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
Peter Eisentraut writes:
> On 14.05.24 01:11, Tom Lane wrote:
>> The mechanism that Andres describes for sourcing the name seems a bit
>> overcomplex though. Why not just allow/require each extension to
>> specify its name as a constant string? We could force the ma
ng but .c and .h files.
I do recommend running "git diff --check" (with --staged if you
already git-added your changes) before you're ready to commit
something. That does find generic whitespace issues, and I
believe it would've found this one.
regards, tom lane
let's avoid changing
that existing behavior.
regards, tom lane
updating those files would only be possible for whoever
owns the github repo. I don't have a position on whether we want
these additional files or not; but if we do, I think the best answer
is to stick 'em under .github/ where they are out of the way but yet
updatable by any committer.
regards, tom lane
e to install manually if you want to debug a particular
package. This is good for disk space consumption, but it means that
most users are still only going to see the same backtrace they see
currently.
I don't know how much of that applies to, eg, Debian.
regards, tom lane
dely enough
useful to justify creating a special mode beyond what we already
have.
regards, tom lane
t's
> intentionally not supported. I can't believe it would ever be useful,
> and the current behaviour is clearly broken.
+1, let's put this back the way it was.
regards, tom lane
Alexander Lakhin writes:
> 13.05.2024 23:17, Tom Lane wrote:
>> 3. We don't know exactly why hamerkop suddenly started seeing these
>> failures, but a plausible theory emerges after noting that its
>> reported time for the successful "make check" step dropped pre
ike we wrote off the other issue as a compiler bug,
so I don't have much trouble assuming that this one was too.
regards, tom lane
ot just allow/require each extension to
specify its name as a constant string? We could force the matter by
redefining PG_MODULE_MAGIC as taking an argument:
PG_MODULE_MAGIC("hstore");
regards, tom lane
around here with
access to the relevant source code.
In the short run, it might be a good idea to deprecate using
--with-gssapi on Windows builds. A different stopgap idea
could be to drastically reduce the default AuthenticationTimeout,
perhaps only on Windows.
regards, tom
; result set in the first place.
Sounds a lot like a WHERE clause to me.
regards, tom lane
small chance some external code is using
COMMAND_TAG_NEXTTAG for the same purpose tag_behavior[] does.
But we aren't anywhere near declaring v17's API stable, so
I'd rather fix the issue than dismiss it in HEAD.
regards, tom lane
=?utf-8?Q?Dagfinn_Ilmari_Manns=C3=A5ker?= writes:
> Tom Lane writes:
>> I'm fairly down on this idea for SQL, because I think it creates
>> ambiguity for the ROW() constructor syntax. That is:
>> (x,y) is understood to be shorthand for ROW(x,y)
>> (x)
Matthias van de Meent writes:
> PFA a patch that fixes this issue, by assuming that all pages in the
> source database utilize a non-standard page layout.
Surely that cure is worse than the disease?
regards, tom lane
front of the committee in this area.
regards, tom lane
David Rowley writes:
> On Mon, 6 May 2024 at 15:06, Tom Lane wrote:
>> My best guess is that that changed the amount of WAL generated by
>> initdb just enough to make the problem reproduce on this animal.
>> However, why's it *only* happening on this animal? The amount
as dead as AIX, in terms of
anybody being willing to put effort into supporting it?
regards, tom lane
Peter Geoghegan writes:
> On Sat, May 11, 2024 at 4:21 PM Tom Lane wrote:
>>> There's another problem along these lines, that seems at least as bad:
>>> queries involving contradictory >= and <= quals aren't recognized as
>>> contradictory during
Peter Geoghegan writes:
> On Sat, May 11, 2024 at 3:19 PM Tom Lane wrote:
>> However, despite the rather over-the-top verbosity of commenting in
>> _bt_advance_array_keys, it's far from clear why or how it depends on
>> that. So I feel a little stuck about what
1 - 100 of 15254 matches
Mail list logo
