neer all this, but right now I have
better things to do.
regards, tom lane
ere.
I think we usually just say VACUUM. If it affected autovacuum
differently, that might be worth documenting; but IIUC it's the
same.
regards, tom lane
if (strcmp(p->type->size, "1") == 0)
? I've not actually tested, but this should catch the cases the
warning is meant to catch while not complaining about any of the
examples you give. I'm not sure if leading/trailing spaces
would fool it (i.e., "char foo[ 1 ];"). But even if they do,
that doesn't seem disastrous.
regards, tom lane
See
https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=ee219ee8c40d88e7a0ef52c3c1b76c90bbd0d164
As usual, please send corrections/comments by Sunday.
regards, tom lane
'update_failover'
2 'update_tuple'
8 'update_two_phase'
8 'vob'
That shows that the apparent similarity of the total number of reports
per animal is illusory: there are some that all eight animals agree
on, but a lot where they don't.
regards, tom lane
s
> rejected at the initial cost stage that would have been accepted at
> the final cost stage.
That absolutely is the expectation, and we'd better be careful not
to break it.
regards, tom lane
>
So in other words, we might as well just remove RLS.
regards, tom lane
ing from pre-9.2 servers, so this no
> longer serves any need, it seems to me.
+1 for the idea; didn't vet the patch closely.
regards, tom lane
put the app on a different platform?
regards, tom lane
source
text. (Don't recall precise numbers offhand, and they'd be obsolete
by now even if I did.)
I'm not sure that the results you're showing justify taking any
risk here.
regards, tom lane
this is an academic example not corresponding
to any real use-case. The current code seems to effectively assume
that the constant-instances are distinct even though textually
identical, and that's fine with me.
regards, tom lane
to other types. However, that would be
a compatibility break for a case that doesn't fail today, so
it might be a harder sell than changing cases that do fail.
I'm mildly in favor of doing it, but somebody else might
think differently.
regards, tom lane
out to cover the other jsonb-to-XXX
cast functions.
regards, tom lane
[1]
https://www.postgresql.org/message-id/flat/18564-5985f90678ed7512%40postgresql.org
diff --git a/src/backend/utils/adt/jsonb.c b/src/backend/utils/adt/jsonb.c
index 928552d551..91f1059e4c 10064
r columns. I see
no reason to blame the plan cache for it. Do you have any
examples that don't depend on such a bug?
(And yes, I apologize for not yet having reviewed your patch
to fix the grouping-sets bug.)
regards, tom lane
t seems like a mess, not least
because there are going to be varying opinions about where we
should set the bar for the lower level.
regards, tom lane
istics and cost estimates we're dealing with are not perfect.
It is probably worth drilling down into that test case to understand
where the planner is going wrong, with an eye to future improvements;
but I doubt it's something we need to address for v17.
regards, tom lane
If we
start marking things as leakproof because we cannot prove
they leak, rather than because we can prove they don't,
we are eventually going to find ourselves in a very bad place.
regards, tom lane
drops a bunch of new code in here.
regards, tom lane
days ago
caused by instability of the new 043_vacuum_horizon_floor.pl test.
Once you take those out it doesn't look quite so bad.
regards, tom lane
Peter Eisentraut writes:
> On 30.07.24 18:19, Tom Lane wrote:
>> Sometime in the last month or so, flaviventris's bleeding-edge
>> version of gcc has started whining[1] about truncation of a
>> string literal's implicit trailing '\0' in contexts like this:
>> ..
e to
> complain where we could still reverse the decision.
Seems like a plausible compromise.
regards, tom lane
ic sort
of recursive traversal that you illustrated.
regards, tom lane
at's *not* drawing a warning. So the most plausible fix
seems to be
- .soundex = "00",/* Six digits */
+ .soundex = {'0', '0', '0', '0', '0', '0'}, /* Six digits */
(In principle, we could fix the COPY and numutils cases the same
way, but I don't care for the readability loss that'd entail.)
Preferences, other suggestions?
regards, tom lane
[1]
https://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=flaviventris=2024-07-30%2012%3A29%3A41=build
Amit Kapila writes:
> On Tue, Jul 30, 2024 at 1:48 AM Tom Lane wrote:
>> If the problem can be correctly described as "pg_createsubscriber
>> takes 10 seconds or so to detect end-of-stream",
> The problem can be defined as: "pg_createsubscriber waits for
ments, so that they're unlikely to care if
numeric_mul gets slightly faster or slower. Obviously a *big*
performance drop might get pushback.
regards, tom lane
hashtable at a time, so this shouldn't cause
any large memory bloat.
I'll park this in the next CF.
regards, tom lane
[1] https://www.postgresql.org/message-id/2422717.1722201869%40sss.pgh.pa.us
diff --git a/src/backend/utils/adt/ruleutils.c b/src/backend/utils/adt/ruleutil
Robert Haas writes:
> On Sun, Jun 30, 2024 at 2:40 PM Tom Lane wrote:
>> ... However, I added a new open item about how the
>> 040_pg_createsubscriber.pl test is slow and still unstable.
> But that said, I see no commits in the commit history which purport to
> improve pe
ks are supposed to follow.
Yeah, that's fair.
regards, tom lane
Heikki Linnakangas writes:
> Yeah I'm not worried about that at all. Also, the assert is made when
> you have already released the spinlock; you are already out of the
> critical section.
Not in the patch Andres posted.
regards, tom lane
e than 2X max_connections
subprocesses (don't recall the exact limit, but it's around there).
regards, tom lane
ave been my oversight in 4c3c8c048d.
regards, tom lane
17 pg_upgrade's stability on.
Anyway, proposed patches attached. 0001 is some trivial cleanup
that I noticed while working on the failed single-ALTER-TABLE idea.
0002 merges the catalog-UPDATE commands that dumpTableSchema issues,
and 0003 is Alexander's suggestion.
regar
Noah Misch writes:
> On Sun, Jul 28, 2024 at 11:50:33AM -0400, Tom Lane wrote:
>> Is it time to worry yet? If this were HEAD only, I'd not be too
>> concerned; but two of these three are on allegedly-stable branches.
>> And we have releases coming up fast.
> I don't know
r
storing through it is pretty pointless. Maybe what was intended
was
- if (ident && strcmp(*name, "dynahash") == 0)
+ if (*name && strcmp(*name, "dynahash") == 0)
?
regards, tom lane
s.
And we have releases coming up fast.
(BTW, I don't think taipan qualifies as a slow machine.)
regards, tom lane
Andrew Dunstan writes:
> On 2024-07-27 Sa 10:20 AM, Tom Lane wrote:
>> Just to add some more fuel to the fire: I do *not* observe such an
>> effect on my own animals.
> The culprit appears to be meson. When I tested running crake with
> "using_meson => 0"
jian he writes:
> On Fri, Jul 26, 2024 at 10:40 PM Tom Lane wrote:
>> Hmm, yeah, you're right. I didn't want to write two separate
>> synopses there, but maybe there's no choice.
> Now the output is
> It has the syntax regexp_replace(string, pattern,
PI then manipulate
it through the other if need be.
regards, tom lane
ou sure there's not
background load on the machine?
regards, tom lane
utils/timestamp.h and
utils/datetime.h.
regards, tom lane
't easily reduce the number of
SQL commands in some cases.
It's late here, and I've got some other commitments tomorrow,
but I'll try to produce a patch to merge more of the SQL
commands in a day or two.
regards, tom lane
Alexander Korotkov writes:
> On Sat, Jul 27, 2024 at 1:37 AM Tom Lane wrote:
>> It's fairly easy to fix things so that this example doesn't cause
>> that to happen: we just need to issue these updates as one command
>> not N commands per table.
> I was thinking abou
ncern.
> Note that there seemed to be no issue when I created 999 tables without
> partitioning:
> SELECT format('CREATE TABLE t%s(LIKE p)', i,i,i+1) FROM
> generate_series(1,999)i;
Yeah, because then we don't need to play games with attislocal.
regards, tom
a command-line option, if only
because I think a lot of people invoke pg_upgrade through
vendor-provided scripts that aren't going to cooperate with that.
If we can find some way to make it adapt without help, that
would be much better.
regards, tom lane
rom v2.
I'd like to get this merged soon ...
regards, tom lane
From 273ec2558fad646a2835bfe795fb12b8e821a12f Mon Sep 17 00:00:00 2001
From: Tom Lane
Date: Fri, 26 Jul 2024 15:41:20 -0400
Subject: [PATCH v3 1/3] Invent "MatchAnyN" option for tab-complete.c's
M
rtRequestInlineSRF.
It would be good to have an in-core test case for this request type,
but I don't really see any built-in SRFs for which expansion as a
sub-SELECT would be an improvement.
regards, tom lane
uot;interestingly different".
regards, tom lane
nt of memory consumed,
or the verboseness of the output. (I wonder how it interacts with
GEQO, too.)
regards, tom lane
Erik Wienhold writes:
> On 2024-07-25 22:29 +0200, Tom Lane wrote:
>> This still isn't following our usual message style IMO. Here's a
>> proposed v7 that outputs ...
> Works for me. Thanks!
Pushed, then.
regards, tom lane
jian he writes:
> On Fri, Jul 26, 2024 at 10:17 PM Tom Lane wrote:
>> AFAICS, that one is correct, so I left it alone. (I didn't try to
>> merge the table's two entries into one like that, though.)
> regexp_replace(string, pattern, replacement [, start [, N ]] [, flags ])
jian he writes:
> On Fri, Jul 19, 2024 at 5:48 AM Tom Lane wrote:
>> but it is not: we have no function matching that signature. I'm not
>> in a hurry to add one, either, for fear of ambiguity against the other
>> regexp_replace signature. I think this needs to be brok
time in major release notes and just about
everyplace in minor release notes.
regards, tom lane
ve the bug fully. But it's
pretty reliable for issues raised in the last half dozen years or so.
A bigger hole in what you're doing is that bug reports don't
necessarily come in via the web form.
regards, tom lane
ERROR 840.84s exit status 29
Based on this, it seems fairly likely that crake is simply timing out
as a consequence of intermittent heavy background activity.
regards, tom lane
o is most if not all links.
I see nothing wrong with this patch, so pushed.
regards, tom lane
n't read well to have two parenthetical comments
in a single four-line sentence.
regards, tom lane
diff --git a/doc/src/sgml/ref/create_table.sgml b/doc/src/sgml/ref/create_table.sgml
index f19306e776..93b3f664f2 100644
--- a/doc/src/sgml/ref/create_table.sgml
+++ b/doc
I noticed that there were two CF entries pointing at this thread:
https://commitfest.postgresql.org/48/4655/
https://commitfest.postgresql.org/48/4973/
That doesn't seem helpful, so I've marked the second one "Withdrawn".
regards, tom lane
t to
omit that step's log if successful.
regards, tom lane
I wrote:
> I haven't heard any further bikeshedding on the argument names,
> so I'll move forward with committing this soon.
Pushed, after a little further fooling with the documentation.
regards, tom lane
hem will be advanced
hackers who won't blink at digging through a TAP log. We should
update the docs to explain that though.
regards, tom lane
going to be very
selective.)
regards, tom lane
jian he writes:
> On Fri, Jul 19, 2024 at 5:48 AM Tom Lane wrote:
>> The larger issue is that contrib/citext offers versions of some of
>> these functions that are meant to be drop-in replacements using
>> citext input. Hence, we need to add the same parameter names
lso appear to be more consistent with other
> executor nodes (e.g., ExprState, ExprEvalStep), so it might be worth it
> for consistency in any case.
+1, makes sense to me.
regards, tom lane
be turned into a union
of struct varatt_external and toast_compress_header, but that
would impose a good deal of notational overhead on the rest
of this function.
The good news is that we get through check-world (although
I didn't try very many build options).
regards, tom lane
Peter Eisentraut writes:
> On 24.07.24 16:05, Tom Lane wrote:
>> I'm not very thrilled with these changes. It's not apparent why
>> your compiler is warning about these usages of IsA and not any other
>> ones,
> I think one difference is that normally IsA is called o
I'd move the stanza to after the
"if (readBytes < 0)" one.
regards, tom lane
nored or not instead of this approach?
No thanks. Once we create such an option we'll never be
able to get rid of it.
regards, tom lane
le by non-wizards. I'm not surprised if there
are outright bugs in other distros' versions of it, as AFAIK
nobody else turns it on by default.
regards, tom lane
se at all. But I'd settle for minimizing
the amount of test cycles added.)
regards, tom lane
Amit Kapila writes:
> I merged these changes, made a few other cosmetic changes, and pushed the
> patch.
There is a CF entry pointing at this thread [1]. Should it be closed?
regards, tom lane
[1] https://commitfest.postgresql.org/48/4867/
e prepared statement?
We have no mechanism for notifying it that that information is
now falsified. The error is thrown to prevent us from getting
into a situation where we'd need to do that.
regards, tom lane
s similar warnings
on various compiler versions, with no end result other than making
the code uglier and less consistent.
If we can figure out why the warning is appearing, maybe it'd be
possible to adjust the definition of IsA() to prevent it.
regards, tom lane
Jeff Davis writes:
> On Tue, 2024-07-23 at 16:07 -0400, Tom Lane wrote:
>> Well, it depends on which libc collation you have in mind. I was
>> thinking of a libc-supplied C.UTF-8 collation, which I would expect
>> to behave the same as pg_c_utf8, modulo which Unicode
"Daniel Verite" writes:
> Tom Lane wrote:
>> Why? If we agree that that's the way forward, we could certainly
>> stick some collversion other than "1" into pg_c_utf8's pg_collation
>> entry. There's already been one v17 catversion bump s
Robert Haas writes:
> On Tue, Jul 23, 2024 at 3:26 PM Tom Lane wrote:
>>> Do we need to version the new ctype provider?
>> It would be a version for the underlying Unicode definitions,
>> not the provider as such, but perhaps yes. I don't know to what
>> extent
Jeff Davis writes:
> On Tue, 2024-07-23 at 15:26 -0400, Tom Lane wrote:
>> No, I think we *are* winning, because the updates are not "equally
>> unstable": with pg_c_utf8, we control when changes happen. We can
>> align them with major releases and release-not
ld be to let extension types in on the fun.)
regards, tom lane
ess so.
regards, tom lane
t doing so would satisfy Noah's concern; but if it would do
so I'd be happy with that answer.
regards, tom lane
Andrew Dunstan writes:
> On 2024-07-22 Mo 12:46 PM, Tom Lane wrote:
>> Masahiko Sawada writes:
>>> Looking at dodo's failures, it seems that while it passes
>>> module-xid_wraparound-check, all failures happened only during
>>> testmodules-install-check-C.
irable. Maybe
just provide a way to put an artificial limit on how many tuples
processed per pass?
(And no, I wasn't trying to rag on Melanie. My point here is that
we've failed to design-in easy testability of this code path, and
that's surely not her fault.)
regards, tom lane
hough I guess that suggests that few people try this).
regards, tom lane
(Did you figure out exactly why it doesn't reach the code?)
> Because of this, I'm inclined to revert the test on 17 and master to
> avoid distracting folks committing other work and seeing those animals
> go red.
Agreed as a short-term measure.
regards, tom lane
I'd wonder exactly what ALL is quantified over: the
whole output of the FROM clause, or only columns mentioned in the
SELECT tlist, or what? And why that choice rather than another?)
regards, tom lane
eck-C?
Oooh, that is indeed an interesting observation. There are enough
examples now that it's hard to dismiss it as chance, but why would
the two runs be different?
(I agree with the comment that we shouldn't be running this test
twice, but that's a separate matter.)
regards, tom lane
e editing the config files of affected animals.
regards, tom lane
index vacuuming. Do you think
>> this would be worth it?
> No, I don't.
I don't see why that's not a good idea.
regards, tom lane
Melanie Plageman writes:
> On Sun, Jul 21, 2024 at 5:04 PM Tom Lane wrote:
>> I note also that the PG_TEST_EXTRA approach has caused xid_wraparound
>> to get next-to-zero buildfarm coverage. If that test is actually
>> capable of revealing problems, we're unlik
Andrew Dunstan writes:
> On 2024-07-21 Su 1:34 PM, Tom Lane wrote:
>> Locally, I've not managed to reproduce the failure yet; so perhaps
>> there is some platform dependency. What are you testing on?
> Linux ub22arm 5.15.0-116-generic #126-Ubuntu SMP Mon Jul 1 10:08:40 U
Peter Geoghegan writes:
> On Sun, Jul 21, 2024 at 12:51 PM Tom Lane wrote:
>> I do not think the answer to this is to nag the respective animal
>> owners to raise PG_TEST_TIMEOUT_DEFAULT. IMV this test is simply
>> not worth the cycles it takes, at least not for these machi
dodo has highly
variable background load, and the thing simply times out in some
runs but not others?)
Locally, I've not managed to reproduce the failure yet; so perhaps
there is some platform dependency. What are you testing on?
regards, tom lane
copperhead happy. I am also suspicious that we'll
get bad news from other very slow animals such as dikkop.
I wonder if there is a less expensive way to trigger the test
situation than brute-forcing things with a large index.
Maybe the injection point infrastructure could help?
regards, tom lane
doesn't
result in incorrect output, and zeroing it will make things
worse not better.)
regards, tom lane
nt real UPDATEs.
regards, tom lane
responding sgml file is determinable.
I'd go for shorter myself (ie "func/"), mainly due to the precedent
of the existing subdirectory which is "ref/" not "reference/".
It's hardly a big deal though.
regards, tom lane
Andres Freund writes:
> On 2024-07-19 11:06:47 -0400, Tom Lane wrote:
>> 2. Do we really want to encourage people to build with -flto?
> The only case I know where we do rely on compilation units providing some
> level of boundaries is on compilers where we don't know how to
o review this patch, and will try to make
time for that before the end of the CF.)
regards, tom lane
t currently 167 sgml/*.sgml files
plus 219 ref/*.sgml, so adding 30 more would be an 8% increase.
Do we want to use a "func-" prefix on the file names? I could
imagine dispensing with that as unnecessary; or another idea
could be to make a new subdirectory func/ for these.
regards, tom lane
mebody needs to make the case that
there are compelling benefits that would justify the nontrivial
amount of risk and work that may ensue. My default position here
is "sorry, we don't support that".
regards, tom lane
acks Alexander mentions, maybe we
could clean some of those out too? I don't recall what platform
we had in mind there, but we've moved our goalposts on what
we support pretty far in the last couple years.
regards, tom lane
1 - 100 of 15598 matches
Mail list logo
