re if Coverity or other static
analyzers would whine about that.
regards, tom lane
you were lucky.
float8out has a different rule, which is to emit enough digits to
describe the actually-stored binary value unambiguously, so that
dump and reload will not change the stored value.
regards, tom lane
Alvaro Herrera writes:
> On 2024-Feb-29, Tom Lane wrote:
>> I agree that perminfoindex seems to have suffered from add-at-the-end
>> syndrome, and if we do touch the field order you made an improvement
>> there. (BTW, who thought they needn't bother with a comment
r.
I agree that perminfoindex seems to have suffered from add-at-the-end
syndrome, and if we do touch the field order you made an improvement
there. (BTW, who thought they needn't bother with a comment for
perminfoindex?)
regards, tom lane
han in writing one-off
magic code that in the end can avoid only one of the three possible
overflow cases in this function.
regards, tom lane
Heikki Linnakangas writes:
> On 28/02/2024 18:04, Tom Lane wrote:
>> The commit that added that test added a support function
>> "get_columns_length" which is now unused. Should we get rid of that
>> as well?
> I see you just removed it; thanks!
In the no-go
on even simpler.
That's a pretty convincing proof-of-concept. Let's just do this,
and then make sure to keep the file legible as plain text.
regards, tom lane
the final subtraction of the stride
can too. I changed it to just do the straightforward thing
(throwing error if the pg_xxx_s64_overflow routines detect error),
and pushed it. Thanks for the report and patch!
regards, tom lane
, and I'd go so far as to say that adding automation now
would be investing work that might well go to waste. When and
if we get annoyed by the manual labor involved in maintaining
two copies, it'd be time to put work into automating it.
regards, tom lane
et rid of that
as well?
regards, tom lane
out changing the code's behavior.
regards, tom lane
my faithful old PPC animal mamba
was helping to check this, but I see that under NetBSD it's
joined the ALIGNOF_DOUBLE==8 crowd.
regards, tom lane
, timestamp.c:2832
So we ought to guard the subtraction that produces tm_diff similarly.
I suspect it's also possible to overflow int64 while computing
stride_usecs.
regards, tom lane
dn't look hard.
Also, whatever we do here, surely timestamptz_bin() has the
same problem(s).
regards, tom lane
think
there's a compatibility hazard.
regards, tom lane
nce every
three years or so, so I doubt it'd be too painful to maintain two
versions of it.
Having said that, any proposal for this ought to be submitted as
a patch, rather than expecting people to go digging around on
some other repo.
regards, tom lane
l-terminated
> (that's what some bindings in Rust do)
I'd go with that. You would have a very hard time convincing me that
the per-query overhead that building a null-terminated string adds
is even measurable compared to the time needed to send, process, and
receive the query.
regards, tom lane
really see the
point of that --- as long as the relation has the desired
column, the column's type is surely well-defined.
regards, tom lane
[1]
https://www.postgresql.org/message-id/flat/88b574f4-cc08-46c5-826b-020849e5a356%40gelassene-pferde.biz
diff --git a/src/pl/
Tomas Vondra writes:
> On 2/25/24 17:29, Tom Lane wrote:
>> Yeah. Also: once we had such an idea, it'd be very tempting to apply
>> it to other frequently-reset contexts like the executor's per-tuple
>> evaluation contexts. I'm not quite prepared to argue that
>> Mem
PA support.
I don't think it does anybody any good to make it look like that's
still expected to work.)
regards, tom lane
libpq as well? That's not a lift that I think
we'd want to undertake.
regards, tom lane
ecial treatment.
regards, tom lane
Tomas Vondra writes:
> On 2/25/24 00:07, Tom Lane wrote:
>> ... I'm not sure if it'd be worth extending
>> the mcxt.c API to provide something like "MemoryContextResetIfBig",
>> with some internal rule that would be cheap to apply like "reset
>> if
Alvaro Herrera writes:
> On 2024-Feb-22, Tom Lane wrote:
>> While I've not done anything about that here, I wonder if we shouldn't
>> just write "privilege on the target table" without any special markup.
> That would work for me.
OK. Will y
I wrote:
> Tomas Vondra writes:
>> On 2/19/24 16:45, Tom Lane wrote:
>>> Tomas Vondra writes:
>>>> For example, I don't think we expect selectivity functions to allocate
>>>> long-lived objects, right? So maybe we could run them in a dedicated
>
.
IIRC, the parser+planner cooperatively fix things so that the final
state of an RTE's lateral field reflects reality. But if we are
hashing before that's happened, it's not worth all that much.
regards, tom lane
Amit Kapila writes:
> Seeing no objections, I have pushed the required test changes to silence the
> BF.
The farm is still unhappy in the v16 branch.
regards, tom lane
so), but
'CC' => 'ccache clang -std=gnu99',
so maybe the -std has something to do with it. I installed that
(or -std=gnu90 as appropriate to branch) on most of my build
setups back when we started the C99 push.
regards, tom lane
only is accurate within the parser and rewriter,
so maybe clarifications about context are in order.)
regards, tom lane
Heikki Linnakangas writes:
> Buildfarm animals 'sifaka' and 'longfin' are not happy, I will investigate..
Those are mine, let me know if you need local investigation.
regards, tom lane
,
maybe it'd be the best way.
It might be that any of these things is too messy to be considered
for back-patching, and we ought to apply what you did in the
back branches. I'd like a better fix in HEAD though.
regards, tom lane
diff --git a/src/backend/executor/nodeApp
.
which is fairly nonsensical: we don't define privileges on the name
of something. While I've not done anything about that here,
I wonder if we shouldn't just write "privilege on the target table"
without any special markup.
regards, tom lane
diff --git a/doc/s
und
exactly where it's going off the rails, but I feel like this ought
to get fixed somewhere else. Please hold off pushing your patch
for now.
(The test case looks valuable though, thanks for working on that.)
regards, tom lane
eoffs have changed.
regards, tom lane
nd+exec) for every savepoint, that
> would result in 3 or 6 messages overhead for every user query.
Those should get bundled into single TCP messages, though. Assuming
that that's done properly, I share the doubt that you're saving
anything very meaningful.
regards, tom lane
(But "smart" shutdown
doesn't enforce that, since it's a very weak state that only
prohibits new client sessions.) The processes that are allowed
to continue beyond that point are ones that are needed to perform
the shutdown checkpoint, or useful to make it finish faster.
regards, tom lane
empty
> set) -- which means that any role that has privileges on *any* column
> would get a pass. If you're doing MERGE with any other action besides
> DO NOTHING, you already have privileges on at least some column, so
> adding ACL_SELECT breaks nothing.
LGTM.
regards, tom lane
o pick out a custom
collection of objects to restore.
regards, tom lane
case where there could be
multiple output groups, yes that'd be a bug.
If you want to run it to ground you could bisect to see where the
behavior changed, but you'd probably just find it was intentional.
regards, tom lane
readability of these flags in
pprint output.
I'm not greatly in love with the macro layer you propose, either,
but those details don't matter because I think we should just
leave well enough alone.
regards, tom lane
but let's just transpose those into numeric.
regards, tom lane
JIT compilation will
expend if it's called. So I don't buy your argument here.
We would be better off to do this in a way that's clean and doesn't
add overhead for non-JIT-enabled builds.
regards, tom lane
gt; Is the use-case for this functionality really strong enough that
> we need to provide it as a single function rather than something
> assembled out of spare parts?
I'm still unconvinced about that, though.
regards, tom lane
Tomas Vondra writes:
> On 2/19/24 16:45, Tom Lane wrote:
>> Tomas Vondra writes:
>>> For example, I don't think we expect selectivity functions to allocate
>>> long-lived objects, right? So maybe we could run them in a dedicated
>>> memory context, and re
).
Is the use-case for this functionality really strong enough that
we need to provide it as a single function rather than something
assembled out of spare parts?
regards, tom lane
blem was data
structures associated with rejected Paths, but I might be wrong.
Is there some simple way we could get a handle on where the most
memory goes while planning?
regards, tom lane
Dean Rasheed writes:
> On 19 Feb 2024, at 12:48, Tom Lane wrote:
>> Or we could just flush it. It's never detected a bug, and I think
>> you'd find that it adds zero code coverage (or if not, we could
>> fix that in a far more surgical and less expensive manner).
> O
y breaks, is it time to add this to
> the regular make check?
Or we could just flush it. It's never detected a bug, and I think
you'd find that it adds zero code coverage (or if not, we could
fix that in a far more surgical and less expensive manner).
regards, tom lane
ndling of the
zero-partitions case in the RTEPermissionInfo refactoring.
(I didn't bisect to prove that a61b1f748 is exactly where it
broke, but I do see that the query successfully does nothing
in v15.)
regards, tom lane
Tomas Vondra writes:
> On 2/17/24 20:20, Tom Lane wrote:
>> I don't have an immediate proposal for exactly what to call such a
>> function, but naming it by analogy to pg_typeof would be questionable.
> Are you objecting to the pg_basetypeof() name, or just to it accepting
&
unction, but naming it by analogy to pg_typeof would be questionable.
regards, tom lane
Tomas Vondra writes:
> On 2/17/24 00:14, Tom Lane wrote:
>> The conclusion was that the specific invalid values didn't matter as
>> much on the other platforms as they do with glibc. But right now you
>> have a fifty-fifty chance that a pointer to garbage will look
to garbage will look valid.
Do we want to increase those odds?
regards, tom lane
for password expiration
time BTW.
regards, tom lane
can be shown
that pulling a few fields out of pg_stat_activity actually does make
for a useful speedup, then maybe OK ... but Andres hasn't provided
any evidence that there's a measurable issue.
regards, tom lane
f the new or changed expected outputs from that commit.
regards, tom lane
From f84343864e74501df627f986e326f766072398cd Mon Sep 17 00:00:00 2001
From: Tom Lane
Date: Fri, 16 Feb 2024 14:32:23 -0500
Subject: [PATCH v2] Improve EXPLAIN's display of SubPlan nodes.
child4 fail to restore altogether, but stchild5
ends with the wrong attstorage.
This patch definitely needs more work.
regards, tom lane
ession/storage settings accurately already?
(Note that it proves little that the pg_upgrade test passes,
since if pg_dump were blind to the settings applicable to a
child table, the second dump would still be blind to them.)
regards, tom lane
n build clearly needs to be rectified.
regards, tom lane
from ALTER TYPE OWNER.
> I've not tried to code that here, though.
Now that the multirange issue is fixed (3e8235ba4), here's a
new version that includes the needed recursion in ALTER EXTENSION.
I spent some more effort on a proper test case, too.
regards, tom lane
diff
tter to remember to do this
(which is an imperfect system, but...)
regards, tom lane
er 5 years
> until v17 goes EOL. It'll still be around for years in V16->.
Works for me.
> Attached is a diff to show what it would look like to remove adminpack
> (catalog
> version bump omitted on purpose to avoid conflicts until commit).
I don't see any references you missed, so +1.
regards, tom lane
Joseph Koshakow writes:
> On Tue, Feb 13, 2024 at 1:46 PM Tom Lane wrote:
>> (We'd need ereport in back branches, but this problem seems to
>> me to probably not be worth back-patching.)
> Agreed, this seems like a pretty rare overflow/underflow.
OK, pushed to HEAD
roblem seems to
me to probably not be worth back-patching.)
regards, tom lane
Robert Haas writes:
> On Tue, Jan 16, 2024 at 11:46 AM Tom Lane wrote:
>> Also, we already
>> treat the multirange as dependent for some things:
> But this seems like an entirely valid point.
Yeah, it's a bit of a muddle. But there is no syntax for making
a standalone m
by #ifdef'd code sections that you didn't compile.
On the whole, our experience with automated #include removal is
pretty awful. I'm not sure I want to go there again.
regards, tom lane
oughly a wash for performance.
Question to think about is which way is easier to use. I don't
have an opinion particularly; just throwing the idea out there.
regards, tom lane
.
Also, I'm pretty sure that reformat_dat_file.pl will
think your pg_proc.dat entry is overly verbose. See
https://www.postgresql.org/docs/devel/system-catalog-initial-data.html
regards, tom lane
Christoph Berg writes:
> Should the removal of "register" be backported to support that better?
Perhaps. It's early days yet, but nobody has complained that that
broke anything in v16, so I'm guessing it'd be fine.
regards, tom lane
Peter Eisentraut writes:
> On 06.02.24 16:14, Tom Lane wrote:
>> +1 for the general idea, but it seems like "row type equality"
>> might still be a slightly fuzzy concept.
> I did another pass across the callers to check what pg_attribute fields
> might be re
to "stack", so
that you'd have to remove each one before not-nullness stops being
enforced. Less sure about unnamed properties.
regards, tom lane
Andrew Dunstan writes:
> On 2024-02-08 Th 11:08, Daniel Gustafsson wrote:
>> On 8 Feb 2024, at 16:53, Tom Lane wrote:
>>> 2. Don't wait, migrate them all now. This would mean requiring
>>> Perl 5.10.1 or later to run the TAP tests, even in back branches.
>
e internal catalog within which names must be unique.
Worth noting perhaps that this is actually required by the SQL
standard: per spec, functions and procedures are both "routines"
and share the same namespace, which is necessary so that commands
like DROP ROUTINE are well-defined.
regards, tom lane
ze_t can be an unsigned long int for some architecture).
> Why is it safe to do this?
We do pretty much assume that "int" is "int32". But I agree that
assuming anything about the width of size_t is bad. I think we need
a separate pg_cmp_size() or pg_cmp_size_t().
regards, tom lane
ned. And if we use static inlines, we need to do so for correct
>> semantics anyway.
> Seems reasonable to me.
+1 here also.
regards, tom lane
ized fix.
We could imagine a more aggressive refactoring that would
allow passing down the Relation instead of re-opening it
in set_relation_column_names, but I doubt it's worth the
trouble.
regards, tom lane
diff --git a/src/backend/utils/adt/ruleutils.c b/src/backend/utils
same?
I think static inlines might be a safer technology. Perhaps it's
okay given the only expected use is in qsort comparators, but ...
regards, tom lane
.
Barring objections, I plan to push this pretty soon.
regards, tom lane
From 8d7ebd1fc5b556850fcbe117f44f1e0918edf4b9 Mon Sep 17 00:00:00 2001
From: Tom Lane
Date: Thu, 8 Feb 2024 12:54:08 -0500
Subject: [PATCH v2 1/2] Clean up unnecessarily Windows-dependent code in
Peter Eisentraut writes:
> On 07.02.24 16:26, Tom Lane wrote:
>> Why would a test be applying pg_get_expr to a table it doesn't
>> control?
> I think the situation is that one test (domain) runs pg_get_expr as part
> of an information_schema view, while at the s
/.
Didn't read the patch, but +1 for concept.
regards, tom lane
n
2009, so how likely is it that anyone cares anymore?
regards, tom lane
k branches that don't use autodie.
(Back-patching the use of autodie doesn't seem feasible, since before
v16 we supported perl 5.8.something.)
regards, tom lane
nfused about the objection here:
exactly what uses of plpgsql aren't in a routine or DO block?
regards, tom lane
Thomas Munro writes:
> On Tue, Jan 30, 2024 at 5:06 PM Tom Lane wrote:
>> Thomas Munro writes:
>>> Ahh, there is one: https://github.com/cpan-authors/IO-Tty/issues/38
>> Just for the archives' sake: I hit this today on a fresh install
>> of FreeBSD 14.0, whic
he tests around a bit until the
> issue goes away?
Why would a test be applying pg_get_expr to a table it doesn't
control?
regards, tom lane
Stephen Frost writes:
>> On Tue, 2024-02-06 at 12:29 -0500, Tom Lane wrote:
>>> I was, and remain, of the opinion that that was a bad idea that
>>> we'll eventually revert, just like we previously got rid of most
>>> inessential log chatter in the default configur
s suggesting, it should be easier to
> reason about overflow risks.
A comparison routine that is not is probably broken, agreed.
I didn't look through the details of the patch --- I was more
curious whether we had a version of the qsort bug, because
if we do, we should fix that too.
o maybe these are just test problems not fundamental weaknesses.
But "replication falls over if the walsender is slow" isn't
something I'd call acceptable.
regards, tom lane
diff --git a/src/backend/replication/walsender.c b/src/backend/replication/walsender.c
ind
t looks like now we have a mess, because the condition was copied
verbatim into copyto.c but not copyfrom.c. Aren't we failing to
validate encoding in this case in COPY FROM, which is where we
actually need to?
regards, tom lane
less
bad than log_checkpoints, because no such events will occur in a
well-tuned configuration ... but still, it's going to be useless
chatter in the average installation.
regards, tom lane
ould compare attcollation too, no?
+1 for the general idea, but it seems like "row type equality"
might still be a slightly fuzzy concept.
regards, tom lane
d whether there's a
problem with the code we do use?
regards, tom lane
oint, aren't these proposals just band-aids that
would stabilize the test without fixing the actual problem?
The same thing is likely to happen to people in the field,
unless we do something drastic like removing ALTER SUBSCRIPTION.
regards, tom lane
CreateMutex() which has documented failure
conditions. So I wonder if we ought to copy this implementation
back into ecpglib; but I've not done that here.
regards, tom lane
[1]
https://www.postgresql.org/message-id/flat/18312-bbbabc8113592b78%40postgresql.org
From
er, which'd
break a *lot* of code.
regards, tom lane
the default public CONNECT privilege on database db2.
regards, tom lane
Noah Misch writes:
> On Fri, Feb 02, 2024 at 08:18:50PM -0500, Tom Lane wrote:
>> Noah Misch writes:
>>> Shall the top of the notes advise to reindex GIN indexes?
>> I thought about that, but it's a pretty low-probability failure
>> I think, so I didn't write t
nes with identical call APIs, but different failure
behavior, so that we don't have to touch the callers?
regards, tom lane
Noah Misch writes:
> On Fri, Feb 02, 2024 at 05:07:14PM -0500, Tom Lane wrote:
>> If you look at the buildfarm's failures page and filter down to
>> just subscriptionCheck failures, what you find is that all of the
>> last 6 such failures are in 031_column_list.pl:
>>
on that one some more.
regards, tom lane
701 - 800 of 15356 matches
Mail list logo
