] Apparently I managed to hit ^K right before sending this
email. The missing line was meant to be more or less
> which found a couple of missing "break"
Not too important, but perhaps future readers of the archives will
be confused.
regards, tom lane
I'm still not happy with what you did in predicate_refuted_by_recurse:
it feels wrong and rather expensively so. There has to be a better
way. Maybe strong vs. weak isn't quite the right formulation for
refutation tests?
regards, tom lane
diff --git a/src/backend/optimizer/u
David Rowley writes:
> On Tue, 26 Mar 2024 at 03:53, Tom Lane wrote:
>> Could we move the knowledge of exactly which context type it is out
>> of the per-chunk header and keep it in the block header?
> I wasn't 100% clear on your opinion about using 010 vs expanding the
ld include teaching the server
to ignore postgresql.auto.conf altogether, which would make it
relatively easy to get to a bulletproof configuration.
regards, tom lane
u don't
back it up with filesystem-level controls.
regards, tom lane
able to postponing
creation of the subplans, as we speculated about earlier. (I have
no near-term desire to actually do that, but maybe someday it will
happen.)
regards, tom lane
Robert Haas writes:
> On Sat, Mar 23, 2024 at 12:31 PM Tom Lane wrote:
>> However, the calling logic seems a bit shy of a load, in that it
>> trusts IsInParallelMode() completely to decide whether to check for
>> leaked parallel contexts. So we'd miss the ca
eems to
be about two days.
regards, tom lane
n air, and I have
no certainty that it's even within an order of magnitude of being a
good choice.
* Code needs more than zero comments.
* Is it worth trying to make a subroutine, or at least a macro,
so as not to have 2 copies of the code?
regards, tom lane
odID bits to allow having a small number of different
ways, perhaps.
regards, tom lane
g, but if I'm right it
will do nothing to prevent that crash. This needs a bit more effort.
regards, tom lane
regards, tom lane
odules.
regards, tom lane
Masahiko Sawada writes:
> On Mon, Mar 25, 2024 at 1:53 AM Tom Lane wrote:
>> I think the point here is that if you start with an arbitrary
>> non-negative shift value, the preceding loop may in fact decrement it
>> down to something less than zero before exiting, in which ca
Andrew Dunstan writes:
> On Sat, Mar 23, 2024 at 3:00 PM Tom Lane wrote:
>> So I'm glad we found that sooner not later, but something needs
>> to be done about it if [1] is to get committed. It doesn't seem
>> particularly hard to fix though: we just have to track the e
er
hard-code that?
- n4->chunks[0] = RT_GET_KEY_CHUNK(key, shift);
+ n4->chunks[0] = RT_GET_KEY_CHUNK(key, 0);
regards, tom lane
chipmunk is still failing in
HEAD and v16. Can we please have a fix? I'm good with Heikki's
adjustment to the pg_visibility test case.
regards, tom lane
I propose the attached.
regards, tom lane
[1] https://commitfest.postgresql.org/47/4713/
diff --git a/src/backend/catalog/pg_enum.c b/src/backend/catalog/pg_enum.c
index d2fe5ca2c8..7768bc97c3 100644
--- a/src/backend/catalog/pg_enum.c
+++ b/src/backend/catalog/pg_enum.c
Robert Haas writes:
> On Fri, Mar 22, 2024 at 4:37 PM Tom Lane wrote:
>> I think these things are already dealt with. However, one thing
>> worth questioning is that CommitSubTransaction() will just silently
>> kill any workers started during the current
step. Or you could
do
if (record_cmp(fcinfo) > 0)
PG_RETURN_DATUM(PG_GETARG_DATUM(0));
else
PG_RETURN_DATUM(PG_GETARG_DATUM(1));
because really there's no point in detoasting at all.
regards, tom lane
urn would be
substantial and the gain minimal. But we could imagine reimplementing
that stuff atop and then getting rid of the configure-time
probes.
regards, tom lane
Jeff Davis writes:
> On Fri, 2024-03-22 at 12:28 -0400, Tom Lane wrote:
>> Thanks for the report. I did some bisecting and found that the crash
>> appears at Jeff's commit c8aeaf3ab (which introduced this assertion)
>> and disappears at Heikki's c4649cce3 (which removed it
a great usability improvement. Prompt space is
expensive and precious, at least for people who aren't in the
habit of working in very wide windows.
regards, tom lane
I could get behind throwing an error if -Werror is spotted. I think
trying to pull it out and put it back is too much work and a bit
too much magic.
regards, tom lane
Nathan Bossart writes:
> On Fri, Mar 22, 2024 at 11:54:48AM -0500, Nathan Bossart wrote:
>> On Fri, Mar 22, 2024 at 12:53:15PM -0400, Tom Lane wrote:
>>> Would you like to review the catcache patch further, or do you
>>> think it's good to go?
>> I'll take ano
rporate the plpython
crash that started this thread, as it's weird and dependent on
Python code outside our control (though I have checked that we
don't crash on that anymore).
regards, tom lane
diff --git a/doc/src/sgml/parallel.sgml b/doc/src/sgml/parallel.sgml
index 5acc953
e seems like a job for another patch.)
regards, tom lane
's a problem would be difficult.
The short answer is that Autoconf is not designed to support -Werror
and it's not worth it to try to make it do so.
regards, tom lane
o COPT, so it'd likely be safe to keep that set all the time, but in
the buildfarm client it's just as easy to be conservative.
regards, tom lane
[1] https://www.postgresql.org/docs/devel/install-make.html#CONFIGURE-ENVVARS
Nathan Bossart writes:
> On Fri, Mar 22, 2024 at 11:27:46AM -0400, Tom Lane wrote:
>> * Do we want to risk back-patching any of this, to fix the performance
>> regression in v16? I think that the OP's situation is a pretty
>> narrow one, but maybe he's not the only person
cleanup, when there's
no very good reason to assume that the tapeset's been closed down
cleanly. (To be clear, that's not what's happening in the given
test case ... but I fear that it could.)
regards, tom lane
Robert Haas writes:
> On Fri, Dec 29, 2023 at 12:56 PM Tom Lane wrote:
>> Here's a draft patch along this line. Basically the idea is that
>> subtransactions used for error control are now legal in parallel
>> mode (including in parallel workers) so long as they do
only person who managed to dodge
roles_is_member_of's performance issues in most other cases.
regards, tom lane
), I don't think it would be much
more than a finger exercise [*]. And why would you want it to act
any differently from record_cmp()? Those semantics have been
established for a long time.
regards, tom lane
[*] Although conceivably there are some challenges in getti
}
roles_list = lappend_oid(roles_list, otherid);
if (bf)
bloom_add_element(bf, (unsigned char *) , sizeof(Oid));
}
regards, tom lane
Nathan Bossart writes:
> On Thu, Mar 21, 2024 at 03:40:12PM -0500, Nathan Bossart wrote:
>> On Thu, Mar 21, 2024 at 04:31:45PM -0400, Tom Lane wrote:
>>> I don't think we have any really cheap way to de-duplicate the role
>>> OIDs, especially seeing that it has t
Vik Fearing writes:
> On 3/22/24 00:17, Tom Lane wrote:
>> Vik Fearing writes:
>>> As also said somewhere in that thread, I think that
>>> short-cutting a NULL input value without considering the constraints of
>>> a domain is a bug that needs to be fix
Vik Fearing writes:
> On 3/21/24 15:30, Tom Lane wrote:
>> The SQL spec's answer to that conundrum appears to be "NULL is
>> a valid value of every domain, and if you don't like it, tough".
> I don't see how you can infer this from the standard at all.
I believe wh
y_extended((unsigned char *)
> al->name, al->len, seed));
> uint32 levelHash = DatumGetUInt32(hash_any((unsigned char *) al->name,
> al->len));
Yeah, that'd fail on 32-bit machines.
Pushed v5 with some minor cosmetic tweaking.
regards, tom lane
the bool transform is nearly as bad, but we
could improve that too while we're at it.)
regards, tom lane
a lot of
work.
regards, tom lane
This helps a good
deal, but I still see the problematic GRANT taking ~250ms, compared
to 5ms in v15. roles_is_member_of is clearly on the hook for that.
regards, tom lane
diff --git a/src/backend/utils/cache/catcache.c b/src/backend/utils/cache/catcache.c
index d5a3c1b59
case so that they dodge these
implementation problems in v15 and earlier, but that's a far cry from
saying that there were no problems with lots-o-roles before v16.
regards, tom lane
the problem. The complaint is that the last GRANT
takes multiple seconds (about 5s on my machine), rather than
milliseconds.
regards, tom lane
#!/bin/bash
echo "CREATE ROLE acc WITH LOGIN NOSUPERUSER INHERIT CREATEDB CREATEROLE NOREPLICATION;" > create-roles.sql
#crea
omain (succeed
immediately if input is NULL), but the question is what to do
with existing "DOMAIN NOT NULL" DDL.
Anyway, now that I recall all that, e5da0fe3c is throwing good work
after bad, and I wonder if we shouldn't revert it.
regards, tom lane
n
bring a bunch of work to fix all the problems noted in the discussion
thread, and commit to providing ongoing development manpower and
hardware to keep it working, maybe something could happen. But I
suspect you will find it cheaper to start thinking about migrating
off AIX.
regards, tom lane
l precedent: have a file corresponding to the
chapter and containing any top-level text we need, then that includes
a file per sect1.
regards, tom lane
tests.
regards, tom lane
gh it is autovacuum, and there's some environment-specific
enabling condition that parula has and my machine doesn't (which
could also help explain why no other animal is doing this).
So yeah, if we could have log_autovacuum_min_duration = 0 perhaps
that would yield a clue.
regards, tom lane
you've got relics of a structure that doesn't exist any more
> sticking around forever.
I'd say that a separate file per AM is a good thing regardless.
Elsewhere in this same thread are grumblings about how big func.sgml
is; why would you think it good to start down that same path for the
AM documentation?
regards, tom lane
t emitting -1 for no typmod, and documented that explicitly.
regards, tom lane
red to this quick hack.
Thoughts?
regards, tom lane
[1]
https://www.postgresql.org/message-id/60EF4E11-BC1C-4034-B37B-695662D28AD2%40justatheory.com
diff --git a/src/backend/catalog/Catalog.pm b/src/backend/catalog/Catalog.pm
index 55a8877aed..f4b13b600d 100644
--- a/src/back
valid member of the enum. But
in any case, exactly how much value do these assertions carry?
If you're intent on keeping them, perhaps casting child_type to
int here would suppress the warnings. But personally I think
I'd lose the Asserts.
regards, tom lane
ity of ssl_key_file).
It's off-topic for this thread though.
regards, tom lane
Dean Rasheed writes:
> Fair enough. I have no further comments.
Pushed then. Thanks for reviewing! I gave you credit as co-author.
regards, tom lane
t eager to write it though.)
I had actually had a similar thought about sticking ".col1" onto
EXPR_SUBLINK cases, but I concluded it was mostly pedantry.
Nobody's likely to get confused.
regards, tom lane
But it'd do for starters.
I'm not super thrilled by the fact that the patch contains zero
user-facing documentation, even though it's created new SQL syntax,
not to mention a new postgres_fdw option. I assume this means that
nobody thinks it's anywhere near ready to commit.
regards, tom lane
y this wasn't happening before. I scraped the
buildfarm logs for 3 months back and confirmed my impression that
this is a new failure mode. But one of these four runs is on
REL_14_STABLE, eliminating the theory that the cause is a recent
HEAD-only change.
Any ideas?
Richard Guo writes:
> Here is the patch for HEAD. I simply re-posted v10. Nothing has
> changed.
I got back to this finally, and pushed it with some minor cosmetic
adjustments.
regards, tom lane
I wrote:
> I won't update the patch right now, but "(rescan SubPlan N)"
> seems like a winner to me.
Here's a hopefully-final version that makes that adjustment and
tweaks a couple of comments.
regards, tom lane
diff --git a/contrib/postgres_fdw/expected/
Jelte Fennema-Nio writes:
> On Tue, 19 Mar 2024 at 15:52, Tom Lane wrote:
>> I like this idea. The "bonus" is not optional though, because
>> setting the files' ownership/permissions is the only way to be
>> sure that the prohibition is even a little bi
looks like real file permissions?
Another question is whether this should be one-size-fits-all for
all the configuration files. I can imagine situations where
you'd like to lock down postgresql[.auto].conf but not pg_hba.conf.
But maybe that can wait for somebody to show up with a use-case.
regards, tom lane
ll the way down to the 7.2 docs online has it) so
> maybe
> it was intentional?
I'm quite sure it *was* intentional. Maybe it was a bad idea, but
it's not that way simply because nobody thought about it.
regards, tom lane
s is the tablespace
in which partitions will be created when one is not
specified in the creation command.
regards, tom lane
Thomas Munro writes:
> On Tue, Mar 19, 2024 at 11:55 AM Tom Lane wrote:
>>>> This is causing all CI jobs to fail the "compiler warnings" check.
>>> I did run CI before checkin, and it passed:
> Maybe I misunderstood this exchange but ...
> Currently
Dean Rasheed writes:
> On Mon, 18 Mar 2024 at 23:19, Tom Lane wrote:
>> After thinking a bit more, I understood what was bothering me about
>> that notation: it looks too much like a call of a user-defined
>> function named "rescan()". I think we'd be better o
I think we'd be better off with the
all-caps "RESCAN()".
regards, tom lane
Jeff Davis writes:
> On Mon, 2024-03-18 at 18:04 -0400, Tom Lane wrote:
>> This is causing all CI jobs to fail the "compiler warnings" check.
> I did run CI before checkin, and it passed:
> https://cirrus-ci.com/build/5382423490330624
Weird, why did it not report with
y suggestion, but: could we just render the
"most important" chapter titles in a larger font?
regards, tom lane
urn a value
This is causing all CI jobs to fail the "compiler warnings" check.
Probably the best fix is the traditional
return ;/* keep compiler quiet */
but I'm not sure what the best default result is in this function.
regards, tom lane
Robert Haas writes:
> On Sat, Mar 16, 2024 at 8:17 PM Tom Lane wrote:
>> Even taking the position that this is an unspecified point that we
>> could implement how we like, I don't think there's a sufficient
>> argument for changing behavior that's stood for a couple of deca
he attached, but it still looks
a bit odd to my eye.
I did some more work on the documentation too, to show the difference
between hashed and not-hashed subplans. I feel like we're pretty
close here, with the possible exception of how to show MULTIEXPR.
regards, tom
o me. I doubt that pg_basetype(pg_typeof())
is going to be so common as to need a shorthand.
regards, tom lane
or "127.0.0.1"
2024-03-17 23:11:30.990 UTC [106988][postmaster][:0] FATAL: could not create
any TCP/IP sockets
2024-03-17 23:11:30.993 UTC [106988][postmaster][:0] LOG: database system is
shut down
regards, tom lane
(errcode(ERRCODE_WRONG_OBJECT_TYPE),
2522 errmsg("encoding \"%s\" does not match
locale \"%s\"",
2523
pg_encoding_to_char(encoding), locale)));
regards, tom lane
oes
there is to re-arm the SubPlan to be evaluated again on the next
pass through the targetlist. I'm not greatly in love with either
of those ideas, though. Any thoughts?
regards, tom lane
diff --git a/contrib/postgres_fdw/expected/postgres_fdw.out b/contrib/postgres
Dean Rasheed writes:
> On Sat, 16 Mar 2024 at 17:25, Tom Lane wrote:
>> After looking at your draft some more, it occurred to me that we're
>> not that far from getting rid of showing "$n" entirely in this
>> context. Instead of (subplan_name).$n, we could write
s.
(The spelling of the message has changed over the years, but giving a
warning not an error appears to go all the way back to 99b8f8451
where we implemented user groups.) It is certain that there are
applications out there that rely on this behavior and would break.
regards, tom lane
Laurenz Albe writes:
> On Fri, 2024-03-15 at 19:18 -0400, Tom Lane wrote:
>> This patch seems to have stalled out again. In hopes of getting it
>> over the finish line, I've done a bit more work to address the two
>> loose ends I felt were probably essential to deal with:
g this as a POC to see if this is the direction
people would like to go in. If there's not objections, I'll try to
make a bulletproof implementation.
regards, tom lane
diff --git a/contrib/postgres_fdw/expected/postgres_fdw.out b/contrib/postgres_fdw/expected/postgres_fdw.out
index 5
.
regards, tom lane
From 1df5cc3ffdee85db8f9815dc0839769192b57158 Mon Sep 17 00:00:00 2001
From: Tom Lane
Date: Fri, 26 Jan 2024 11:10:00 -0500
Subject: [PATCH v11 1/6] Some small preliminaries for pg_dump changes.
Centralize management of the lo_buf used to hold data while restoring
blobs
Heikki Linnakangas writes:
> On 15/03/2024 16:00, Tom Lane wrote:
>> It may be even worse than it appears from the buildfarm status page.
>> My animals were stuck in infinite loops that required a manual "kill"
>> to get out of, and it's reasonable to assume there
t this
point we can just debate proposed output without worrying about
how to implement it.)
regards, tom lane
to me, but anything based on elog is
likely to be problematic, because it'll involve exit()
somewhere.
regards, tom lane
arm status page.
My animals were stuck in infinite loops that required a manual "kill"
to get out of, and it's reasonable to assume there are others that
will require owner intervention. Why would this test have done that,
if the module failed to load?
regards, tom lane
e will get accepted. We have
a policy (and an enforcement mechanism) that libpq.so must not call
exit(). OAuth code in libpq will need to cope with using pqexpbuffer.
regards, tom lane
Michael Paquier writes:
> On Thu, Mar 14, 2024 at 06:19:38PM -0400, Tom Lane wrote:
>> I wonder if it'd be wise to adjust the injection point stuff so that
>> it's active in only the specific database the injection point was
>> activated in.
> It can be ma
Thomas Munro writes:
> On Fri, Mar 15, 2024 at 11:19 AM Tom Lane wrote:
>> Do they? It'd be fairly easy to explain this if these things were
>> being run in "installcheck" style. I'm not sure about CI, but from
>> memory, the buildfarm does use install
installcheck for some things.
Hmm, Munro's comment yesterday[1] says that current CI does use
installcheck mode in some cases.
regards, tom lane
[1]
https://www.postgresql.org/message-id/CA+hUKGJYhcG_o2nwSK6r01eOZJwNWUJUbX==avnw84f-+8y...@mail.gmail.com
if it'd be wise to adjust the injection point stuff so that
it's active in only the specific database the injection point was
activated in.
regards, tom lane
dae gets any more stable.
regards, tom lane
Robert Haas writes:
> On Thu, Mar 14, 2024 at 3:13 PM Tom Lane wrote:
>> With the possible exception of #1, every one of these is easily
>> defeatable by an uncooperative superuser. I'm not excited about
>> adding a "security" feature with such obvious holes in
r to build something with
fewer holes. I'm not against inventing such a feature,
but it'd take a fair amount of work and likely would end
in a noticeably less usable system (no plpython for example).
regards, tom lane
is about as content-free an error message as I've ever seen.
Even granting that it's developer-directed, it's still content-free:
we already know it's an error, and something must have triggered that,
but you're offering nothing about what. Can't we do better than that?
regards, tom lane
Jeremy Schneider writes:
> On 3/13/24 11:21 AM, Tom Lane wrote:
>> Agreed, we would probably add confusion not reduce it if we were to
>> change our longstanding nomenclature for this.
> Before v10, the quarterly maintenance updates were unambiguously and
> always called pa
greed, we would probably add confusion not reduce it if we were to
change our longstanding nomenclature for this.
I'm +1 on rewriting these documentation pages though. Seems like
they could do with a whole fresh start rather than just tweaks
around the edges --- what we've got now is an accumulation of such
tweaks.
regards, tom lane
g is that pretty soon there will be no difference,
ie distribution tarballs will have the same contents as a git pull
(less the .git infrastructure). If we're planning on making that
happen for 17, perhaps we'd better get on with it.
regards, tom lane
Andrew Dunstan writes:
> On 2024-03-12 Tu 18:59, Tom Lane wrote:
>> I wonder whether perlcritic has sufficiently deep understanding of
>> Perl code that it could find these hazards.
> Yeah, that was my thought too. I'd start with ProhibitComplexRegexes.pm
> as a template.
tilla, but other than that
I'm not seeing a connection. I suspect it's basically just a
timing dependency. Have you thought about the fact that a cancel
request is a no-op if it arrives after the query's done?
regards, tom lane
ere's no built-in filter for this (at least not
in the perlcritic version I have), but maybe we could write one?
The rules seem to be plug-in modules, so you can make your own
in principle.
regards, tom lane
501 - 600 of 15282 matches
Mail list logo
