bal after running configure.
FWIW, EL5 is *ancient*. You really oughta consider an update.
regards, tom lane
if you are
doing something nonstandard to configure those, but for me
it works for alternate IPs configured in
/etc/sysconfig/network-scripts/ifcfg-whatever.
regards, tom lane
Michael Harris writes:
> On Mon, 7 Feb 2022 at 09:57, Tom Lane wrote:
>> Do you want to try this and see if it actually adds any robustness with your
>> buggy code?
> Sorry for the delayed response, & thanks for the patch.
> I wasn't able to test with our actua
he sentence is
> still true in a more general sense, so we can just leave it there.
Oh, I didn't notice that comment, or I probably would have tweaked it.
Perhaps along the line of "there are too few systems that have epoll
and not signalfd to justify maintaining a separate code path
fault.
> 0x008b3514 in pg_detoast_datum ()
The most obvious theory is that there are some nulls in the XT.XMLT1C1
column. Since your code isn't bothering to check pXmlDataNulls[ix],
it would hit a null-pointer dereference when accessing pXmlData[ix].
regards, tom lane
probably happen if
we could get consensus on the syntax. But we're not going to
throw away thirty-five years' worth of work to chase some
blue-sky ideas.
regards, tom lane
de GRANT EXECUTE TO PUBLIC. Revoking the never-granted-in-the-
first-place permission to z doesn't remove the PUBLIC permission.
So, if you want to be selective about who can use your functions,
you should revoke the PUBLIC permission and then grant out
permissions to individual roles.
regards, tom lane
nd about this behavior that they ought to look
more closely.)
regards, tom lane
alification or a function-local
setting of search_path.
regards, tom lane
quot;can't sync from a non-table"
rather than claiming the object doesn't exist at all.
regards, tom lane
objects depend on it
DETAIL: function myfunc(integer) depends on function cube(double
precision,double precision)
HINT: Use DROP ... CASCADE to drop the dependent objects too.
Another possible approach is to group such functions into
their own extension, which you could make dependent on cube.
regards, tom lane
"David G. Johnston" writes:
> On Thu, Feb 17, 2022 at 6:17 PM Tom Lane wrote:
>> There is no bug here; it's operating as designed and documented.
>> Maybe the docs need some refinement.
> We should just say that ALTER FUNCTION ALTER DEPENDS ON makes the target
Postgres
installation, this seems plausible). Beyond that it's hard to think
of any explanation other than hardware fault or corrupted executable.
regards, tom lane
s) if you had to?
At the SQL level, your example does not involve text -> double.
The literal 1.56 is of type numeric.
regards, tom lane
me machine has ECC
memory ... ]
regards, tom lane
Carsten Klein writes:
> @Tom Lane: you say, PostgreSQL does not / cannot change rounding mode at
> any time? There is no function to do so? So, the script (it's more like
> a module) must provide a Shared Object module with a C function in order
> to change the FPU's ro
html#XFUNC-SQL-COMPOSITE-FUNCTIONS
regards, tom lane
en for people with no interest in changing modes.
Thanks for closing out the thread with this info!
regards, tom lane
n general.
Perhaps the ideal behavior here would be "normalize, but don't throw away
stopwords", but unfortunately our dictionary APIs don't support that.
regards, tom lane
aving to double quotes and backslashes
within those quotes. So what you'd actually need is
=# select $$'\\:':1$$::tsvector;
tsvector
--
'\\:':1
(1 row)
If you write just one backslash, it has the effect of quoting
the next character, which in this case doesn't need quoting.
regards, tom lane
umented requirement, so I don't see why it wouldn't be
safe.
regards, tom lane
NING r_1103088.id,
> r_1103088.mobiuserid,
> [etc]
The RETURNING list has to match the column list of the rule's
target table or view (here, doctrine.ja_notes). Maybe you added
some columns to that since this last worked?
regards, tom lane
regards, tom lane
wasted split attempts (and other
files being exactly the same size as the ones from the previous
iteration).
regards, tom lane
i.postgresql.org/wiki/PGLister_Announce
Those looking to unsubscribe should also read that page. Sending
"unsubscribe" messages to the list will not accomplish anything
except to annoy the rest of the list membership.
regards, tom lane
er convenient unsubscribe
buttons. Not sure how many of the people who are complaining use
mail agents that don't handle that.
regards, tom lane
regards, tom lane
conspicuous absence of pgsql-annou...@postgresql.org in the
> lists the Before email was sent to. Can I assume that that list
> continues under the old regime?
It's scheduled to be migrated next week.
regards, tom lane
Unsubscribe.
(If you indeed did that, and it failed to work, our list admins
would definitely want to know about it; but they'd want a lot
more details than you've provided.)
regards, tom lane
whether there are complicating factors Ryan hasn't mentioned,
like maybe his traffic is getting forwarded from some other account
on some other email provider. If so, maybe the List-Unsubscribe
header is getting dropped in forwarding? That's a reach, but it's
hard to explain otherwise.
regards, tom lane
Cory Tucker writes:
> On Mon, Nov 20, 2017 at 9:36 AM Tom Lane wrote:
>> The only thing I can think of offhand that could create temp files far in
>> excess of the actual data volume is if a hash join repeatedly decides that
>> it needs to increase the number of hash batche
at none of this thread would
be seeing the light of day in any timely fashion if the new code
did that.
Hopefully things have more or less settled out now and we can get on
with normal discussions? Please?
[ wanders away wondering why last week's migration of the hackers
lists produced far less complaining... ]
regards, tom lane
> rotfl, and ain't that the truth.
I'm not sure I believe it. People reading any database-oriented mailing
list are going to be pretty tech-savvy, I'd think.
regards, tom lane
Thomas Munro writes:
> On Wed, Nov 22, 2017 at 7:04 AM, Tom Lane wrote:
>> Now, there's definitely something busted here; it should not have gone as
>> far as 2 million batches before giving up on splitting.
> I had been meaning to discuss this. We only give up when we r
nless you
can find what was holding that lock, there's not much we can learn from
this report ...
regards, tom lane
Andres Freund writes:
> On 2017-11-21 18:21:16 -0500, Tom Lane wrote:
>> Justin Pryzby writes:
>>> As $subject: backends are stuck in startup for minutes at a time. I didn't
>>> strace this time, but I believe last time I saw one was waiting in a futex.
> A
and...@anarazel.de (Andres Freund) writes:
> On 2017-11-21 18:50:05 -0500, Tom Lane wrote:
>> (If Justin saw that while still on 9.6, then it'd be worth looking
>> closer.)
> Right. I took this to be referring to something before the current
> migration, but I might h
not see our
lwWaiting as cleared yet, causing the loop to go around an extra time and
wait for a sema wakeup that will never come. Then, we are holding the
lock but are blocked anyway, and everyone else who wants that same lock
will queue up behind us.
regards, tom lane
on't have a defense against it.)
regards, tom lane
(which are all libpq tests),
>> why is the “examples” directory not included when building postgres?
I've always taken those to be more documentation, or sample code, than
test cases. I'm not sure why they're under src/test/ at all.
regards, tom lane
t your subscription in some other way.
regards, tom lane
ory that fits at all.
[ in an earlier post: ]
> BTW this is a VM run on a hypervisor managed by our customer:
> DMI: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform,
> BIOS 6.00 06/22/2012
Hmm. Can't avoid the suspicion that that's relevant somehow.
regards, tom lane
ns during the first wait for
an LWLock ... and if so, how could that be?
regards, tom lane
gresql.org/wiki/Generating_a_stack_trace_of_a_PostgreSQL_backend
regards, tom lane
Justin Pryzby writes:
> On Wed, Nov 22, 2017 at 07:43:50PM -0500, Tom Lane wrote:
>> My hypothesis about a missed memory barrier would imply that there's (at
>> least) one process that's waiting but is not in the lock's wait queue and
> Do I have to also check
GISTENTRY *entry = (GISTENTRY *) PG_GETARG_POINTER(0); /* I think entry
> is pointer to bad memory */
The argument is TRGM *, I think ... certainly not GISTENTRY *.
regards, tom lane
ed to restart the postmaster, to get rid of whatever
is in Postgres' shared buffers.
regards, tom lane
ea.
There are lots of other known bugs in that version.
Relevant to our discussion, the fix involves inserting a memory
barrier into the kernel's futex call handling:
https://github.com/torvalds/linux/commit/76835b0ebf8a7fe85beb03c75121419a7dec52f0
regards, tom lane
irst email though: we should
> always be able to handle that condition gracefully.
I suspect this is an instance of the issue I complained about before [1]
that parallel query is unable to cope with worker start failure.
regards, tom lane
[1] https://www.postg
3. If #2 fails, TRUNCATE pg_statistic, then re-analyze everything to
rebuild the stats.
regards, tom lane
tly, the view owner lacks select permission on some underlying
table. Pay attention to what is being denied access to.
regards, tom lane
nor an
indexscan qual.
In principle this could be improved, but given how much work it'd be
and how seldom anyone complains, it's not likely to happen anytime soon.
regards, tom lane
at remote userid needs SELECT on whatever the foreign table
is referencing. I'm guessing you messed up one of these components.
regards, tom lane
; seems to be a child of a "SPI Proc" context, whereas
it's entirely clear from the code that it ought to be a direct child of
TopMemoryContext. I have no idea how this state of affairs came to be,
and am interested to find out.
regards, tom lane
Ted Toth writes:
> On Tue, Nov 28, 2017 at 9:59 PM, Tom Lane wrote:
>> So whatever's going on here, there's more to it than a giant client-issued
>> INSERT (or COPY), or for that matter a large number of small ones. What
>> would seem to be required is a many-
ble_name;
SELECT 38400256
Watching the process with "top", its memory consumption stayed
rock-steady. If there's a leak in there, this example doesn't
show it. There could be a leak related to some detail you
failed to mention, but ...
regards, tom lane
ts(json_rmq -> 'orders'::text) AS orders
FROM
(SELECT
json_rmq->>'totalSize' as totalSize, json_rmq
FROM csnbi_stg.stg_rmq_prod_test_json_raw_jmcn stg_rmq_json_raw
WHERE ...
OFFSET 0) ss;
regards, tom lane
8601 offset for PST
as being in any way vague about which convention the "-8" is read in?
regards, tom lane
tamp with time zone at time
> zone 'Australia/Melbourne';
The +11 in your timestamp input value is per ISO convention, but the
argument of AT TIME ZONE is a zone name, so it follows the POSIX
convention if it's numeric.
regards, tom lane
seful
if it's waiting, too.
https://wiki.postgresql.org/wiki/Getting_a_stack_trace_of_a_running_PostgreSQL_backend_on_Linux/BSD
regards, tom lane
x(age(datfrozenxid)) from pg_database;
If that starts to approach two billion, or gets a lot larger than
autovacuum_freeze_max_age, you've got a problem.
regards, tom lane
nto a pre-existing table that has the
right name and the wrong column list.
I'd counsel looking at the *first* error message and resolving that,
then trying again. Anything later could just be cascaded failures.
regards, tom lane
ernal to the
comparison function, convert each string to EBCDIC on each call.
Another way you could imagine is to store EBCDIC strings embedded
in bytea values.
regards, tom lane
ll be used inside a transaction block or not.
regards, tom lane
nt in SQL?
Seems like you could build a query for that easily enough using a
recursive union over pg_depend plus pg_describe_object() to produce
text descriptions of the entries.
regards, tom lane
Venkata B Nagothi writes:
> To rule out any application issues, is it possible to get postgresql to
> ignore DST and render all the timestamps with timezone offsets of +11 ?
set timezone = 11
regards, tom lane
But as far as Postgres is concerned, it's nonsense.
regards, tom lane
Vincenzo Romano writes:
> It seems I cannot use a temporary function.
You have to schema-qualify the temp function name when calling it, too.
regards, tom lane
Vincenzo Romano writes:
> 2017-12-21 17:52 GMT+01:00 Tom Lane :
>> You have to schema-qualify the temp function name when calling it, too.
> So search_path is not used with functions?
pg_temp is explicitly ignored when searching for functions/operators.
Otherwise, installing a tro
ubquery Scan on "*SELECT* 2" (cost=0.00..0.02 rows=1 width=4)
-> Result (cost=0.00..0.01 rows=1 width=0)
(5 rows)
which would only be the right plan for UNION ALL.
So yeah, it's wrong ... but personally I'm not terribly excited
about fixing it. Maybe somebod
"David G. Johnston" writes:
> On Thursday, December 21, 2017, Tom Lane wrote:
>> So yeah, it's wrong ... but personally I'm not terribly excited
>> about fixing it. Maybe somebody else wants to; but what's the
>> practical use?
> Ho
see
https://git.postgresql.org/gitweb/?p=postgresql.git&a=commitdiff&h=1b4f7f93b
There should be something about it in the 9.4 release notes.
regards, tom lane
o throw an error ;-). So I just
fixed it and added some regression tests. But 9.6 blows up somewhere
in the executor, and it didn't seem worth trying to deal with that.
So in 9.4-9.6 I just made the case throw an error.
regards, tom lane
subbing the parameters?
psql hasn't any way to do that. You might consider pgbench as a
possible substitute though --- not only can it do PARSE/BIND/EXECUTE,
but you can insert appropriate parameter values via variables.
regards, tom lane
a change to the view definition.
You'd probably be better off to define your own nonstandard view, IMO.
regards, tom lane
Rob Sargent writes:
> Keep in mind there is a quick write-to-file in psql with ‘\o ’. And
> don’t forget to turn it off with ‘\o’
See also "\g filename", for one-shot output.
regards, tom lane
t wish
to avoid that.
The usual rule for that is "be sure all transactions acquire locks
in the same order". So just throw an "order by id" type of clause
into the SELECT FOR UPDATE, and you should be fine.
Personally, I'd still code the application to retry on deadlock
failures, just for robustness.
regards, tom lane
the underlying tmpfs
> file). Can you share the query plan (EXPLAIN SELECT ...)?
I wonder if OP is running with a tmpfs size setting that's less than
the traditional Linux default of half of physical RAM size.
regards, tom lane
fs limits that seem equally chosen with the aid of a dartboard.
regards, tom lane
an Ubuntu user, I don't know how to do that,
but I'm sure they have an equivalent of "rpm -qf".)
regards, tom lane
throwing in a bunch of -I switches willy-nilly.
In short, yeah, try removing the -I that's pointing at the upper
directory.
regards, tom lane
me amount of macro-ization involved, so it might
look more like
INCLUDEDIR = /usr/include/postgresql
...
CPPFLAGS = -I$(INCLUDEDIR)
Furthermore, given our current theory, there's going to be more than
one -I switch on that line, and you want to get rid of just one.
regards, tom lane
s likely to break code that's expecting
the Ubuntu-standard layout. I think your best course is to adapt the
particular package you're having trouble with to work with that layout.
Maybe contact its author for help?
regards, tom lane
t really sure if that will help much.
Is anything at all appearing in the postmaster log file now?
regards, tom lane
scanning parts of the inner input. It has to do that
whenever the outer input has duplicate keys.
regards, tom lane
at could lead
to a crash in pg_qsort --- at worst it might cause a little inefficiency.
regards, tom lane
Alvaro Herrera writes:
> Tom Lane wrote:
>> Hm. I'm not normally one to jump to the conclusion that something is a
>> compiler bug, but it's hard to explain this stack trace any other way.
>> The value of "n" passed to the inner invocation of pg_qsort sho
rrupted-binary theory.
regards, tom lane
7;s misexecuting integer divide every so
often --- though it's hard to guess why only pg_qsort would be
affected.
regards, tom lane
9.4 is awful. So your problem is not with the costs but with the
selectivity estimates. Has the 9.4 database been ANALYZEd at all? Maybe
you disabled auto-analyze? Maybe the old DB has some special statistics
target settings that you neglected to port forward?
regards, tom lane
U4pXYKDHeQhsA_%3DFC93yOBZp5j1h%3DBSSAo9-oLcwNww%40mail.gmail.com
Seems to have lost interest though ...
regards, tom lane
the raw column contents.
regards, tom lane
Daniel Farina writes:
> On Tue, Jan 16, 2018 at 3:04 PM Tom Lane wrote:
>> Umm ... are you accounting for catalogs that have zeroes in
>> pg_class.relfilenode? It's generally better to rely on the
>> pg_relation_filenode(oid) function than the raw column contents.
&g
ect chunk_id, chunk_seq, ctid, xmin, xmax, length(chunk_data)
from pg_toast.pg_toast_10919630
where chunk_id = 1498303849
order by 1,2;
might be informative. If you do see what seem to be duplicate
chunk_seq values, checking whether they're still there in a
seqscan would be good.
regards, tom lane
Alvaro Herrera writes:
> Tom Lane wrote:
>> However, assuming you've gotten that detail right, then any file
>> you can't match up with a relfilenode value must be an orphan you
>> can just "rm".
> Maybe look in pg_buffercache for entries referencing
having a reproducer. It's okay if it
takes awhile to reproduce the fault ...
Also, before spending a whole lot of time on this: are you on 9.6.6?
If not, update, just in case this is an already-fixed issue. The
symptoms don't sound familiar, but I don't want to waste a lot of
time only to find out it's some manifestation of a known bug.
regards, tom lane
imates suggesting that
only a relatively small number of rows will get processed. It's
definitely making some progress, because your successive backtraces
show different blocks getting read.
regards, tom lane
e that much worse than
some other gotchas.
regards, tom lane
FROM tab, LATERAL (SELECT a+b as x OFFSET 0) ss;
I haven't really experimented, but I think that this'd dodge
most of the optimization pitfalls, except one: in this formulation,
a+b will be evaluated for every "tab" row even if the particular
use of the view does not demand any of the columns that use "x".
regards, tom lane
evaluated at every outer row.
regards, tom lane
2601 - 2700 of 2962 matches
Mail list logo
