a non-Postgres server starting up at the wrong time.
regards, tom lane
these branches.
regards, tom lane
ally want to change
it, that might be worth checking somehow before we jump.
regards, tom lane
o cause
a different error. We might find additional problems once this patch
hits the buildfarm or gets out into the field.
I'll park this in the next CF.
regards, tom lane
diff --git a/doc/src/sgml/pltcl.sgml b/doc/src/sgml/pltcl.sgml
index b31f2c1330..64c4918419 100644
Erik Wienhold writes:
> On 2024-06-03 18:57 +0200, Tom Lane wrote:
>> So your thought that we should just not use throw_tcl_error here
>> was correct, and a minimal fix could look like the attached.
> LGTM.
Pushed, thanks.
regards, tom lane
Nathan Bossart writes:
> On Tue, Jun 04, 2024 at 02:28:43PM -0400, Tom Lane wrote:
>> Hence, new patch attached, now with docs and tests. Barring
>> objections I'll push this one.
> Should we expand the documentation for SPI_connect_ext() to note that
>
pattern.
Hence, new patch attached, now with docs and tests. Barring
objections I'll push this one.
regards, tom lane
diff --git a/doc/src/sgml/spi.sgml b/doc/src/sgml/spi.sgml
index bb3778688b..7d154914b9 100644
--- a/doc/src/sgml/spi.sgml
+++ b/doc/src/s
s unwillingness to assume that Apple hasn't randomly
fixed or broken stuff across toolchain versions. Their track record
fully justifies that lack of trust.
regards, tom lane
f
time on the idea that _SPI_execute_plan() was doing things wrong,
and that led me to notice that its comment about having four modes
of snapshot operation has been falsified in multiple ways. So this
draft does include fixes for that comment.
Thoughts?
regards, tom lane
diff -
zeroes. So to the extent that zero is an okay value for
such a new field, that can help --- but if zero were always okay
then we'd likely not need a new field in the first place.
regards, tom lane
Peter Eisentraut writes:
> On 02.06.24 21:46, Tom Lane wrote:
>> If you don't
>> like our current behavior, then either you have to say that RETURNING
>> with a length-limited target type is illegal (which is problematic
>> for the spec, since they have no such typ
Erik Wienhold writes:
> On 2024-06-03 00:15 +0200, Tom Lane wrote:
>> The new bit of information that this bug report provides is that it's
>> possible to get a TCL_ERROR result without Tcl having set errorInfo.
>> That seems a tad odd, and it must happen only in weird corne
Peter Eisentraut writes:
> On 29.05.24 18:44, Tom Lane wrote:
>> Yeah, I too think this is a cast, and truncation is the spec-defined
>> behavior for casting to varchar with a specific length limit.
> The SQL standard says essentially that the output of json_serialize()
where the same case is handled like this:
Hm, I wonder why that's not using throw_tcl_error. I guess because
it wants to give its own primary message, but still ...
regards, tom lane
substitution of $(TESTS) for --schedule.
But I suggest that those behaviors have stood for a long time and
so the appropriate thing to do is duplicate them as best we can,
not invent something different.
regards, tom lane
rn [list $aa $aa])
> $$;
> CALL test_proc5('abc');
> CREATE EXTENSION
> CREATE PROCEDURE
> server closed the connection unexpectedly
Replicated here. I'll look into it later if nobody beats me
to it. Thanks for the report!
regards, tom lane
ve ever seen a real-world case with
intentionally-duplicate unique indexes.
So on the whole I'm unconvinced that this is worth changing.
regards, tom lane
eason that this should work differently from
select json_serialize('{"a":1, "a":2}' returning text)::varchar(5);
json_serialize
{"a":
(1 row)
regards, tom lane
/MacOSX14.2.sdk/usr/include/string.h
but I wonder if maybe the actual OS version is back-rev?
regards, tom lane
ump doesn't
see these bogus ACLs.
regards, tom lane
ger applicable.
Note that any change in behavior there would affect prepared
statements in general, not only plpgsql.
regards, tom lane
r
for giant tables.)
regards, tom lane
problem that the
existing code does notice: if blocknum is close to UINT32_MAX
and adding nblocks causes it to wrap around to a small value.
Is there an inexpensive way to catch that? (If not, it's
not a reason to block this patch; but let's think about it
while we're here.)
regards, tom lane
w much of that is practical to fix in v17, seeing that
it's all long-standing bugs and we're already past beta1.
I kind of doubt that the answer to #2 is "all of it".
But perhaps we can do better than "none of it".
regards, tom lane
that change query
semantics are an awful idea? Pick a single access method
for these things and stick to it.
regards, tom lane
bgroups of 3 or 4 people sounds about right. And definitely
some advance looking to see which patches need discussion.
regards, tom lane
Joe Conway writes:
> On 5/24/24 15:45, Tom Lane wrote:
>> I was *not* proposing doing a regular review, unless of course
>> somebody really wants to do that. What I am thinking about is
>> suggesting how to make progress on patches that are stuck, or in some
>> ca
Robert Haas writes:
> On Fri, May 24, 2024 at 2:57 PM Tom Lane wrote:
>> Doesn't seem right to me. That will give pg_dump the wrong idea
>> of what the initial privileges actually were, and I don't see how
>> it can construct correct delta GRANT/REVOKE on the basis of
Tomas Vondra writes:
> On 5/24/24 19:09, Tom Lane wrote:
>>>> ... Maybe we could divide and conquer: get a
>>>> dozen-or-so senior contributors to split up the list of pending
>>>> patches and then look at each one with an eye to what needs to
>&g
The partition_split test has unstable results, as shown at [1].
I suggest adding "ORDER BY conname" to the two queries shown
to fail there. Better look at other queries in the test for
possible similar problems, too.
regards, tom lane
Robert Haas writes:
> On Fri, May 24, 2024 at 11:59 AM Tom Lane wrote:
>> So this goal seems to
>> mean that neither ALTER OWNER nor REASSIGN OWNED should touch
>> pg_init_privs at all, as that would break its function of recording
>> a historical state. Onl
or it never did apply to frontend programs. But it doesn't
seem to me to be a great thing for it to behave like this.
You could easily miss that you have a broken setup until
after you deploy it.
regards, tom lane
Tomas Vondra writes:
> On 5/20/24 16:16, Robert Haas wrote:
>> On Sun, May 19, 2024 at 3:18 PM Tom Lane wrote:
>>> * Before starting this thread, Robert did a lot of very valuable
>>> review of some individual patches. I think what prompted him to
>>>
Daniel Gustafsson writes:
> On 24 May 2024, at 16:20, Tom Lane wrote:
>> Another point: shdepReassignOwned explicitly does not touch grants
>> or default ACLs. It feels like the same should be true of
>> pg_init_privs entries,
> Agreed, I can't see why pg_init
eah, good idea. Let's get some more feedback on this before I code up
> a complicated list parser.
Kinda doubt it's worth the trouble, either to code the GUC support or
to use it. I don't object to having the booleans in a debug build,
I was just concerned about whether they should exist in production.
regards, tom lane
does so they will not be tracked as part of the
extension". Presumably, that also means that no pg_init_privs
entries are made; but do we do that correctly?
Anyway, -ENOCAFFEINE for the moment. I'll look more later.
regards, tom lane
ogs are too loose, not too tight.)
regards, tom lane
he implied join has no relid.
regards, tom lane
le).
*/
typedef Bitmapset *Relids;
Repeating that everyplace the term "relid" appears would not be
tremendously helpful.
regards, tom lane
separate section, it would come before
'Source code'?
I am not sure Bruce that you realize that your disregard for
performance improvements is shared by nobody. Arguably,
performance is 90% of what we do these days, and it's also
90% of what users care about.
regards, tom lane
Hannu Krosing writes:
> While the 'DROP OWNED BY fails to clean out pg_init_privs grants'
> issue is now fixed,we have a similar issue with REASSIGN OWNED BY that
> is still there:
Ugh, how embarrassing. I'll take a look tomorrow, if no one
beats me to it.
reg
s of it that could be factored out
and shared, but I bet not a lot.
regards, tom lane
verlapping, an assumption not yet justified by evidence;
but we could do something more complicated if we have to.)
regards, tom lane
r to me that protocol
parameters should be exposed at the SQL level at all; but if we
don't feel they need to be available via SHOW and pg_settings,
what benefit is guc.c really bringing to the table?
regards, tom lane
y on
any modern system, but I'm unexcited about trying to find out.
regards, tom lane
se tuples.
The more duplicate-keyed tuples on the outer side, the bigger the
effect.
You can see the same thing happening at the Materialize a little
further up, which is feeding the inside of the other merge join.
regards, tom lane
ill means what it
meant before. Also, table aliases (as opposed to actual table names)
don't change readily, so I don't think there's much risk of the query
suddenly meaning something different than it did yesterday.
regards, tom lane
which would result in
> PostgreSQL crashing.
To clarify: the rule is that it's only allowed to pass NoLock if you
know for certain that some suitable lock on that relation is already
held by the current query. That's why these conditions are complicated.
regards, tom lane
arguments are, but that all ought to be propagated
into the --help output for the wrapper script. Right now you
couldn't figure out how to use the wrapper without reading the
underlying module.
regards, tom lane
orted values seem pretty substantially off, though ---
5293917674 would be barely an hour and a half later than the
epoch, which seems unlikely to be the value Sushrut intended
to test with. I suspect a mistake that's outside the fragment
of code we were shown.
regards, tom lane
read_parse_plan_trees
> debug_raw_expression_coverage_test
I'm kind of down on this. It seems like forcing a bunch of
useless-in-production debug support into the standard build.
What of this would be of any use to any non-developer?
regards, tom lane
,
so rejecting parameter numbers above 32K would make sense to me.
regards, tom lane
Bruce Momjian writes:
> On Sun, May 19, 2024 at 03:18:11PM -0400, Tom Lane wrote:
>> * Another reason for things sitting a long time is that they're too
>> big to review without an unreasonable amount of effort. We should
>> encourage authors to break large patches
tes folks to review patches, figure out status of a
> complicated patch thread, maintain a list of open items, etc?
Yeah, all this stuff ultimately gets done "for the good of the
project", which isn't the most reliable motivation perhaps.
I don't see a better one...
regards, tom lane
beta with, but it's far from
being good enough to ship, IMO. If there were active work going
on to fix these things, I'd feel better, but neither the C code
nor the test script have been touched since 1 April.
regards, tom lane
[1]
https://buildfarm.postgresql.org/cgi
e the
> release.
Per the cfbot [1], this patch needs a rebase over the ALPN-related
commits. It still isn't likely to get human attention before the
July commitfest, but you can save some time by making sure it's
in a reviewable state before that.
regards,
ign on the
purely hypothetical basis that this might happen.
> I think what Amit had before your objection was starting to turn into
> something workable and we should switch back to working on that.
The reason I posted this idea was that I didn't think the previously
existing patch looked promising at all.
regards, tom lane
Thomas Munro writes:
> Oops, right I didn't know we had that documented. Thanks. Will hold
> off doing anything until the thaw.
FWIW, I don't think the release freeze precludes docs-only fixes.
But if you prefer to sit on this, that's fine too.
regards, tom lane
Andrew Dunstan writes:
> I've pushed a small change, that should just mark with an asterisk any
> gitref that is more than 2 days older than the tip of the branch at the
> time of reporting.
Thanks!
regards, tom lane
*
want to go.
regards, tom lane
ts. If we tried to make the project's
files be the union of all those lists, we'd be at serious risk
of ignoring stuff we absolutely shouldn't ignore in some contexts.
regards, tom lane
even exist yet.
I won't complain too loudly as long as we remember to revert the
patch from HEAD once the ecpg fix goes in.
regards, tom lane
cause it would take far too much effort to
figure out how much work anyone else is doing. I see CFMs reminding
everybody that this rule exists, but I don't think they ever try to
check it either. It's pretty much the honor system, and I'm sure
some folk ignore it.
regards, tom lane
se don't complain about build time.)
I grant that there are people who are more affected, but still, I'd
just as soon not contort the build rules for a temporary problem.
regards, tom lane
for this hint
to be exhaustive. I could get behind your suggestion of
s/You must specify/Specify/, but I also think it's fine to do nothing.
regards, tom lane
that, but it's still not a good thing.) Maybe it's
time to introduce a system view for such things? It could be really
simple, with name and value, or we could try to steal some additional
ideas such as units from pg_settings.
regards, tom lane
release
freeze to mess with it, but I'd support pushing Thomas'
proposed patch after the freeze is over.
regards, tom lane
was that we didn't exit
a CF until it was empty of un-handled patches, so obviously allowing
new patches to come in would mean we'd never get to empty. That idea
didn't work and we don't think that way anymore.
So yeah, I'm okay with abandoning the must-submit-to-a-future-CF
restriction.
regards, tom lane
valuable but different. Maybe call it
"pending" or such? Or invent a different name for the other thing.
regards, tom lane
Peter Eisentraut writes:
> On 16.05.24 16:45, Tom Lane wrote:
>> Yeah, that was bothering me too, but I went for the minimum delta.
>> I did think that a couple of integer macros would be a better idea,
>> so +1 for what you did here.
> I committed thi
Robert Haas writes:
> On Fri, May 17, 2024 at 10:31 AM Tom Lane wrote:
>> If we go back to the old its-development-mode-all-the-time approach,
>> what is likely to happen is that the commit rate for not-your-own-
>> patches goes to zero, because it's always possible to ra
CF open until the backlog actually went to zero,
which resulted in multi-month death-march CFs and no clarity
at all as to release timing. Let's not go back to that.
But the CF app was probably built with that model in mind.
regards, tom lane
Michael Paquier writes:
> On Thu, May 16, 2024 at 10:45:18AM -0400, Tom Lane wrote:
>> ... I think the enum should be nuked altogether, but
>> it's a bit late to be redesigning that for v17 perhaps.
> You're right, WaitEventExtension is better gone. The only thing that
> ma
Peter Eisentraut writes:
> On 16.05.24 23:46, Tom Lane wrote:
>> Right, so what can we do about that? Does Needs Review state need to
>> be subdivided, and if so how?
> Maybe a new state "Unclear". ...
> I think, if we consider the core mission of the commit
Probably
that would have to happen first, but there would be a lot of benefit
from having the info flow be two-way.
regards, tom lane
we need to keep thinking about what should be improved.
regards, tom lane
Andrew Dunstan writes:
> On 2024-05-16 Th 17:15, Tom Lane wrote:
>> I'd rather have some visible status on the BF dashboard. Invariably,
>> with a problem like this, the animal's owner is unaware there's a
>> problem. If it's just silently not reporting, then no one else
Andrew Dunstan writes:
> On 2024-05-16 Th 16:18, Tom Lane wrote:
>> Andrew: maybe the buildfarm server could be made to flag
>> animals building exceedingly old commits? This is the second
>> problem of this sort that I've noticed this month, and you
>> really have
abandoned by their authors. Our problem is the same as it's
been for many years: not enough review person-power, rather than
not enough patches. So I think authors would just jump through that
hoop, or enough of them would that it wouldn't improve matters.
regards, tom lane
ereupon it wouldn't
be impolite for someone else to sign up for active review.
regards, tom lane
ke the app very tempting
infrastructure for parked patches. Maybe we could have a not-the-CF
app that offers those amenities?
regards, tom lane
tes\"=\"off\" was replayed "
but that's a bit much for my taste.
regards, tom lane
o look closely to realize it's happening.
regards, tom lane
lived entries like that don't seem
like they're a big problem beyond possibly skewing the CF statistics
a bit. It's the stuff that keeps hanging around that seems like
the core of the issue.
>> I spent a good deal of time going through the CommitFest this week
> And you deserve a big Thank You for that.
+ many
regards, tom lane
Andres Freund writes:
> On 2024-05-16 14:50:50 -0400, Tom Lane wrote:
>> The intention was certainly always that it be atomic. If it isn't
>> we have got *big* trouble.
> We unfortunately do *know* that on several systems e.g. basebackup can read a
> partially writte
he buildfarm for any other occurrences. I
> also seem some threads concerning whether the way we are reading/writing
> the control file is atomic.
The intention was certainly always that it be atomic. If it isn't
we have got *big* trouble.
regards, tom lane
Daniel Gustafsson writes:
>> On 5 Jul 2022, at 18:59, Tom Lane wrote:
>> Given the lack of field complaints, it's probably not worth trying
>> to do anything to restore that capability. But we really ought to
>> update pg_upgrade's code and docs in pre-v15 branches to
within nearby
examples, but I don't agree at all that it should be uniform
across all our docs.
regards, tom lane
I'm good with this, with a mental note to look again at
WaitEventExtension later.
regards, tom lane
ttle the worse off notationally. I experimented
with a patch for that, as attached. (In the case of NotificationHash,
I thought it better to arrange for there to be a suitable variable;
but it could certainly be done the other way too.) Is this too anal?
regards, tom lane
rposition or something?
No, it's the dependence on the physical library file name that's
bothering me. Maybe that won't be an issue, but I foresee requests
like "would you please case-fold it" or "the extension-trimming rule
isn't quite right", etc.
regards, tom lane
o
both kinds of indent runs, but it's not clear to me that that's
obvious in v3. Maybe the steps should be rearranged to be
(1) base case, (2) VALIDATION, (3) ONCE PER CYCLE.
At this point my OCD got the better of me and I did a little
additional wordsmithing. How about the attached?
+ReadBuffersFlags
+ResourceOwnerData
+WaitEventExtension
+WalSyncMethod
I believe all of these must have been added manually during v17.
If I took any one of them out there was some visible disimprovement
in pgindent's results, so I kept them. Was that the right decision?
If so we should explain it here.
regards, tom lane
s side, once you'd bought into that environment,
it'd be equally trivial to offer alternatives like "run raw
parsing and parse analysis, but don't run the query". I continue
to maintain that that's the set of checks you'd really want in a
lot of use-cases.
regards, tom lane
Robert Haas writes:
> On Wed, May 15, 2024 at 2:39 PM Tom Lane wrote:
>> The thing that was bothering me most about this is that I don't
>> understand why that's a useful check. ...
> But I don't understand the idea that the concept doesn't make sense.
Sorry: "make sen
ress that problem just by making sure to provide
a documentation example that shows use of "N".
> An English speaker is more likely to understand what is meant by
> "N'th" than what is meant by "count'th".
+1 ... none of the proposals make that bit read more clearly
than it does now.
regards, tom lane
walt...@technowledgy.de writes:
> Tom Lane:
>> BTW, if you do feel that a pure grammar check is worthwhile, you
>> should look at the ecpg preprocessor, which does more or less that
>> with the SQL portions of its input.
> Would working with ecpg allow to get back a
ust fixing what Coverity complained about.
I wonder why it missed this; it does seem to understand that PGresult
leaks are a thing. But anyway, I missed it too.
regards, tom lane
lts are pretty approximate anyway, ISTM. We've not heard
anything suggesting that version skew is a huge problem for
ecpg users.
regards, tom lane
st certainly
going to have a bunch of platform-specific problems to solve.
So I think Peter's thought is worth pursuing.
regards, tom lane
1 - 100 of 15274 matches
Mail list logo
