"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 catve
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
>> e
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
would be to let extension types in on the fun.)
regards, tom lane
ess so.
regards, tom lane
w to what
extent 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-chec
really desirable. 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
me up before
(though I guess that suggests that few people try this).
regards, tom lane
it despite being 64-bit.
(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
ally, 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
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); it'd
only require 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 unli
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
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
ul on dodo, but when it fails
it's twice that. Why the instability? (Perhaps 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
did the latter; but that won't be
enough to make 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
trashed FSM doesn't
result in incorrect output, and zeroing it will make things
worse not better.)
regards, tom lane
current 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 ho
m aware that I ought to review this patch, and will try to make
time for that before the end of the CF.)
regards, tom lane
xt, I count 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
lly and not
by the back door. But I think somebody 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
hacks 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
in replacements using
citext input. Hence, we need to add the same parameter names to
those functions, or they'll fail to replace some calls.
regards, tom lane
ut let's
> start with that.
+1
regards, tom lane
James Coleman writes:
> On Thu, Jul 18, 2024 at 2:38 PM Tom Lane wrote:
>> Are you really sure nothing changed about what the ORM is emitting?
> Yes, aside from the fact that application code didn't change, we
> reproduced the problem by restoring a physical snapshot of the
hink the attached v4 is committable. If Andres is
too busy, I can push it, but really it's his patch ...
(BTW, I see no need for additional test cases. Coverage checks show
that all this code is reached during the core regression tests.)
regards, tom la
confused too. What nondefault planner settings
have you got? ("EXPLAIN (SETTINGS)" would help with answering that
accurately.)
Are you really sure nothing changed about what the ORM is emitting?
regards, tom lane
.
Yeah. The old way was great if there really were just a few tuples
needing to be moved ... but by the time you decide you need VACUUM
FULL rather than plain VACUUM, that's unlikely to be the case.
regards, tom lane
tment if an
immediate shutdown wasn't what was expected/wanted. If we
just say "shut down in recovery", that may be accurate,
but it offers little help as to what to do next.
regards, tom lane
ter".
> I've set it to "ready for committer", thanks.
Pushed, thanks.
regards, tom lane
the mutability situation
strictly worse, because people will have to continue to rely on
OS-provided functionality that can change at any time.
regards, tom lane
l, USAGE allows nextval() which
gives strictly less information than what this exposes; that's why
we're here after all.) So there is a difference in the privilege
levels, which is another reason for not combining this with
pg_sequence_last_value.
regards, tom lane
Nathan Bossart writes:
> On Wed, Jul 17, 2024 at 02:59:26PM -0400, Tom Lane wrote:
>> Uh ... why do we need a function, rather than just
>> select * from pg_sequence
> We can use that for dumpSequence(), but dumpSequenceData() requires
> information from the sequence tuple i
y do we need a function, rather than just
select * from pg_sequence
?
regards, tom lane
Jacob Champion writes:
> On Wed, Jul 17, 2024 at 8:01 AM Tom Lane wrote:
>> The existing and documented expectation is that PG_TEST_EXTRA is an
>> environment variable, ie it's a runtime option not a configure option.
>> Making it be the latter seems like a significant
D is the way at present. MacRumors has some
reviews/testing, eg this one:
https://www.macrumors.com/review/hyper-usb-hubs-ssd-enclosure/
regards, tom lane
ry introducing a new way to surface this information someday).
It still feels to me like not a great way to go about it. Having
said that, it's not like we don't have any existing examples of
the category, so I won't cry hard if I'm outvoted.
regards, tom lane
igure option.
Making it be the latter seems like a significant loss of flexibility
to me.
regards, tom lane
Joe Conway writes:
> Fair enough, but then I think we should change the documentation to not
> say "forever".
No objection to that, it's clearly a misleading definition.
regards, tom lane
an before, and then 0003 adds the preprocessor. (I fixed the
bogus install rule, too.)
regards, tom lane
From f5e02af68a9c5cc3c2035bf453f5de7c960f4404 Mon Sep 17 00:00:00 2001
From: Tom Lane
Date: Mon, 15 Jul 2024 18:45:10 -0400
Subject: [PATCH v2 1/3] Invent "MatchAnyN&quo
7;s
worth having, we don't need a fourth level. Possibly you could
argue that "safe to put in an index" is a different level from
"safe to constant-fold", but I don't really agree with that.
regards, tom lane
hich might be error-prone or
warning-inducing.
So on the whole, "leave it alone" seems like the right answer.
(This applies only to the s/char/enum/ proposal; I've not read
the patchset further than that.)
regards, tom lane
havior in non-obvious ways.
Unless you've got some compellingly good reason for messing
with this, I doubt it is worth the investigatory effort to
convince ourselves that it wouldn't introduce any bugs.
regards, tom lane
Andres Freund writes:
> On 2024-07-13 13:16:14 -0400, Tom Lane wrote:
>> Of course the main point is the hope that it will work at all with MSVC, but
>> I'm not in a position to test that.
> It does work with just your patches applied - very nice.
Thanks for testing!
&
[row('inv c',42,1.99), row('inv
d',42,2)]]::inventory_item[]));
In this particular example we need an explicit cast to cue the
parser about the type of the array elements, but then it can
cope with casting the outer row() construct automatically.
regards, tom lane
[1]
https://www.postgresql.org/message-id/flat/CACJufxExAcpvrkbLGrZGdZ%3DbFAuj7OVp1mOhk%2BfsBzeUbOGuHQ%40mail.gmail.com
expected to be architecture-independent, so how would they make
that work?
regards, tom lane
ack-patch to v13, where that commit
added the support.
Per bug #18467 from Onder Kalaci.
Patch by Japin Li, per a suggestion from Tom Lane, with some changes to
the comments by me. Review by Onder Kalaci, Alvaro Herrera, and me.
Discussion: https://postgr.es/m/184
Thomas Munro writes:
> On Fri, Jul 12, 2024 at 2:26 PM Tom Lane wrote:
>> Thomas Munro writes:
>>> I don't see any on clang 16 in the 12 and 13 branches. Where are you
>>> seeing them?
>> In the buildfarm. "adder" and a bunch of other machin
>> get_rel_name() called together at many places.
> That's not worth the complications based on the level of caching.
> This code is fine as-is.
I could get behind creating such functions if there were a
demonstrable performance win, but in places that are not hot-spots
that&#x
Thomas Munro writes:
> On Sat, Jul 6, 2024 at 2:35 PM Tom Lane wrote:
>> I see that there are a boatload of related warnings in older
>> branches too; do we want to try to do anything about that? (I doubt
>> code changes would be in-scope, but maybe adding a -Wno-foo s
Nathan Bossart writes:
> On Wed, Jul 10, 2024 at 01:41:41PM -0500, Nathan Bossart wrote:
>> On Wed, Jul 10, 2024 at 11:11:13AM -0400, Tom Lane wrote:
>>> We went through a ton of permutations of that kind of
>>> idea years ago, when it first became totally clear that cr
that can be done behind
the scenes, without messing with this source-code notation.)
Does anyone particularly hate this plan, or have a better idea?
BTW, we have quite a few instances of code like the aforementioned
else if (HeadMatches("CREATE", "STATISTICS", MatchAny) &am
think it's OK, so I pushed it. I did take out a couple
of uses of "logical replication" that seemed unnecessary and were
making the length problem worse.
regards, tom lane
[1]
https://www.postgresql.org/docs/devel/error-style-guide.html#ERROR-STYLE-GUIDE-WHAT-GOES-WHERE
on the ability to use fcinfo->flinfo->fn_extra as cache space
in an aggregate. (Indeed, the array aggregate code is almost
identical to where we ended up.)
AFAICS this is good to go. I made a couple of tiny cosmetic
adjustments, added a catversion bump, and pushed.
regards, tom lane
of
src/test/regress/expected/collate.windows.win1252.out are actually
wrong, and we'd not noticed because it was only checked with diff -w.
psql does put an extra trailing space in some lines of table output,
but that space isn't there in collate.windows.win1252.out.
regards, tom lane
*/
prohibitValueChange = true;
}
else if (context != PGC_POSTMASTER)
// throw "cannot be changed now" error
regards, tom lane
ncy check" mechanism that GUC applies after
it thinks it's reached a final set of GUC values. I'm not very
clear on how outside checking code would be able to look at the
tentative rather than active values of the variables, but that
should be solvable.
regards, tom lane
regress.c with this rather less
>> dangerous flag, so instead of ignoring any white space difference we would
>> only ignore line end differences. The use of "-w" apparently dates back to
>> 2009.
> That seems like a good improvement to me.
+1
regards, tom lane
Andres Freund writes:
> On 2024-07-09 17:44:27 -0400, Tom Lane wrote:
>> Worst case: the reason no one uses readline under Windows is that it flat
>> out doesn't work.
> It seems to work fine as long as a debug-readline is paired with a debug-psql
> or a release-readlin
o be
malloc'd by the client (tab-complete.c) and later free'd within
libreadline. I wonder how that will play with Windows' weird rules
about when one DLL's malloc pool will interoperate with another's
(cf PQfreemem). Worst case: the reason no one uses readline under
Windows is that it flat out doesn't work.
regards, tom lane
_NOT_WELL_BALANCED with
no other error. So my instinct to not suppress that
unconditionally was right.
At the moment I'm thinking that we should just remove those
new test cases again. They are not valuable enough to
justify a new variant expected-file, while suppressing the
errdetail would remove whatever value they do have.
regards, tom lane
ttps://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=indri&dt=2024-07-09%2018%3A17%3A23
I'll push this change in a little bit (still gotta write commit
message) and indri should go back to green. Unless one of the
other animals complains, I'll set about back-patching in a
day or two.
regards, tom lane
my suggestion of applying strchr() to
see if the character we are expecting to see actually appears
anywhere. Or did you have something else in mind? Please be
specific, both about the test you are thinking of and how the
message should be worded.
regards, tom lane
jian he writes:
> On Mon, Jul 8, 2024 at 10:42 PM Tom Lane wrote:
>> One possibility could be
>> ...
>> that is, only say "Missing "]"" if there's no ']' anywhere, and
>> otherwise just say the dimensions are wrong. This could be
e a way
to track or quantify it before, because locale changes happened
outside code we control.
regards, tom lane
here?
Don't recall right at this instant, but I've put myself down as
reviewer of this patch to remind me to look at it in the next
day or two.
regards, tom lane
quired for GSSAPI])])])
fi
There might be a variant of AC_CHECK_HEADERS that doesn't have
the default define-a-symbol action, not sure.
Maybe it's not really necessary to check both gssapi.h and
gssapi_ext.h, but I'm not very familiar with all the variants of
GSSAPI that are out the
cy about that!). While I wouldn't
complain too hard about assuming that our own test files don't
contain \r\n, if the code might get copied into a non-test
scenario then it could create problems later.
regards, tom lane
2024-07-08 14:18:03 -0400, Tom Lane wrote:
>> Could we perhaps have a table of first words of each interesting
>> match, and do a lookup in that before dispatching to code segments
>> that are individually similar to what's there now?
> Eventually it seems yet, it ought
translator comment, but to label the name properly, perhaps like
errmsg("synchronization worker \"%s\" could not connect to the
primary server: %s",
app_name.data, err));
regards, tom lane
[1]
https://www.postgresql.org/docs/devel/error-style-guide.html#ERROR-STYLE-GUIDE-OBJECT-TYPE
g to code segments
that are individually similar to what's there now?
regards, tom lane
accounted for anyway, no?
(Perhaps the auto_explain documentation should mention this?)
regards, tom lane
;]' anywhere, and
otherwise just say the dimensions are wrong. This could be fooled
by a ']' that's part of some string in the data, but even then the
errdetail isn't wrong.
Or we could just say "Array dimensions have invalid syntax."
unconditionally.
regards, tom lane
ion, but maybe it'd be fine even then.
regards, tom lane
he search path but is masked by some
operator in an earlier schema, so simply testing if the operator's
schema is in the path at all would be insufficient.
regards, tom lane
amp;
^
-line 1: chunk is not well balanced
-&
-^
it's kind of hard to argue that the chunk isn't well-balanced.
So we can either suppress errdetails from the expected output,
or set up an additional expected-file. I'm leaning to the
"\set VERBOSITY terse"
aller of xml_parse passes
parsed_nodes = NULL. (And it wasn't doing the right thing in the
other case either :-(.) The attached works significantly better,
and cleans up these bogus errors.
We're still left with missing "chunk is not well balanced" errcontext
entries, which w
Erik Wienhold writes:
> On 2024-07-06 20:43 +0200, Tom Lane wrote:
>> I'm disinclined to spend much effort on working around dot-zero bugs.
> Found an open issue about ABI compatibility that affects 2.12.7 and
> possibly also 2.13: https://gitlab.gnome.org/GNOME/libxml2/-
at, ISTM we ought to raise an error somewhere?
+1, if we can figure out how.
regards, tom lane
classification,
and it would effectively act the same as immutable does now, because
people will certainly wish to use these functions in indexes etc.
regards, tom lane
o spend much effort on working around dot-zero bugs.
Meh ... 2.13.1, at least, changes nothing here.
regards, tom lane
Erik Wienhold writes:
> On 2024-07-06 16:25 +0200, Tom Lane wrote:
>> Yeah, apparently --- I get what look like the same diffs with
>> libxml2 2.13.0 recently supplied by MacPorts. Grumble.
>> Somebody's going to have to look into that.
> Here's a patch th
k into that.
regards, tom lane
imnodes.h or
> * parsenodes.h will warrant a catversion update.
> Since this patchset changes the querytree produced by the parser, does
> this indicate that a catversion bump is needed?
Yes, it would.
regards, tom lane
ope, but maybe adding a -Wno-foo switch
to the build flags would be appropriate.)
regards, tom lane
x27;::timestamptz works is that timestamptz_in
ignores irrelevant punctuation (or what it thinks is irrelevant,
anyway). I do not think we should include examples that look like
that, because it will further confuse readers who don't already
have a solid grasp of how this works.
regards, tom lane
but not of the SQL function now().) Documentation
that is equally confused won't help any.
regards, tom lane
Pavel Stehule writes:
> čt 4. 7. 2024 v 21:42 odesílatel Tom Lane napsal:
>> Here's a v2 that does it like that.
> I like it.
> - patching and compilation without any issue
> - check world passed
> I'll mark this as ready for commit
Pushed, thanks!
regards, tom lane
be nothing to do if not. In normal
cases that's not going to buy much because the OnCommitItems list
is short, but in your scenario maybe it could win.
regards, tom lane
XX, so that we completely move out
> of the way of the system regex stuff. But not today, and certainly
> not in back-branches.
That would be an API break for any extensions using our regex code,
so I'm not especially in favor of it.
regards, tom lane
the result of format_procedure() to generate the internal Tcl name.
> That should greatly reduce the number of cases where we have duplicate
> internal names we have to unique-ify.
Here's a v2 that does it like that.
regards, tom lane
diff --git a/doc/src/sgml
there's no way that can work. Never mind...
regards, tom lane
Thomas Munro writes:
> On Mon, Jul 1, 2024 at 2:06 PM Tom Lane wrote:
>> Yeah. I'd do pg_regex_t in a minute except that it'd break existing
>> extensions using our facilities. However, your mention of macrology
>> stirred an idea: could we have our regex/regex.
Tcl name.
That should greatly reduce the number of cases where we have duplicate
internal names we have to unique-ify.
> Is there some size limit for variable name? I didn't find it.
I did a quick test with 1-character names and Tcl didn't
complain, so it seems like there's no hard limit.
regards, tom lane
ns in different schemas,
but it doesn't move the needle for overloaded functions. On the
whole I feel like that'd add verbosity without buying much.
regards, tom lane
501 - 600 of 7950 matches
Mail list logo
