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
with incomplete opfamilies. _bt_advance_array_keys
* depends on this.
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 needs to be done here.
order of business ought to be to create some
test cases that reach this area. Perhaps they'll be too expensive
to incorporate in our regular regression tests, but we could still
use them to investigate Mark's concerns.
regards, tom lane
ople might have internalized the fact that
it didn't work, or created complicated workarounds.
regards, tom lane
really informative about what other sessions are doing, we'd probably
have to hide them from unprivileged users in pg_stat_activity, and
then there'd also be a security concern here.)
On the whole I'd reject this proposal as causing churn in
application-visible behavior for very little gain.
regards, tom lane
of people trying to complete open items or revert failed patches,
but it's getting to be time. Any objections to doing these
things on Tuesday May 14th?
regards, tom lane
to be a test of an error case --- it looks like
just sloppily-verified testing to me. "block 3" must have been
dropped in after the tests before and after it were written,
without noticing that it changed their results.)
regards, tom lane
egards, tom lane
t how come we haven't noticed that
before? Have you added a setlocale() call somewhere?
regards, tom lane
oc/src/sgml
(which builds just the HTML docs) takes right about 30s in HEAD.
Can't believe that the overhead would be noticeably different
between make and meson, since it's a simple command sequence
with no opportunity for parallelism.
regards, tom lane
ecuted by child processes,
but should we try to move them somewhere else? Another idea could be
to add an Assert to SetProcessingMode that insists that it can't be
executed by the postmaster.
regards, tom lane
of the same relid set are grouped together, just like
> what we do in remove_rel_from_restrictinfo?
I left it alone, just because it didn't seem worth cluttering "git
blame" here.
regards, tom lane
t,
not just config reload. The postmaster log would have told you
that, but pg_reload_conf() can't really see the effects of its
signal.
regards, tom lane
Nathan Bossart writes:
> On Wed, May 08, 2024 at 07:42:18PM -0400, Tom Lane wrote:
>> One positive reason for increasing the number of parameters is that
>> that will be a clear API break for any outside callers, if there
>> are any. If I just replace a bool with an enu
the number of parameters is that
that will be a clear API break for any outside callers, if there
are any. If I just replace a bool with an enum, such callers might
or might not get any indication that they need to take a fresh
look.
regards, tom lane
o
can't believe that an extra fetch will be noticeable compared
to the cost of the adjacent bms_xxx operations.
regards, tom lane
David Rowley writes:
> On Thu, 9 May 2024 at 06:49, Tom Lane wrote:
>> BTW, now that I've wrapped my head around what's happening here,
>> I believe that -DREALLOCATE_BITMAPSETS is introducing a bug where
>> there was none before. The changes that left-join removal mak
is
pretty lame.
The attached patch fixes up the code and adds a new test to
the test_extensions module. The fix basically is to skip the
pg_depend entries for dependent types, assuming that they'll
get dealt with when we process their parent objects.
regards, tom lane
Nathan Bossart writes:
> Thanks for looking. I noticed that the version check is unnecessary since
> we always use the new binary's pg_dump[all], so I removed that in v2.
+1
regards, tom lane
that acts entirely different from
production bitmapset infrastructure.
regards, tom lane
trying to say that
sharing is disallowed.
Thoughts?
regards, tom lane
diff --git a/src/backend/optimizer/plan/initsplan.c b/src/backend/optimizer/plan/initsplan.c
index e2c68fe6f9..4198e9c83a 100644
--- a/src/backend/optimizer/plan/initsplan.c
+++ b/src/backend/optimizer
CORD return-type setup was stuck into PLy_function_build_args,
where it has no particular business being in the first place, rather
than being done at the point of use. We can just move the code.
regards, tom lane
diff --git a/src/pl/plpython/plpy_exec.c b/src/pl/plpython/pl
t;> be to break referential integrity. It is the trigger programmer's
>> responsibility to avoid that.
> That's perfect!
Hearing no further comments, done like that.
regards, tom lane
David Rowley writes:
> On Wed, 8 May 2024 at 10:55, Tom Lane wrote:
>> Not in a way that gives me any confidence that we found *all* the
>> problems.
> Here are some statements I believe to be true:
> 1. If REALLOCATE_BITMAPSETS is defined then modifications to a
> Bi
David Rowley writes:
> On Wed, 8 May 2024 at 10:40, Tom Lane wrote:
>> Didn't test, but that route seems awfully invasive and fragile: how
>> will we find all the places to modify, or ensure that the policy
>> is followed by future patches?
> REALLOCATE_BITMAPSETS was i
David Rowley writes:
> On Wed, 8 May 2024 at 06:20, Tom Lane wrote:
>> I find that Richard's proposed fix makes the core regression tests
>> pass, but we still fail check-world. So I'm afraid we need something
>> more aggressive, like the attached which makes make_restric
Nathan Bossart writes:
> On Tue, May 07, 2024 at 01:44:16PM -0400, Tom Lane wrote:
>> +1 to include that, as it offers a defense if someone invokes this
>> function directly. In HEAD we could then rip out the test in the
>> view.
> I apologize for belaboring this point
that sort; there's unlikely to be a
lot of them.
regards, tom lane
diff --git a/src/backend/optimizer/util/restrictinfo.c b/src/backend/optimizer/util/restrictinfo.c
index 0b406e9334..e81861bc8b 100644
--- a/src/backend/optimizer/util/restrictinfo.c
+++ b/src/backend/optimizer/u
then rip out the test in the
view.
BTW, I think you also need something like
- int64 result;
+ int64 result = 0;
Your compiler may not complain about result being possibly
uninitialized, but IME others will.
regards, tom lane
the attached seems to fix it.
regards, tom lane
diff --git a/src/bin/pg_dump/pg_backup_archiver.c b/src/bin/pg_dump/pg_backup_archiver.c
index c6c101c118..56e0688154 100644
--- a/src/bin/pg_dump/pg_backup_archiver.c
+++ b/src/bin/pg_dump/pg_backup_archiver.c
@@ -1319,10 +1319,13 @
Robert Haas writes:
> Never mind all this. I think what I have in mind requires doing what
> you did first. So if you're happy with what you've got, I'd go for it.
OK. HEAD-only sounds like a good compromise. Barring objections,
I'll do that later today.
regard
Robert Haas writes:
> On Mon, May 6, 2024 at 7:31 PM Tom Lane wrote:
>> So maybe this is not really worth fixing. Thoughts?
> Hmm, I thought the RLS condition needed to accept the old and new
> TIDs, but not (InvalidBlockNumber,0). I might well have misunderstood,
> tho
g in -l mode: ProcessArchiveRestoreOptions
saves the result of _tocEntryRequired in te->reqs, but PrintTOCSummary
doesn't, and that will bollix its subsequent _tocEntryRequired checks
for "dependent" TOC entries.
regards, tom lane
her we have a live bug
in this area in released branches; and if so, why we've not seen
reports of that.
regards, tom lane
le_to.
Hmm, the SJE code didn't really touch any of this logic, so why
didn't we see the failure before?
regards, tom lane
David Rowley writes:
> Why not "Fix INSERT with multi-row VALUES clauses ..."?
To my mind, the VALUES clause is the data source for INSERT,
so "from" seems appropriate. I'm not going to argue hard
about it.
regards, tom lane
m pretty sure it means "Fix
> multiple-row VALUES clauses with INSERT statements when ...", but I'm
> not sure.
The problem happens in commands like
INSERT INTO tab VALUES (1,2), (3,4), ...
We treat this separately from the single-VALUES-row case for
efficiency reasons.
regards, tom lane
ent.
+1. This is hardly a major bug fix --- it's just blocking off
something that people shouldn't be doing in the first place.
regards, tom lane
documented implementation details, that I can't
imagine anyone is actually using such an RLS condition or ever will.
So maybe this is not really worth fixing. Thoughts?
regards, tom lane
[1]
https://www.postgresql.org/message-id/CA%2BTgmobwgL1XyV4uyUd26Nxff5WVA7%2B9XUED4yjp
get labeled in EXPLAIN,
I'd be kind of disinclined to spend extra cycles. But in any case,
I rather suspect you'll find that this actively breaks things.
Whether we change the varno on a Var isn't really optional, and there
are cross-checks in setrefs.c to make sure things match up.
regards, tom lane
wouldn't remove it, but maybe an Assert is good enough. The tests
on Vars' varno should be equally pointless no?
regards, tom lane
ed
> TidPath gets chosen, but this problem is not the fault of that.
> We're not making the TidPath with the correct contents in the first
> place.
Still true.
regards, tom lane
blem is not the fault of that.
We're not making the TidPath with the correct contents in the first
place.
regards, tom lane
1 - 100 of 15212 matches
Mail list logo
