to go, if we can replace that with a separate
boolean without driving up the cost of add_path too much.
regards, tom lane
Robert Haas writes:
> On Tue, Mar 12, 2024 at 1:32 PM Tom Lane wrote:
>> BTW, having written that paragraph, I wonder if we couldn't get
>> the same end result with a nearly one-line change that consists of
>> making disable_cost be IEEE infinity.
> I don't think so, b
rly one-line change that consists of
making disable_cost be IEEE infinity. Years ago we didn't want
to rely on IEEE float semantics in this area, but nowadays I don't
see why we shouldn't.
regards, tom lane
the time if they care about the column name at all.
regards, tom lane
Joe Conway writes:
> On 3/9/24 13:07, Tom Lane wrote:
>>> BTW, while I didn't touch it here, it seems fairly bogus that
>>> connectby() checks both type OID and typmod for its output
>>> columns while crosstab() only checks type OID. I think
>>&g
Joe Conway writes:
> On 3/5/24 17:04, Tom Lane wrote:
>> After reading the thread at [1], I could not escape the feeling
>> that contrib/tablefunc's error reporting is very confusing.
> The changes all look good to me and indeed more consistent with the docs.
> D
Yugo NAGATA writes:
> On Wed, 06 Mar 2024 13:03:39 -0500
> Tom Lane wrote:
>> I don't have Windows here to test on, but does the WIN32 code
>> path work at all?
> The outer loop is eventually exited even because PSQLexecWatch returns 0
> when cancel_pressed = 0. H
event (that is,
"flush all cache entries").
regards, tom lane
inly because we can't count on it
to localize consistently with ereport et al. My grep confirms this
is the only use, so +1 for removing it.
regards, tom lane
Daniel Gustafsson writes:
> On 7 Mar 2024, at 20:58, Tom Lane wrote:
>> This could probably do with a comment, and we need to propagate
>> the fix into libpq's copy of the function too. Barring objections,
>> I'll take care of that and push it later today.
> LGTM.
eed to sweat.
This could probably do with a comment, and we need to propagate
the fix into libpq's copy of the function too. Barring objections,
I'll take care of that and push it later today.
regards, tom lane
ssion on OpenSSL's part. Maybe
they'll figure out how to fix it sometime; that seems to be
another good argument for not pre-empting their error handling.
regards, tom lane
above works, then +1 to that.
My reaction as well --- I was just gearing up to test this idea,
unless one of you are already on it?
regards, tom lane
Hannu Krosing writes:
> On Sat, Feb 10, 2024 at 12:38 AM Tom Lane wrote:
>> 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,
> Can you point m
Alexander Korotkov writes:
> Sorry for tediousness, but isn't pre-order a variation of depth-first order
> [1]?
To me, depth-first implies visiting children before parents.
Do I have the terminology wrong?
regards, tom lane
ative. Fortunately we can
just reset ichild to zero and not worry about having any
connection between the first loop and the second.
Here's a v5 of 0003 with those issues and some more-cosmetic ones
cleaned up. I didn't look at 0001 or 0002.
regards, tom lane
diff --git a
p, only the inner delay
one, meaning that trying to control-C out of a \watch will just
cause it to repeat the command even faster. That path isn't
setting the "done" variable, and it isn't checking it either,
because all of that only happens in the other #ifdef arm.
regards, tom lane
Joe Conway writes:
> I will have a look at your patches, and the other issue you mention, but
> it might be a day or three before I can give it some quality time.
No hurry certainly. Thanks for looking.
regards, tom lane
for a separate patch though.
regards, tom lane
[1]
https://www.postgresql.org/message-id/flat/DM4PR19MB597886696589C5CE33F5D58AD3222%40DM4PR19MB5978.namprd19.prod.outlook.com
From 7fba23c28e9e7558f54c52dd9407ce50f75b0e1d Mon Sep 17 00:00:00 2001
From: Tom Lane
Date: Tue
the exact-equality case.
regards, tom lane
like it's just these two places.
regards, tom lane
LRU_PAGE_EMPTY has (by chance, or deliberately)
the numeric value of zero, so I guess the majority of our BF
animals are understanding this as "address != NULL". But that
doesn't look like a useful test to be making.
regards, tom lane
regards, tom lane
I wrote:
> 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.
I looked this over again and pushed it.
regards, tom lane
s == 0 || IsBinaryUpgrade)
> +return;
max_logical_replication_workers is already PGC_POSTMASTER so there's
not any immediate loss of flexibility, but I don't think it's a great
idea to introduce another reason why it has to be PGC_POSTMASTER.
regards, tom lane
l push it.
regards, tom lane
diff --git a/src/bin/initdb/initdb.c b/src/bin/initdb/initdb.c
index ac409b0006..200b2e8e31 100644
--- a/src/bin/initdb/initdb.c
+++ b/src/bin/initdb/initdb.c
@@ -484,6 +484,7 @@ replace_guc_value(char **lines, const char *guc_name, const char *guc_value,
for
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
601 - 700 of 15282 matches
Mail list logo
