other thing that may be worth considering is if we should remove
> this sanity check.
Nah.
regards, tom lane
izeof()
bits work. Right now it's agnostic about how big toast_pointer is,
which seems like a good property to preserve if we are thinking
about having multiple kinds of toast pointer.
regards, tom lane
ningful time
savings, but perhaps it's worth doing just for consistency: grepping
for pg_sleep in our tests, I see anywhere from 0.1 to 0.001 sec.
regards, tom lane
[1]
https://www.postgresql.org/message-id/flat/be0339cc-1ae1-4892-9445-8e6d8995a...@eisentraut.org
f statement doesn't recognize such cases.
regards, tom lane
eally
better, since it's still not an exact match to when the behavior
changed.
regards, tom lane
wiring "blobs.toc", so they fail on
archives made by versions before 548e50976.
I think your patch is about the right thing to do, although I'm
inclined to check for K_VERS_1_14 which is closer to when the
fix was made.
regards, tom lane
...
/* of type PgAioResultStatus, see above */
uint32 status:PGAIO_RESULT_STATUS_BITS;
...
} PgAioResult;
That doesn't make a lot of sense to me, because as far as I've
seen the bitfields in PgAioResult are not concurrently accessed.
But it feels like a relevant observation.
regards, tom lane
7;s update is lost.
If we want to preserve the compactness of this struct, we have
to use primitive int types not bit-fields.
regards, tom lane
[1]
https://wiki.sei.cmu.edu/confluence/display/c/CON32-C.+Prevent+data+races+when+accessing+bit-fields+from+multiple+threads
Peter Eisentraut writes:
> Since we now require Python 3.6, we can also remove PL/Python test
> alternative expected files for earlier Python versions. See attached patch.
+1. So nice to get rid of src/pl/plpython/expected/README.
regards, tom lane
e even need that to be persistent storage at all, rather
than just allocating it for the duration of CheckDeadLock?
regards, tom lane
iled it.
IMO all those struct fields better be declared uint8.
regards, tom lane
did notice a typo in the comment:
+ * pg_assume(expr) stats that we assume `expr` to evaluate to true. In assert
s/stats/states/, I think you meant.
regards, tom lane
Andy Fan writes:
> When reading the code for Gin Index, there are lots of confusion about
> some concepts, so here are some questions in my mind.
At least some of these things are explained in gin.sgml.
regards, tom lane
Andres Freund writes:
> I think this is a big enough pitfall that it's, obviously assuming the patch
> has a sensible complexity, worth fixing this in 18. RMT, anyone, what do you
> think?
Let's see the patch ... but yeah, I'd rather not ship 18 like this.
FM. I'd probably write "is marked as" not "is defined as".
regards, tom lane
don't think I'd trust that. UDFs can claim to be immutable but
be lying about it.
regards, tom lane
-query seems sufficiently
unusual that we'd probably just confuse people by mentioning the
case. Unless you have a proposed wording you think is better?
regards, tom lane
fects than it did before.
regards, tom lane
MIT).
I concur that this needs to be called out as an incompatibility.
regards, tom lane
oncur that any such change would likely not be back-patch
material.
regards, tom lane
ael's point, that really would be exactly
the same place where the eventual "sorry, not supported anymore"
message will be.
If we're not ready to be in their face that much, maybe the
removal isn't so close after all.
regards, tom lane
code, but we aren't going to just rip on faith.
regards, tom lane
; can be proven by the planner to be safe to do so (i.e., no difference in
> result).
I am interested to know how you think the planner could prove that.
regards, tom lane
Jeff Davis writes:
> On Thu, 2025-05-29 at 11:12 -0400, Tom Lane wrote:
>> Perhaps a compromise is to invent RunAsUser but only apply it to
>> virtual columns for now, leaving the view case as a research
>> project. Then we aren't destroying the performance of any
>
Chapman Flack writes:
> On 06/02/25 14:13, Tom Lane wrote:
>> Here's a proposed patch for the "=" issue. Whether or not we should
>> rethink FDW validation behavior, doing so surely couldn't be
>> back-patched. But I think this much should be.
Here's a proposed patch for the "=" issue. Whether or not we should
rethink FDW validation behavior, doing so surely couldn't be
back-patched. But I think this much should be.
regards, tom lane
diff --git a/src/backend/access/common/reloptions.c
Thomas Munro writes:
> On Tue, May 6, 2025 at 12:12 PM Tomas Vondra wrote:
>> On 5/6/25 01:11, Tom Lane wrote:
>>> The attached patch is a response to the discussion at [1], where
>>> it emerged that lots of rows with null join keys can send a hash
>>> join
examples to look at, there's little hope
of getting it right anyway. So I'm content with Peter's choice
here. Perhaps sometime in the future we will have useful examples
with which to revisit this question.
[ wanders away wondering about recasting btree_gist and btree_gin
as single opfamilies ... ]
regards, tom lane
" markers for "xmsg"
and "tbmsg" aren't that big a deal. Trying to mark "emsg" as volatile
would be problematic because none of the StringInfo routines are set
up to allow that, but it shouldn't be a problem because that struct
will surely be on the stack.
regards, tom lane
e somebody abusing
extensions in one very specific way. There are a lot of scenarios
in which a cowboy DBA can cause the database contents to differ
from what the extension scripts say, and most of them would not
be helped by what you're suggesting.
regards, tom lane
Chapman Flack writes:
> On 05/31/25 19:55, Tom Lane wrote:
>> I'm not following that part?
> It's that ISO rule that identifiers match case-insensitively
> if they weren't quoted, case-sensitively if they were.
> We don't explicitly store in catalogs wheth
ote for leaving the grammar alone and rejecting '='
in the option-storing code. If memory serves, there's precedent
for that approach somewhere else in our code.
> SQL rules would also make its case-sensitivity dependent on faithfully
> recovering whether it was delimited or not.
I'm not following that part?
regards, tom lane
t did create them, the indirect dependency seems sufficient.)
regards, tom lane
fers in PLy_elog_impl's PG_FINALLY
block: that doesn't seem necessary, and continuing to do it would
require making those things volatile which is notationally messy.
regards, tom lane
diff --git a/src/pl/plpython/plpy_elog.c b/src/pl/plpython/plpy_elog.c
index ddf3
tly outweigh the value, IMO.
Fundamental layering violations tend to bite you on tender
parts of your anatomy.
regards, tom lane
del. The argument that
"fork is too expensive" may not have a long shelf life.
I'm not taking a position on whether $SUBJECT is a good idea
in the first place.
regards, tom lane
Jelte Fennema-Nio writes:
> On Fri, 30 May 2025 at 16:38, Tom Lane wrote:
>> But if we could have *some* kind of explainable basis for
>> assigning DEBUGn levels, I think our lives would be better.
> Agreed. I'll start with a concrete proposal then:
> DEBUG1 is reserv
at least until someone shows up
with a counterexample.
regards, tom lane
to do after
beta1. So I pushed the minimal patch in all branches. Here is
a rebased-on-top-of-that version of the full patchset, which
I plan to push once v19 development opens.
regards, tom lane
From 3c6c9f60205aaeb740d18876f893d1d46cef9f89 Mon Sep 17 00:00:00 2001
Fr
d never be used
in permanent code.
Maybe that particular idea is not appropriate for some reason.
But if we could have *some* kind of explainable basis for
assigning DEBUGn levels, I think our lives would be better.
regards, tom lane
hacky answer. But making ordinary tables unsafe to
read absolutely is a quantum jump in insecurity; claiming otherwise
is not helpful.
regards, tom lane
much worse.
As Robert said upthread, it would be nice to make all this more
secure. But it'd presumably involve user-visible semantics changes
along with the performance worries I mentioned. It's a dauntingly
large task...
regards, tom lane
fix the known problem
in back branches.
(Patch is labeled .txt so that cfbot doesn't think it's the
patch-of-record.)
regards, tom lane
diff --git a/contrib/postgres_fdw/postgres_fdw.c b/contrib/postgres_fdw/postgres_fdw.c
index 331f3fc088d..4283ce9f962 10
ngjmp" --- they
don't seem to make it possible to bookmark individual pages.
regards, tom lane
Maxim Orlov writes:
> On Thu, 29 May 2025 at 14:14, Tom Lane wrote:
>> -Wclobbered would be really useful if it worked --- but sadly,
>> on practically all gcc and clang versions, those warnings have
>> nearly nothing to do with reality. We typically ignore them.
> Yes,
x post-beta1".
Perhaps a compromise is to invent RunAsUser but only apply it to
virtual columns for now, leaving the view case as a research
project. Then we aren't destroying the performance of any
existing queries.
regards, tom lane
t knows what is the patch-of-record.
(The rebasing is completely trivial; I'm surprised that "git am"
fails to cope.)
regards, tom lane
From 07befa0c2640069db239ed55cfbf068c462e5a26 Mon Sep 17 00:00:00 2001
From: Tom Lane
Date: Thu, 29 May 2025 10:43:10
amount of memory?
regards, tom lane
ing. I anticipate I'll have to rebase the other
patches after I push v5-0001.
Thanks for looking at it!
regards, tom lane
othing to do with reality. We typically ignore them.
See eg:
https://www.postgresql.org/message-id/4001633.1722625...@sss.pgh.pa.us
regards, tom lane
th a check_hook that prevents the gss_accept_delegation
GUC from being set to "true" if not HAVE_GSS_STORE_CRED_INTO.
(That should make the above-depicted elog unreachable, but
belt and suspenders too isn't a bad plan.)
regards, tom lane
t just the wrong time aren't
high, but losing track of an open connection seems pretty bad.
regards, tom lane
From 1d32ebcbae932c3d473fe90094e3c4c90723c0eb Mon Sep 17 00:00:00 2001
From: Tom Lane
Date: Wed, 28 May 2025 16:52:20 -0400
Subject: [PATCH v5] Avoid resour
eptable. I also wonder about whether we ought to try to use
GSS.framework on Mac.
I can say though that it's definitively too late for v18; we've been
in feature freeze for months.
regards, tom lane
especially since the
detailed symptoms are not like indri's.
regards, tom lane
protocol is that you can't/don't
need to detect that. The short answer here is that this is
pgbouncer's bug and you should be nagging them to change, not us.
regards, tom lane
"David G. Johnston" writes:
> On Tue, May 27, 2025 at 3:08 PM Tom Lane wrote:
>> Yeah. I'd say the fundamental problem is that pgbouncer is abusing
>> the server_version parameter, which will break plenty of things
>> besides psql --- pg_dump for instanc
m minus quite a lot on silencing this warning, because
it is telling you about real problems you are likely to hit.
regards, tom lane
ctivity helps --- which would square with
Alexander's results that suggest concurrent runs help.
regards, tom lane
ere's not too many routines touching that
hashtable, so maybe it's not hard.
regards, tom lane
ersion 17.0.0 (clang-1700.0.13.3)
Target: arm64-apple-darwin24.5.0
Thread model: posix
InstalledDir:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
If it's OS-version-specific, that raises the odds IMO that this
is Apple's fault more than ours.
regards, tom lane
some more-limited fix; Evgeniy's
original recommendation was just to reject if the result of
strtod() was outside the expected 0..1 range. But I'm finding
it hard to believe that that's a great idea.
Comments?
regards, tom lane
diff --git a/src/backend/utils/ad
ros). But it is darn hard to repro, for sure.
regards, tom lane
ailure any more or less common. But I've yet to
reproduce it at anything except -O2.
regards, tom lane
lies easily further back, and
would be enough to get the bulk of the benefit.
Comments?
regards, tom lane
[1]
https://www.postgresql.org/message-id/20210317055718.v6qs3ltzrform...@alap3.anarazel.de
diff --git a/src/backend/utils/cache/funccache.c b/src/backend/utils/
.git-blame-ignore-revs, perhaps.)
0004 is the old 0002 (still unmodified) and then 0005 cleans
up one remaining leakage observed by Valgrind.
regards, tom lane
From 47d10046b2594358a1724a1c3f02562eb2d53e30 Mon Sep 17 00:00:00 2001
From: Tom Lane
Date: Mon, 26 May 2025 12:3
ON in order to slap people on the wrist
if they get this wrong.
regards, tom lane
[1] https://www.postgresql.org/docs/current/sql-createdomain.html
Thomas Munro writes:
> On Sun, May 25, 2025 at 3:22 PM Tom Lane wrote:
>> So far, I've failed to get anything useful out of core files
>> from this failure. The trace goes back no further than
>> (lldb) bt
>> * thread #1
>> * frame #0: 0x00018de39388
a better way.
regards, tom lane
or. But we assume that in other usages too.
Hence, v3 attached. The 0002 patch is still the same as before.
regards, tom lane
From be4b888d0d2936cb80e63092d14a3133fab590da Mon Sep 17 00:00:00 2001
From: Tom Lane
Date: Sun, 25 May 2025 19:49:33 -0400
Subject: [PATC
Etsuro Fujita writes:
> On Sat, May 24, 2025 at 10:10 AM Tom Lane wrote:
>> I thought of fixing this by using a memory context reset callback
>> to ensure that the PGresult is cleaned up when the executor's context
>> goes away, and that seems to work nicely (see 000
Silicon machines (an M1 mini, an M4 Pro mini, and an M4 Pro
laptop). So there is definitely something wrong. The failure rate
is pretty tiny for me, though I've not tried running several test
instances concurrently.
regards, tom lane
t;, Line:
1605, PID: 79322
(2 rows)
So it seems that "very low-probability issue in our Mac AIO code" is
the most probable description.
regards, tom lane
pply these
on top of my valgrind-cleanup patches at [1], you'll see that
contrib/postgres_fdw's tests go through leak-free.
regards, tom lane
[1] https://www.postgresql.org/message-id/2884224.1748035274%40sss.pgh.pa.us
From 9b88de523dbede9888b695e660992f803c0110ee
wer. For the moment I have no suggestion other than to not specify
--with-perl etc. while building a valgrind'able installation.
I've now run contrib (at least the installcheck tests) with this
patchset, and we seem to be in mostly good shape there. postgres_fdw
and dblink each have s
x27;s mentioned in the thread title,
I think we only care about LC_CTYPE.
regards, tom lane
I think that it probably should be.
Yeah, I agree, but didn't get to that yet. I've also gone ahead with
committing a couple of clear bugs that I located while doing this.
regards, tom lane
has a better idea.
I'm envisioning this patch series as v19 work, were you
thinking we should be more aggressive?
regards, tom lane
t behavior should also be "no additional filter".
regards, tom lane
tings view to mark custom GUCs
that don't correspond to any reserved extension prefix?
"Not a known extension" could be one of the "error" messages
that that view provides.
regards, tom lane
d
perfectly well be a fully valid setting for an extension that
the installation doesn't choose to preload.
regards, tom lane
sql" is now a reserved prefix.
psql (18beta1)
Type "help" for help.
That's all operating as intended, and I'm not seeing how the proposed
patch isn't completely redundant with it.
regards, tom lane
Jim Jones writes:
> On 22.05.25 01:48, Tom Lane wrote:
>> ... I considered adding an assertion that that call returns
>> NULL, but concluded that it wasn't worth the notational hassle.
>> I'm not strongly set on that conclusion, though, if you think
>>
ith that and it seems you do, too. So perhaps Jeff should make
>> it so?
> +1, I think we should go ahead and do this. If Jeff can't get to it, I'm
> happy to pick it up in the next week or so.
Works for me, too.
regards, tom lane
k the planner to handle those.
BTW, in my mind the current thread is certainly v19 material,
so I have not looked at Richard's patch yet.
regards, tom lane
f them show pretty
enormous amounts of "possibly lost" data, which again seems likely to
be an artifact of allocation games within those libraries rather than
real leaks. I wonder if they have "valgrind friendly" build options
that we'd need to use to get sane res
rhaps it would be better to apply the same configuration as the CI
> by default at the end?
I'd vote for standardizing on pg_regress.c's spelling, as that's got
the most usage history behind it. I'm unexcited about bloating the
logs with [%v:%x] --- that's data I've very seldom needed.
regards, tom lane
Jim Jones writes:
> On 21.05.25 22:20, Tom Lane wrote:
>> It turns out that xmlDocSetRootElement() doesn't
>> merely install the given root node: it unlinks the document's old
>> root node and returns it to you. If you don't free it, it's leaked
>&g
h that issues a
> warning for such invalid GUC entries.
How will you know they are invalid? All I see in the patch is
a syntactic check, which looks quite redundant with
assignable_custom_variable_name().
regards, tom lane
palloc). The amount of
leakage isn't that large, seems to be a couple hundred bytes per
iteration, which may explain why this escaped our notice in the
previous testing. Still, it could add up under extensive usage.
So I think we need to apply the attached, back to PG 16.
really
really doesn't want to fix their app, they can trivially create a
wrapper function with the old name.
Having said that, what's wrong with inventing some improved function
names and never removing the old ones?
regards, tom lane
hout it we
have various gripes about memory leaked from plancache entries.
regards, tom lane
[1] https://www.postgresql.org/message-id/flat/213261.1747611093%40sss.pgh.pa.us
[2] https://www.postgresql.org/message-id/594293.1747708165%40sss.pgh.pa.us
[3] https://www.postgresql
st back-patching, as there is a user-visible
behavior change in EXPLAIN, and I don't think there are really
any severe consequences to the mistaken assignments.
regards, tom lane
From 19382e5a4af617a56e86d197f394bed93862cd66 Mon Sep 17 00:00:00 2001
From: Tom Lane
Date
Andres Freund writes:
> On 2025-05-20 16:18:57 -0400, Tom Lane wrote:
>> I'm curious though: what was the test case you were looking at?
> It's a modified query from our regression tests, I had added some debugging to
> find cases where the targetlists differed.
,
though. Those operations work from a parse tree not a plan tree.
regards, tom lane
.
I don't believe that we guarantee EXPLAIN output to be 100% valid SQL,
so I doubt there's a correctness argument here; certainly it'd not
affect pg_dump. I'm curious though: what was the test case you were
looking at?
regards, tom lane
I wrote:
> I think we can just delete this assignment (and fix these comments).
As attached. I'm tempted to back-patch this: the plan tree damage
seems harmless at present, but maybe it'd become less harmless with
future fixes.
regards, tom lane
diff --git
made me wonder if we would
> detect mismatches - and afaict we largely wouldn't. There's basically no
> verification in ExecBuildProjectionInfo(). And indeed, adding something very
> basic shows:
Hmm, seems like an independent issue.
regards, tom lane
like the core idea of deferring locking, but I don't like
anything about this implementation of it. It seems like there has
to be a better and simpler way.
regards, tom lane
broken". Whether it's flaky hardware, broken compiler, or what is
undeterminable from here, but I don't believe it's our bug. So I'm
unexcited about putting effort into it.
regards, tom lane
[1]
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=leafhopper&dt=2025-05-19%2007%3A07%3A04
* the state of the master
branch. If there is a problem in master, we typically know it because
the buildfarm is also unhappy, so I'm not clear on what a null patch
in the queue would add.
regards, tom lane
1 - 100 of 2674 matches
Mail list logo
