on the findings above.
+1, given the lack of complaints it certainly appears that
nobody cares.
regards, tom lane
the whole I see little value in taking any risk here.
regards, tom lane
ctions qualify as a "custom API". I'd vote not (ie they
shouldn't modify their input strings) unless we find exceptions.
So that suggests that the use of non-const pointer Datums should be
the outlier.
regards, tom lane
hange like this one,
in isolation, isn't going to move that needle.
regards, tom lane
really have to do #2 until someone complains about
the lack of ability to do forward references, which going by history
is probably not going to be soon. I certainly don't feel that it has
to be completed in this patchset.
regards, tom lane
rcommit disabled, if it truly runs occasionally OOM.
We have very substantial field experience showing that leaving memory
overcommit enabled also makes the system unreliable, if it approaches
OOM conditions. I don't think removing that advice is an improvement.
regards, tom lane
ply the check only when there are fewer than say 1000 labels,
reasoning that anything bigger is probably machine-generated anyhow.
regards, tom lane
verything in this file is dealing with
socket-related errors. Certainly the underlying pqsecure_raw_read
and pqsecure_raw_write layer expects those macros to be used.
Like you, I'm not really in a position to test this on Windows ...
regards, tom lane
ot/HEAD/pgsql.build/src/interfaces/ecpg/test/thr
All the other processes belonging to pgbf are test driver processes
that would be waiting for these two.
Since we're not seeing comparable failures on other animals,
I tend to agree with his diagnosis of a bug in 9.3's malloc library.
regards, tom lane
Peter Eisentraut writes:
> On 30.08.25 18:52, Tom Lane wrote:
>> I suppose that the expectation is that every release note item
>> will be credited to someone. Why does this item lack a credit?
> Maybe I'm understanding this differently, but the "Migration" se
rrounding text.
Hmm, this text has *two* attributions to Peter, and
add_commit_links.pl disagrees with you on where to put the URL.
regards, tom lane
lank line before the , which is not our usual
style and should be removed IMO. (Alternatively, we could change
the $prev_leading_space updating logic to ignore blank lines.)
regards, tom lane
diff --git a/src/tools/add_commit_links.pl b/src/tools/add_commit_links.p
the item"?
In either case, I don't agree with hacky workarounds like manually
munged ulink entries ...
> I can commit this once our RC1 git tree freeze is over. Is that Tuesday?
The release freeze doesn't apply to the release notes ;-)
regards, tom lane
function's name, but we do need to be more precise in the
> documentation that it checks for the null value and not values that are
> null.
Agreed. You might be able to borrow some wording from the docs'
discussion of the IS [NOT] NULL construct, and/or IS DISTINCT FROM.
regards, tom lane
l allocation could stand to be a good bit larger, maybe 64 or
256 or so entries, to reduce the number of repallocs. I did
experiment with that a little bit and could not show any definitive
speedup on the test case I was using ... but 4 entries seems miserly
small.
regards, tom lane
angerous, just as we've
judged it to be for deadlock reports.
Hearing no comments beyond that one, pushed.
regards, tom lane
e case of
SQL-standard functions. Everything mentioned in such a function has
to exist at function creation time, no exceptions.
There's a closely related complaint at [1], which I rather doubt
we're going to do anything about.
regards, tom lane
[1]
https://www.postgresql.org/message-id/19034-de0857b4f94ec10c%40postgresql.org
[ moving thread to -hackers for more visibility ]
Dilip Kumar writes:
> On Fri, Jun 20, 2025 at 2:29 AM Tom Lane wrote:
>> Dilip Kumar writes:
>>> I haven't reviewed the patch itself, but I like the idea. We're now
>>> consistently using the pare
ch's draft commit message.
regards, tom lane
Peter Eisentraut writes:
> On 07.08.25 16:58, Tom Lane wrote:
>> 0004: I prefer the solution I exhibited yesterday, ie add
>> externs to those headers.
> That solution seems fine, too.
Great.
> This comment should be clarified:
> + # This redundant extern declarat
p some very messy hacks.
regards, tom lane
Richard Guo writes:
> On Fri, Aug 29, 2025 at 2:26 AM Tom Lane wrote:
>> With one eye on the fast-approaching release freeze for 18rc1,
>> I plan to go ahead and push these. Please do review if you
>> have time, but I think getting some buildfarm cycles on these
>>
cs altogether. I think there is not a
very good argument for ProcessUtilitySlow doing all that stuff.
It's supposed to mainly just be a dispatching switch(), IMO.
regards, tom lane
nd it a little confusing that that code doesn't line up
exactly with what CreateLWLocks does.
regards, tom lane
Richard Guo writes:
> On Thu, Aug 28, 2025 at 6:42 AM Tom Lane wrote:
>> 2. Try to fix up the SJE patch so that it calculates relid changes
>> honestly, or at least no less honestly than what happened before
>> a3179ab69.
> I took a look at #2. I don't have a
ht
> be okay now to change the product name in various places here, but it
> seems better to do it consistently across the whole page.)
LGTM, thanks. (My wording was only meant as a draft ...)
regards, tom lane
lready doing, but
I still think that the cost will be negligible in normal cases.
I'll try to have a patch along those lines by tomorrow.
regards, tom lane
Richard Guo writes:
> On Wed, Aug 27, 2025 at 2:26 AM Tom Lane wrote:
>> I wonder if the right answer in v18 is to back out a3179ab69.
>> Not fixing that performance regression for another year would
>> be mildly annoying; but AFAIR we've still had only the one
>
The release team has agreed that we should put out 18rc1 next
week (wrap 9/1, announce 9/4).
If the RC period goes smoothly, we'll put out 18.0 the last
full week of September (wrap 9/22, announce 9/25).
regards, tom lane
I wonder if the right answer in v18 is to back out a3179ab69.
Not fixing that performance regression for another year would
be mildly annoying; but AFAIR we've still had only the one
complaint, so it seems like it's not hurting many people.
And we are getting mighty late in the release calendar to be
inventing new stuff in v18.
regards, tom lane
t wouldn't end in making things worse.
regards, tom lane
Peter Eisentraut writes:
> Tom: You ought to update the configuration on the buildfarm members
> longfin and sifaka from
> 'CC' => 'ccache clang -std=gnu99',
> to
> 'CC' => 'ccache clang -std=gnu11',
> for the master branch.
Roger, will do.
regards, tom lane
for this than the server does, so I don't see why the existing
server-side options aren't sufficient.
(For that matter, if you have system-level security specifications
to meet, why would you not alter the system-wide OpenSSL configuration
on the client's host?)
regards, tom lane
eah, same here. I have a BF instance lying around that's configured
to do the cross-version pg_upgrade tests. It's not registered with
the BF server, I just run it manually when I need to test that.
regards, tom lane
ower than the current
code. But maybe the difference would be small.
I'm not planning to work on either of these ideas right now,
but I thought I'd put them out there in case someone else is
interested.
regards, tom lane
ss Unique step. Maybe we should just absorb the input
relation's path list as-is?
regards, tom lane
diff --git a/src/backend/optimizer/plan/planner.c b/src/backend/optimizer/plan/planner.c
index 65f17101591..bb03ea7ccb4 100644
--- a/src/backend/optimizer/plan/planner.c
earlier: we need to avoid attaching a new tlist entry if the
expression is constant, else we'll still get the failure.
regards, tom lane
Daniel Gustafsson writes:
>> On 1 Jul 2025, at 17:42, Tom Lane wrote:
>> There are some minor typos in the proposed commit message, too.
> It seems that my grasp of the english language went on holiday before I did.
> The attached v9 is hopefully less terrible.
This thread s
left joins.
> I have only observed this problem when there are many null values in the join
> column.
Thanks for testing!
regards, tom lane
t any
substantive logic change.
regards, tom lane
From ba0701a0bf2f2f20b1453f38471c9f100c989c8d Mon Sep 17 00:00:00 2001
From: Tom Lane
Date: Sun, 24 Aug 2025 13:39:54 -0400
Subject: [PATCH v4 1/4] Provide more-specific error hints for function lookup
failures.
Up to now we've contented ourse
the wrong tradeoff. CI should be expected to be
fairly cheap, not to catch everything the buildfarm could catch.
regards, tom lane
oked at what code
changes would be needed for that.)
regards, tom lane
[1]
https://www.postgresql.org/message-id/flat/19030-944dd78d7ef94c0f%40postgresql.org
nstallation settings, but that's a minority
of our tests.
regards, tom lane
triving
to make the meson system as easy to use as autoconf/make, not trying
to attain parity by making the latter experience worse.
regards, tom lane
Sami Imseih writes:
> One point I did not make earlier is that the tranche name lengths will
> need to be as long as we allow in dsm_registry.c.
> #define DSMR_NAME_LEN 128
Huh. Why is that different from NAMEDATALEN in the first place?
regards, tom lane
tches 0002
and 0003 are unchanged.
I did not adopt your changes in [2], because they didn't really
seem like improvements to me.
regards, tom lane
[1]
https://www.postgresql.org/message-id/CACJufxGFzbRDnyG-%3DWZ3RgkVUwOZexUobGDrA3n5bj8MxrAZvQ%40mail.gmail.com
quences, views, foreign tables, materialized
views, composite types, and indexes are all relations. A relation
in this sense is a container or descriptor for a set of tuples.
"Class" is an alternative but archaic term. The system catalog
pg_class holds an entry for each Postgres relation.
regards, tom lane
t;ambiguous function" case, which might be worth doing but it's
not the goal of this patch.
regards, tom lane
se" comes from. Maybe whoever
wrote this was trying to get at that point? But this text is
hardly clear about that.
regards, tom lane
to be able to call pprint from pretty much
anywhere.
Also, AFAICS this breaks re-reading of dump trees, which breaks all
kinds of stuff (rules, views, parallel query, etc).
regards, tom lane
Node* first?
We take that sort of shortcut in many places. If there's not any need
for the code to deal with more than one node type, an extra variable
that's used just for the IsA test seems like a lot of notational
overhead.
regards, tom lane
; violates
> not-null constraint
> DETAIL: Failing row contains (0, null, null, null).
You are misunderstanding the effects of that INSERT. The AS labels
have zero to do with the semantics, so you are inserting 0 to col1,
null to col2 & col3, and by default null to col4.
regards, tom lane
;argnames != NIL"
for checking whether there are argnames, though. Also, I added a
flag bit and error message for the case where none of the candidate
functions have the right number of arguments, because when that's
true, we'll never get to looking at ar
Alexander Korotkov writes:
> On Tue, Aug 19, 2025 at 10:50 PM Tom Lane wrote:
>> Therefore, I vote for reverting bc22dc0e0. Hopefully only
>> temporarily, but it's too late to figure out another way for v18,
>> and I don't think that bc22dc0e0 is such an essenti
those questions. Sure, we could also do that through
returned flags, but is that better? ParseFuncOrColumn contains
existing tests for "argnames != NIL", so checking that the same way
in this new code seemed better than doing it differently.
regards, tom lane
Chao Li writes:
> On Aug 8, 2025, at 09:29, Tom Lane wrote:
>> I couldn't quite let go of this, and after some thought I hit on the
>> idea of making FuncnameGetCandidates pass back a bitmask of flags
>> showing how far the match succeeded.
> I traced this problem t
e handled completely differently
on different platforms? I'd lean to ignoring the Linux/FreeBSD
facilities, because otherwise we're basically doubling our testing
problems in exchange for not much.
regards, tom lane
undreds of lines of errors and
> conditions and comments that were now unreachable.
The patch would likely be a lot more readable if you split out the
"delete unreachable code" part into a separate step.
regards, tom lane
sting.
If you prefer to regard this as an independent issue, that's okay with
me ... but it's touching most of the same lines of code, so it seems
to me that it'd be about as easy to deal with both items at once.
regards, tom lane
t let's not be fuzzy about what information
is available at execution time.
regards, tom lane
#x27;m not 100% sure that it does so correctly.
Anyway, given that it's supposed to provide low-level inspection of
the sequence tuple, I think that it's best not to be too cute.
regards, tom lane
option, it seems like a bad idea.
Independently of that, we have learned the hard way that GUCs
that change application-visible query semantics are a bad idea.
You cannot really argue that this wouldn't be one.
regards, tom lane
for you.
regards, tom lane
Thomas Munro writes:
> On Wed, Aug 20, 2025 at 7:50 AM Tom Lane wrote:
>> I'm inclined to think that we do want to prohibit WaitEventSetWait
>> inside a critical section --- it just seems like a bad idea all
>> around, even without considering this specific failure m
ches, but thus far we've been trying to avoid it.
I can hardly imagine a reason why it wouldn't be okay to limit the
lengths of tranche names. But especially so if an unlimited length
causes practical problems.
regards, tom lane
ased
delays inside critical sections. So that infrastructure is leaving
something to be desired.
Having said that, the test script is also doing something we tell
people not to do, namely SIGKILL the postmaster. Could we use
SIGQUIT (immediate shutdown) instead?
regards, tom lane
if there's a way to
re-implement the injection point "wait" functionality without
depending on WaitEventSetWait. I would be willing to accept
weaker safety guarantees in this context, since we only anticipate
such cases being used in test scaffolding.
regards,
Robert Haas writes:
> On Tue, Aug 19, 2025 at 1:18 PM Tom Lane wrote:
>> * The initial allocations of the arrays need to take
>> more care than this about which context the arrays go into,
>> ie it had better be planner_cxt for PlannerInfo or PlannerGlobal,
>> and the
ething that
seems pretty unsafe, namely invoking WaitEventSet inside a
critical section.
We'd probably be best off to get back to the actual bug the
thread started with, namely whether we aren't doing the wrong
thing with VM-update order of operations.
regards, tom lane
ociated with
ON COMMIT DELETE, you'll find quite a few, which is one reason why
I'm allergic to adding more complexity here.
In short, I think you're underestimating the engineering costs and
overestimating the benefit of doing this.
regards, tom lane
the same context the RelOptInfo is in for RelOptInfo.
Otherwise you risk a mess under GEQO.
* Surely, if extension_state etc is read_write_ignore, then
extension_state_allocated etc had better be as well? I don't
understand the rationale for preserving one without the other.
regards, tom lane
erge some of these tables (adding an additional
key column, probably) so that a single truncate suffices for all?
regards, tom lane
ah, the real sub-text here is "should we believe that this
application is well designed?". It sounds like a fairly brute-force
solution.
regards, tom lane
mailer: QQMail 2.x",
which apparently doesn't feel a need to generate References:
or In-reply-to: headers. That's super unfriendly behavior for
mailing lists.
regards, tom lane
ar, I don't think that creating thousands of temp tables in
a session but then touching only a few of them in any one transaction
is a very plausible usage pattern.
regards, tom lane
work here.
They're not *quite* duplicates though, for instance next_pow2_int has
different response to out-of-range values than pg_nextpower2_32.
regards, tom lane
ll. The tables were a bit wider than screen width
already, but it feels like they changed significantly.
regards, tom lane
Thomas Munro writes:
> On Tue, Aug 19, 2025 at 4:52 AM Tom Lane wrote:
>> But I'm of the opinion that proc_exit
>> is the wrong thing to use after seeing postmaster death, critical
>> section or no. We should assume that system integrity is already
>> compromise
t will be understandable or maintainable --- and certainly,
hash join is on the hairy edge of being too complicated already.
regards, tom lane
ot know it
should use /usr/local/bin/krb5-config).
It looks like every other use of BAIL_OUT is in a file that does
have "use Test::More", so this is the only such oversight.
Will push, thanks for the report!
regards, tom lane
Kirill Reshke writes:
> On Sun, 17 Aug 2025 at 19:33, Tom Lane wrote:
>> I do not like this patch one bit: it will replace one set of problems
>> with another set, namely systems that fail to shut down.
> I did not observe this during my by-hand testing. I am under the
>
ate an update
not a delete. But flushing the function tree would be OK
in either case.)
I wonder if we could make src/backend/utils/cache/funccache.c
handle this, so that SQL functions could also benefit without
duplicated logic.
regards, tom lane
required modules when you say "make check" in those directories.
You broke that for src/test/isolation, and you should fix it.
It shouldn't be much harder than setting EXTRA_INSTALL in the
Makefile case; I dunno about meson.
regards, tom lane
n-lifespan
hash table. You could look at, for example, uncommitted_enum_types
in pg_enum.c for sample code.
regards, tom lane
's fine
for pg_stat_statements, it makes it really questionable to assume
that QueryId is a sufficient proof of semantic equivalence.
(I recall having objected to the whole concept of moving queryjumble.c
into core on the grounds that it could not serve multiple masters.
I think this proves my point...)
regards, tom lane
Jelte Fennema-Nio writes:
> On Sat, 16 Aug 2025 at 16:23, Tom Lane wrote:
>> So I don't really buy Álvaro's argument above. It'd be better
>> to design to some concrete requirement that isn't either of
>> those. Unfortunately, it's not clear to me
regards, tom lane
tatic code analysis. I'm +1 for just
dropping it altogether.
regards, tom lane
t
what shall we do about it?
regards, tom lane
tEventSetWaitBlock; I didn't look.
regards, tom lane
Noah Misch writes:
> On Sun, Aug 10, 2025 at 03:07:43PM -0400, Tom Lane wrote:
>> That's great news, but apparently there is some lag in new packages
>> actually becoming available for download:
> Hmm. I've never used MacPorts, so I'll probably not be an info
s of the concept:
src/backend/utils/adt/array_expanded.c
src/backend/utils/adt/expandedrecord.c
This thread that led to the v18 improvements might be useful too:
https://www.postgresql.org/message-id/flat/CACxu%3DvJaKFNsYxooSnW1wEgsAO5u_v1XYBacfVJ14wgJV_PYeg%40mail.gmail.com
regards, tom lane
t'd be better
to design to some concrete requirement that isn't either of
those. Unfortunately, it's not clear to me that anyone has
a concrete use-case in mind that isn't either of those.
regards, tom lane
gh at all?
I wouldn't expect so.
regards, tom lane
accumulate more data.
There are also cases where multiple finalfns can be called on the
same transition state, although that requires aggregates that share a
transfn, and I don't think jsonb_agg shares its transfn with anything
else.
See the discussion of FINALFUNC_MODIFY in the CREATE AGGREGATE man
page for more details.
regards, tom lane
n.
Not only that, but you'd no longer have any semblance of read-consistency
between the fields of a stats entry.
regards, tom lane
hat happens
when a non-null "outcontext" is specified in the JsonbInState.
No callers exercise that option in this patch, but the next
patch in the series will make use of it.
If we didn't add the outcontext option in this step, we'd just
have to do so in the next one.
regards, tom lane
shouldn't let
that drive the fundamental design.
regards, tom lane
.
Have you considered partitioning these tables by date and then not
dumping the older partitions? That would fit into existing
functionality a lot better.
regards, tom lane
are optimizations where
it'll be applied more than once.
regards, tom lane
1 - 100 of 2906 matches
Mail list logo
