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
I don't see anything that 031_column_list.pl is doing that is much
different from other subscription tests, so why is it the only one
failing? And more to the point, what's going wrong exactly?
I am suspicious that this somehow represents a failure of the
historical catalog decoding logic, but I don't see how that theory
explains this only breaking in one test script.
regards, tom lane
Alexander Kuzmenkov writes:
> On Fri, Feb 2, 2024 at 8:12 PM Tom Lane wrote:
>> Hmm, do you think this is actually reachable? AFAIK we should only be
>> calling errcode_for_file_access() after functions that are unlikely to
>> report ENOMEM.
> It's reachable, that's h
RY. Attached is a small patch to
> fix this.
Hmm, do you think this is actually reachable? AFAIK we should only be
calling errcode_for_file_access() after functions that are unlikely to
report ENOMEM.
regards, tom lane
Antonin Houska writes:
> I couldn't find a reference to the 'langispl' attribute, so I removed it (see
> the diff attached) and the master branch compiled cleanly. Is there yet a
> reason to keep it?
You didn't test pg_dump, I take it.
regards, tom lane
First-draft release notes for 16.2 are available at
https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=87dcc5e45fad3021514f01360d3a2abd4e6480ee
Please send comments/corrections before Sunday.
regards, tom lane
ing.
regards, tom lane
ass to be especially
suited to the test.
regards, tom lane
this patch did not touch libpq.sgml, which still says
Note that the request is not itself flushed to the server automatically;
use PQflush if necessary.
Doesn't that require some rewording?
regards, tom lane
^
I pushed v12 (with some cosmetic adjustments) into the back branches,
since we're getting close to the February release freeze. We still
need to deal with the larger fix for HEAD. Please re-post that
one so that the cfbot knows which is the patch-of-record.
regards, tom lane
possible typo at
t/003_extrafiles.pl line 85.
in v14. v15 and up are OK.
regards, tom lane
Daniel Gustafsson writes:
> I think it should, the idea of that check is to catch calls to actual exits,
> while this is instrumentation which has nothing to do with exit(2). The
> attached diff should be enough to handle this.
+1
regards, tom lane
changing in minor releases.
regards, tom lane
Richard Guo writes:
> On Wed, Jan 31, 2024 at 5:12 AM Tom Lane wrote:
>> * Why is it okay to just use pull_varnos on a tablesample expression,
>> when contain_references_to() does something different?
> Hmm, the main reason is that the expression_tree_walker() function
"David G. Johnston" writes:
> On Tuesday, January 30, 2024, Tom Lane wrote:
>> My larger point here is that trying to enforce restrictions on
>> superusers *within* Postgres is simply not a good plan, for
>> largely the same reasons that Robert questioned mak
Magnus Hagander writes:
> On Tue, Jan 30, 2024 at 10:48 PM Tom Lane wrote:
>> I was imagining using selinux and/or sepgsql to directly prevent
>> writing postgresql.auto.conf from the Postgres account.
> Wouldn't a simple "chattr +i postgresql.auto.conf" work
ut I think maybe you need to find a way
to modify that test case so that it still tests what it's meant to.
This is a common hazard when changing the planner's behavior.
regards, tom lane
line 80.
Execution of t/003_extrafiles.pl aborted due to compilation errors.
# Looks like your test exited with 255 before it could output anything.
[17:19:57] t/003_extrafiles.pl ..
Dubious, test returned 255 (wstat 65280, 0xff00)
Failed 5/5 subtests
regards, tom lane
Robert Haas writes:
> On Tue, Jan 30, 2024 at 2:20 PM Tom Lane wrote:
>> Indeed. I'd go so far as to say that we should reject not only this
>> proposal, but any future ones that intend to prevent superusers from
>> doing things that superusers normally could do (and, in
ind of node should ever
appear in a scan-level expression. I'd leave those out so that we
get an error if something unexpected happens.
regards, tom lane
stem to manage itself is a little
> bit suspect.
Something like contrib/sepgsql would be a better mechanism, perhaps.
regards, tom lane
articular, the report would be delivered too late to be of any
use in client authentication.)
regards, tom lane
Thomas Munro writes:
> On Sat, Jan 13, 2024 at 1:51 PM Tom Lane wrote:
>> Time for a bug report to IO::Tty's authors, I guess.
> 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.
However, I get
> ReadyForQuery at the end. It seems the extended query protocol is
> ended by a simple query protocol message instead of a sync message.
> My question is, is this legal in terms of fronted/backend protocol?
I think it's poor practice, at best. You should end the
extended-protocol query cycle before invoking simple query.
I'm disinclined to document, or make any promises about,
what happens if you mix the protocols.
regards, tom lane
M is this week and
so a lot of people are going to be busy traveling and conferencing
rather than hacking. Things might not happen right away.
You could possibly help move things along if you can propose a
workable patch.
regards, tom lane
dding code in
existing modules we're better off with the rule of "make it match
nearby code". I admit it might be hard to draw a clear line between
the two cases, plus there might be local inconsistency already.
But let's try to avoid making local style inconsistencies worse.
regards, tom lane
in a relative filename.
regards, tom lane
a nearby purpose (coping with a
different change in libxml2's error APIs). So adding another one
of those doesn't seem so bad after all. I now like the attached
approach better.
regards, tom lane
diff --git a/contrib/xml2/xpath.c b/contrib/xml2/xpath.c
index a967257546..b999b1f
ndicate support against/for the change.
> I'll start: +1
[ shrug... ] -1 here.
regards, tom lane
Peter Eisentraut writes:
> On 27.01.24 20:04, Tom Lane wrote:
>> I don't mind adopting the "const" --- it's a good idea in isolation.
>> The trouble is in fixing our code to work with both old and new
>> libxml2 versions. We could thrash around with a configure te
as NaN on policy grounds. I would ask first
if that policy is sane at all. (I'd lean to "not" --- if we allow
it in the input JSON, why not in the output?) If it is sane, the
error message needs to be far more specific.
regards, tom lane
recognized: "%s"
>> timestamp format is not recognized: "%s"
>> timestamp_tz format is not recognized: "%s"
> I believe that the first line was intended to cover all the others:p
+1
regards, tom lane
opose we just remove it.
In short, I suggest the attached.
regards, tom lane
diff --git a/contrib/xml2/xpath.c b/contrib/xml2/xpath.c
index a967257546..b999b1f706 100644
--- a/contrib/xml2/xpath.c
+++ b/contrib/xml2/xpath.c
@@ -74,8 +74,6 @@ pgxml_parser_init(PgXmlStrictness strictn
=?utf-8?Q?Micha=C5=82_K=C5=82eczek?= writes:
> On 27 Jan 2024, at 15:43, Tom Lane wrote:
>> Which FreeBSD version? Which krb5 package version?
>> Is this x86_64, or something else?
> Right, sorry:
> 1. X86_64
> 2. FreeBSD 13.2 (It is in a TrueNAS Jail if it makes a
)
> 3. Build Pg with GSSAPI support
Which FreeBSD version? Which krb5 package version?
Is this x86_64, or something else?
regards, tom lane
David Rowley writes:
> On Sat, 27 Jan 2024 at 09:41, Tom Lane wrote:
>> drongo and fairywren are consistently failing the test case added
>> by this commit. I'm not quite sure why the behavior of Memoize
>> would be platform-specific when we're dealing with integers
sure why the behavior of Memoize
would be platform-specific when we're dealing with integers,
but ...
regards, tom lane
accepting
\create_function as described because I think too few people would
want to use it. However, the idea of an easy way to pull in a file
and convert it to a SQL literal seems like it has many applications.
regards, tom lane
. psql can get
that right even in the face of encoding considerations,
standard_conforming_strings, etc. Not sure you can build a
fully bulletproof solution outside.
regards, tom lane
ript.
This is almost always the behavior you want, and the principal
functional problem with the `cat ...` solution is that it doesn't
work that way.
regards, tom lane
ting something that works like :'...' but reads
from a file not a variable. That might be too specialized
though, and I'm not sure about good syntax for it either.
Maybe like
CREATE FUNCTION foo() RETURNS whatever AS :{source_file.txt} LANGUAGE ...;
regards, tom lane
ughts?
Yeah, if we're going to back-patch at all, that probably makes sense.
regards, tom lane
with Nathan's suggestion to define some macros for
the magic constants.
regards, tom lane
From c48b11547c6eb95ab217dddc047da5378042452c Mon Sep 17 00:00:00 2001
From: Tom Lane
Date: Fri, 26 Jan 2024 11:10:00 -0500
Subject: [PATCH v10 1/4] Some small preliminaries for pg_d
Robert Haas writes:
> On Tue, Dec 26, 2023 at 10:23 PM Tom Lane wrote:
>> I think it's a fool's errand to even try to separate different sort
>> column orderings by cost. We simply do not have sufficiently accurate
>> cost information. The previous patch in this thread
missing de-duplication logic, or something.
> This seems separate and isn't quite causing the same problems as what
> Richard wants to fix so I didn't touch this for now.
Fair enough, but I think it might be worth pursuing later.
regards, tom lane
r back patching is:
> For: Andres, David, Michael B
> Not Sure: Robert, Laurenz, Michael P
> It seems at least nobody is dead set against it.
We're talking about 1d35f705e, right? That certainly looks harmless
and potentially useful. I'm +1 for back-patching.
regards, tom lane
eceding line
res = jperOk;
is dead code and might as well get removed while you're at it.
regards, tom lane
Andrew Dunstan writes:
> On 2024-01-25 Th 14:31, Tom Lane wrote:
>> (The reported crashes seem to be happening later during a
>> recursive invocation, seemingly because JsonbType(jb) is
>> returning garbage. So there may be another bug after this one.)
> I don't think
and that quieted valgrind for this particular query and still
passes regression.
(The reported crashes seem to be happening later during a
recursive invocation, seemingly because JsonbType(jb) is
returning garbage. So there may be another bug after this one.)
regards, tom lane
be adjusting this stuff in back branches.
Yeah, I'm not sure I would change this in the back branches.
regards, tom lane
how little that proves.
Anyway, that's just a side observation unrelated to the problem
at hand. More later.
regards, tom lane
"David E. Wheeler" writes:
> On Jan 24, 2024, at 16:32, Tom Lane wrote:
>> +
>> + Predicate check expressions are required in the
>> + @@ operator (and the
>> + jsonb_path_match function), and should not be
&g
Amit Langote writes:
> On Fri, Jan 26, 2024 at 0:15 Tom Lane wrote:
>> Amit Langote writes:
>>> Ignoring the warning was my 1st thought too, because an old discussion I
>>> found about the warning was too old (2011). The style I adopted in my
>>> “fix” is
Amit Langote writes:
> On Thu, Jan 25, 2024 at 23:57 Tom Lane wrote:
>> -1 please. We should not break that abstraction for the sake
>> of ignorable warnings on ancient compilers.
> Ignoring the warning was my 1st thought too, because an old discussion I
> found about th
+ return BoolGetDatum(!escontext.error_occurred);
-1 please. We should not break that abstraction for the sake
of ignorable warnings on ancient compilers.
regards, tom lane
anging the behavior, so let's
go back to just documenting it. I spent some time going over your
text and also cleaning up nearby shaky English, and ended with v8
attached. I'd be content to commit this if it looks good to you.
regards, tom lane
diff --git a/doc/src/sgml/
est does
have some value; it's just that it's not needed very often these days.
regards, tom lane
not sure that that's a reason to remove the test scaffolding,
though. You'd probably only really use it to smoke-test some new
spinlock assembly code, and how often does anyone do that anymore?
regards, tom lane
at most two digits. I'm not especially inclined to
mess with that, and even if I were I'd think it should be a separate
patch.
> Also I think we need at least one
> negative test for OF.
OK.
regards, tom lane
e numbers change), and then v2-0002 responds to your
and Daniel's review comments.
regards, tom lane
From 8361441cda3343e0f9286bb3b51ccd3041b46807 Mon Sep 17 00:00:00 2001
From: Tom Lane
Date: Tue, 23 Jan 2024 16:58:19 -0500
Subject: [PATCH v2 1/2] Support timezone abbreviations in t
he table, forcing replan. If anyone
tried to get rid of attnotnull or make it incompletely reliable,
then we'd have problems; but AFAIK that's not being contemplated.
regards, tom lane
y, even more to the point: while this doesn't expose the
contents of a role's password, it does expose whether the role
*has* a password to every user in the installation. I doubt
that that's okay from a security standpoint. It'd need debate
at the least.
regards, tom lane
est, that's going to be confusing. Can you get the
same result without changing pg_roles?
regards, tom lane
s-1.0-69.el8.noarch
docbook-style-xsl-1.79.2-9.el8.noarch
docbook-style-dsssl-1.79-25.el8.noarch
What docbook version are you using?
regards, tom lane
ruleutils already de-duplicates table aliases across the whole
tree, but it still seems likely to be confusing. Also, people
are already pretty used to seeing $n to represent the outputs
of InitPlans, and I've not heard many complaints suggesting
that we should change that.
regar
g/arne-roland.html
(For others, click on your own name in the main cfbot page's entry for
one of your patches to find out how it spelled your name for this
purpose.)
regards, tom lane
but
TBH I think that's better anyway --- you're adding too much ambiguity
in pursuit of a very secondary use-case. The stated complaint was
"it's too hard to build UPDATE commands", which I can sympathize with.
(BTW, I wonder how much of this already exists in pgAdmin.)
regards, tom lane
ot (null)" evaluates to null. That doesn't work for allow_false,
+ * however, since "not (false)" is true rather than null.
+ */
+if (is_notclause(clause) &&
+clause_is_strict_for((Node *) get_notclausearg(clause), subexpr,
false))
+return true;
rams into this (or whether it's worth doing).
regards, tom lane
1-Prevent-jumbling-of-every-element-in-ArrayExpr.patch
patching file contrib/pg_stat_statements/Makefile
Hunk #1 FAILED at 19.
1 out of 1 hunk FAILED -- saving rejects to file
contrib/pg_stat_statements/Makefile.rej
patching file contrib/pg_stat_statements/expected/merging.out
patching file cont
Daniel Gustafsson writes:
> On 22 Jan 2024, at 03:10, Tom Lane wrote:
> + while (len > 0)
> + {
> + const datetkn *tp = datebsearch(lowtoken, zoneabbrevtbl->abbrevs,
> + zoneabbrevtbl->numabbrevs);
> My immediate react
That's
part of the reason why I really don't like the idea that the deduced
change commands will be summarily applied without the user even
seeing them.
regards, tom lane
ldn't to_timestamp() handle them?)
regards, tom lane
"David E. Wheeler" writes:
> On Jan 20, 2024, at 12:34, Tom Lane wrote:
>> It will take a predicate, but seems to always return true:
>>
>> regression=# select '{"a":[1,2,3,4,5]}'::jsonb @? '$.a[*] < 5' ;
>> ?column?
>> --
>
"David E. Wheeler" writes:
> On Jan 20, 2024, at 12:34, Tom Lane wrote:
>> Surely we're not helping anybody by leaving that behavior in place.
>> Making it do something useful, throwing an error, or returning NULL
>> all seem superior to this. I observe that @@ re
/* Return address of an already-attached segment. */
I think it's right --- the comments for dsm_attach explicitly
point out that a NULL return is possible. You need to handle
that scenario in some way other than SIGSEGV.
regards, tom lane
Peter Eisentraut writes:
> On 20.01.24 17:03, Tom Lane wrote:
>> * I gather that the point here is to change some generated anchor
>> tags. Would any of these tags be things people would be likely
>> to have bookmarked?
> No, because the problem is that the anchor name
701 - 800 of 15280 matches
Mail list logo
