Replace use of deprecated Python module distutils.sysconfig
With Python 3.10, configure spits out warnings about the module
distutils.sysconfig being deprecated and scheduled for removal in
Python 3.12. Change the uses in configure to use the module sysconfig
instead. The logic stays the same.
Improve code clarity in epilogue of UTF-8 verification fast path
The previous coding was correct, but the style and commentary were a bit
vague about which operations had to happen, in what circumstances, and
in what order. Rearrange so that the epilogue does nothing in the DFA END
state. That all
Fix psql \d's query for identifying parent triggers.
The original coding (from c33869cc3) failed with "more than one row
returned by a subquery used as an expression" if there were unrelated
triggers of the same tgname on parent partitioned tables. (That's
possible because statement-level trigger
Fix psql \d's query for identifying parent triggers.
The original coding (from c33869cc3) failed with "more than one row
returned by a subquery used as an expression" if there were unrelated
triggers of the same tgname on parent partitioned tables. (That's
possible because statement-level trigger
Fix psql \d's query for identifying parent triggers.
The original coding (from c33869cc3) failed with "more than one row
returned by a subquery used as an expression" if there were unrelated
triggers of the same tgname on parent partitioned tables. (That's
possible because statement-level trigger
Hi,
On 2022-01-18 10:18:36 +0900, Michael Paquier wrote:
> On Mon, Jan 17, 2022 at 11:48:02PM +, Andres Freund wrote:
> > tests: Consistently use pg_basebackup -cfast --no-sync to accelerate tests.
> >
> > Most tests invoking pg_basebackup themselves did not yet use -cfast, which
> > makes pg
Hi Andres,
On Mon, Jan 17, 2022 at 11:48:02PM +, Andres Freund wrote:
> tests: Consistently use pg_basebackup -cfast --no-sync to accelerate tests.
>
> Most tests invoking pg_basebackup themselves did not yet use -cfast, which
> makes pg_basebackup take considerably longer. The only reason th
tests: Consistently use pg_basebackup -cfast --no-sync to accelerate tests.
Most tests invoking pg_basebackup themselves did not yet use -cfast, which
makes pg_basebackup take considerably longer. The only reason this didn't
cause the tests to take many minutes is that spread checkpoints only thro
heap pruning: Only call BufferGetBlockNumber() once.
BufferGetBlockNumber() is not that cheap and obviously cannot change during
one heap_prune_page(), so only call it once. We might be able to do better and
pass the block number from the caller, but that'd be a larger change...
Discussion:
http
On Tue, Jan 18, 2022 at 9:37 AM Andres Freund wrote:
> diff -w -U3 c:/cirrus/src/test/recovery/../regress/expected/reloptions.out
> c:/cirrus/src/test/recovery/results/reloptions.out
> --- c:/cirrus/src/test/recovery/../regress/expected/reloptions.out
> 2022-01-17 07:08:52.779337800 +
>
Hi,
On 2022-01-18 07:47:48 +1300, Thomas Munro wrote:
> > No idea what's going on here, but I guess that we'd better show up the
> > contents of regression.diffs in the TAP logs if it exists.
>
> Hmm. Yeah.
It already is in the regress_log_*, but I agree, it'd be good to add it to the
normal ou
Hi,
On 2022-01-17 16:02:34 +0900, Michael Paquier wrote:
> On Mon, Jan 17, 2022 at 03:35:48AM +, Thomas Munro wrote:
> > Test replay of regression tests, attempt II.
> >
> > See commit message for 123828a7fa563025d0ceee10cf1b2a253cd05319. The
> > only change this time is the order of the arg
Move 027_stream_regress.pl's output to tmp_check.
Cleanup for commit f47ed79c.
Discussion:
https://postgr.es/m/CA%2BhUKGKU%3DtiZoE7vp7qYFQNPdBd2pHoaOwkPMDg9YWk1h%3DFtmQ%40mail.gmail.com
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/35b2803cf29a39b1adaf55b8b376b9
pg_upgrade: Preserve relfilenodes and tablespace OIDs.
Currently, database OIDs, relfilenodes, and tablespace OIDs can all
change when a cluster is upgraded using pg_upgrade. It seems better
to preserve them, because (1) it makes troubleshooting pg_upgrade
easier, since you don't have to do a lot
On Mon, Jan 17, 2022 at 8:02 PM Michael Paquier wrote:
> Butterflyfish has just failed in this new test:
> https://buildfarm.postgresql.org/cgi-bin/show_history.pl?nm=butterflyfish&br=HEAD
>
> Ad the pg_regress command has failed one of the tests:
> reloptions ... FAILED
Avoid calling strerror[_r] in PQcancel().
PQcancel() is supposed to be safe to call from a signal handler,
and indeed psql uses it that way. All of the library functions
it uses are specified to be async-signal-safe by POSIX ...
except for strerror. Neither plain strerror nor strerror_r
are cons
Avoid calling strerror[_r] in PQcancel().
PQcancel() is supposed to be safe to call from a signal handler,
and indeed psql uses it that way. All of the library functions
it uses are specified to be async-signal-safe by POSIX ...
except for strerror. Neither plain strerror nor strerror_r
are cons
Avoid calling gettext() in signal handlers.
It seems highly unlikely that gettext() can be relied on to be
async-signal-safe. psql used to understand that, but someone got
it wrong long ago in the src/bin/scripts/ version of handle_sigint,
and then the bad idea was perpetuated when those two vers
Avoid calling strerror[_r] in PQcancel().
PQcancel() is supposed to be safe to call from a signal handler,
and indeed psql uses it that way. All of the library functions
it uses are specified to be async-signal-safe by POSIX ...
except for strerror. Neither plain strerror nor strerror_r
are cons
Avoid calling gettext() in signal handlers.
It seems highly unlikely that gettext() can be relied on to be
async-signal-safe. psql used to understand that, but someone got
it wrong long ago in the src/bin/scripts/ version of handle_sigint,
and then the bad idea was perpetuated when those two vers
Avoid calling strerror[_r] in PQcancel().
PQcancel() is supposed to be safe to call from a signal handler,
and indeed psql uses it that way. All of the library functions
it uses are specified to be async-signal-safe by POSIX ...
except for strerror. Neither plain strerror nor strerror_r
are cons
Avoid calling strerror[_r] in PQcancel().
PQcancel() is supposed to be safe to call from a signal handler,
and indeed psql uses it that way. All of the library functions
it uses are specified to be async-signal-safe by POSIX ...
except for strerror. Neither plain strerror nor strerror_r
are cons
Avoid calling gettext() in signal handlers.
It seems highly unlikely that gettext() can be relied on to be
async-signal-safe. psql used to understand that, but someone got
it wrong long ago in the src/bin/scripts/ version of handle_sigint,
and then the bad idea was perpetuated when those two vers
Avoid calling gettext() in signal handlers.
It seems highly unlikely that gettext() can be relied on to be
async-signal-safe. psql used to understand that, but someone got
it wrong long ago in the src/bin/scripts/ version of handle_sigint,
and then the bad idea was perpetuated when those two vers
Avoid calling strerror[_r] in PQcancel().
PQcancel() is supposed to be safe to call from a signal handler,
and indeed psql uses it that way. All of the library functions
it uses are specified to be async-signal-safe by POSIX ...
except for strerror. Neither plain strerror nor strerror_r
are cons
Avoid calling gettext() in signal handlers.
It seems highly unlikely that gettext() can be relied on to be
async-signal-safe. psql used to understand that, but someone got
it wrong long ago in the src/bin/scripts/ version of handle_sigint,
and then the bad idea was perpetuated when those two vers
Avoid calling gettext() in signal handlers.
It seems highly unlikely that gettext() can be relied on to be
async-signal-safe. psql used to understand that, but someone got
it wrong long ago in the src/bin/scripts/ version of handle_sigint,
and then the bad idea was perpetuated when those two vers
On Tue, Jan 18, 2022 at 6:24 AM Tom Lane wrote:
> I wrote:
> > I'm quite appalled that this patch has apparently added an entire new run
> > of the core regression tests to the standard check-world/buildfarm cycle.
I wonder if there is a good way to share the resulting data directory
with the pg_
I wrote:
> I'm quite appalled that this patch has apparently added an entire new run
> of the core regression tests to the standard check-world/buildfarm cycle.
Not only that, but it leaves junk that is neither cleaned by "make clean"
nor .gitignored:
$ git status
On branch master
Your branch is
Michael Paquier writes:
> On Mon, Jan 17, 2022 at 03:35:48AM +, Thomas Munro wrote:
>> Test replay of regression tests, attempt II.
> Butterflyfish has just failed in this new test:
> https://buildfarm.postgresql.org/cgi-bin/show_history.pl?nm=butterflyfish&br=HEAD
> Ad the pg_regress command
Peter Eisentraut writes:
> Add Boolean node
FTR, there should have been a catversion bump here, since this
certainly broke stored views.
regards, tom lane
Fix for new Boolean node
The token in nodeTokenType() is actually the whole rest of the string,
so we need to take into account the length to do the correct
comparison.
Without this, postgres_fdw tests fail under
-DWRITE_READ_PARSE_PLAN_TREES.
Branch
--
master
Details
---
https://git.po
Add Boolean node
Before, SQL-level boolean constants were represented by a string with
a cast, and internal Boolean values in DDL commands were usually
represented by Integer nodes. This takes the place of both of these
uses, making the intent clearer and having some amount of type safety.
Revie
33 matches
Mail list logo
