Re: do only critical work during single-user vacuum?

On Wed, Feb 16, 2022 at 6:17 AM Peter Geoghegan wrote: > > On Tue, Feb 15, 2022 at 9:28 AM Peter Geoghegan wrote: > > I did notice from my own testing of the failsafe (by artificially > > inducing wraparound failure using an XID burning C function) that > > autovacuum seemed to totally correct t

Re: Design of pg_stat_subscription_workers vs pgstats

On Tue, Feb 15, 2022 at 11:47 PM Andres Freund wrote: > > Hi, > > On 2022-02-04 09:23:06 +0530, Amit Kapila wrote: > > On Thu, Feb 3, 2022 at 3:25 PM Peter Eisentraut > > wrote: > > > > > > On 02.02.22 07:54, Amit Kapila wrote: > > > > > > > Sure, but is this the reason you want to store all the

Re: Design of pg_stat_subscription_workers vs pgstats

On Tue, Feb 15, 2022 at 11:56 PM Andres Freund wrote: > > On 2022-02-03 13:33:08 +0900, Masahiko Sawada wrote: > > I see that important information such as error-XID that can be used > > for ALTER SUBSCRIPTION SKIP needs to be stored in a reliable way, and > > using system catalogs is a reasonable

Re: Design of pg_stat_subscription_workers vs pgstats

On Wed, Feb 16, 2022 at 12:01 AM Robert Haas wrote: > > On Thu, Jan 27, 2022 at 12:46 AM Andres Freund wrote: > > Only if either the user wants to drop all stats, or somehow knows the oids > > of > > already dropped tables... > > If it's really true that we can end up storing data for dropped >

Re: Race conditions in 019_replslot_limit.pl

On Wed, Feb 16, 2022 at 3:22 PM Kyotaro Horiguchi wrote: > > At Wed, 16 Feb 2022 14:58:23 +0900, Masahiko Sawada > wrote in > > Or it's possible that the process took a time to clean up the > > temporary replication slot? > > Checkpointer may take ReplicationSlotControlLock. Dead lock between >

Re: Table AM and DROP TABLE [ Was: Table AM and DDLs]

On 27/09/2021 14:59, Aleksander Alekseev wrote: Hi hackers, As a matter of fact, I think the patch I suggested is the right approach: let me elaborate on why. [...] It is straightforward to replace it by implementing the Table AM methods above, but we are missing a callback on dropping the tabl

Re: Column Filtering in Logical Replication

On Wed, Feb 16, 2022 at 6:09 AM Tomas Vondra wrote: > > On 2/16/22 01:33, Alvaro Herrera wrote: > > > >> 3) partitioning with pubivaroot=false > >> > >> When a partitioned table is added with (pubviaroot=false), it should not be > >> subject to column filter on the parent relation, which is the sa

Re: Column Filtering in Logical Replication

On Wed, Feb 16, 2022 at 5:03 AM Tomas Vondra wrote: > > Hi, > > Here's an updated version of the patch, rebased to current master. Parts > 0002 and 0003 include various improvements based on review by me and > another one by Peter Smith [1]. > > Part 0003 reworks and significantly extends the TAP

Re: Non-decimal integer literals

On 13.02.22 13:14, John Naylor wrote: On Wed, Jan 26, 2022 at 10:10 PM Peter Eisentraut wrote: [v8 patch] 0001-0004 seem pretty straightforward. These have been committed. 0005: {realfail1} { - /* - * throw back the [Ee], and figure out whether what - * remains is an {integer} or {d

Re: initdb / bootstrap design

On 16.02.22 03:12, Andres Freund wrote: Sure, there's a few tokens that we replace in initdb. As it turns out there's only two rows that are actually variable. The username of the initial superuser in pg_authid and the pg_database row for template 1, where encoding, lc_collate and lc_ctype varies

Re: bailing out in tap tests nearly always a bad idea

On 14.02.22 00:22, Andres Freund wrote: Does anybody want to defend / explain the use of BAIL_OUT? I think this was my mistake when this was originally added. I agree it should be changed.

Re: pgsql: Move scanint8() to numutils.c

On 15.02.22 20:00, Joe Conway wrote: I'm not saying it is hard to fix, but it seems a bit cavalier to not even discuss the potential for breakage. If nothing else we should flag this as something for the release notes. I don't think we have ever systematically release-noted backend API change

RE: Optionally automatically disable logical replication subscriptions on error

On Tuesday, February 15, 2022 2:19 PM I wrote > On Monday, February 14, 2022 8:58 PM Amit Kapila > > 2. Can we move the code related to tablesync worker and its error > > handing (the code insider if (am_tablesync_worker())) to a separate > > function say > > LogicalRepHandleTableSync() or somethin

Re: Proposal for internal Numeric to Uint64 conversion function.

On 16.02.22 06:00, Amul Sul wrote: Currently, numeric_pg_lsn is the only one that accepts the Numeric value and converts to uint64 and that is the reason all the type conversion code is embedded into it. There are other functions such as numeric_int8() that work similarly. If you are going to

Re: pg_receivewal.exe unhandled exception in zlib1.dll

On Tue, Feb 15, 2022 at 5:25 PM Andres Freund wrote: > > > If this is something we want to discard altogether, we can check at build > > time with 'dumpbin' to ensure that all dlls share the same vcruntime.dll. > > I think these days it's mostly a question of ucrtbase.dll vs ucrtbased.dll, > righ

Re: Fix a comment in worker.c

On Wed, Feb 16, 2022 at 5:57 AM Masahiko Sawada wrote: > > While reading the code, I realized that the second sentence of the > following comment in worker.c is not correct: > >/* > * Exit if the subscription was disabled. This normally should not happen > * as the worker gets killed d

Re: Design of pg_stat_subscription_workers vs pgstats

On Wed, Feb 16, 2022 at 5:49 PM Amit Kapila wrote: > > On Tue, Feb 15, 2022 at 11:56 PM Andres Freund wrote: > > > > On 2022-02-03 13:33:08 +0900, Masahiko Sawada wrote: > > > I see that important information such as error-XID that can be used > > > for ALTER SUBSCRIPTION SKIP needs to be stored

Re: Proposal for internal Numeric to Uint64 conversion function.

On Wed, Feb 16, 2022 at 4:50 PM Peter Eisentraut wrote: > > On 16.02.22 06:00, Amul Sul wrote: > > Currently, numeric_pg_lsn is the only one that accepts the Numeric > > value and converts to uint64 and that is the reason all the type > > conversion code is embedded into it. > > There are other fu

Re: Adding CI to our tree

On 13.02.22 09:30, Andres Freund wrote: BTW, docs can be built in parallel, and CI is using BUILD_JOBS: 4. /usr/bin/xmllint --path . --noout --valid postgres.sgml /usr/bin/xmllint --path . --noout --valid postgres.sgml /usr/bin/xsltproc --path . --stringparam pg.version '15devel' stylesheet.xsl

minor code correction in typecmds.c

Hi, The attached patch replaces the hard-coded type alignment value with the defined macro for the same. -- Regards, Amul Sul EDB: http://www.enterprisedb.com diff --git a/src/backend/commands/typecmds.c b/src/backend/commands/typecmds.c index ce8c1badb39..ef6f14785a0 100644 --- a/src/backend/com

Re: [PATCH] Fix out-of-bouds access (src/common/wchar.c)

Em qua., 16 de fev. de 2022 às 00:12, Kyotaro Horiguchi < horikyota@gmail.com> escreveu: > At Tue, 15 Feb 2022 09:17:34 -0300, Ranier Vilela > wrote in > > Per Coverity. > > Thanks for the source:) > > > Like the function pg_encoding_max_length_sql > > (src/backend/utils/mb/mbutils.c) > > Onl

Re: minor code correction in typecmds.c

On Wed, Feb 16, 2022 at 7:17 PM Amul Sul wrote: > > Hi, > > The attached patch replaces the hard-coded type alignment value with > the defined macro for the same. Pushed, thanks! -- John Naylor EDB: http://www.enterprisedb.com

Re: pgsql: Add TAP test to automate the equivalent of check_guc

Re: Michael Paquier > Hearing nothing, I have looked once again at this stuff and tested it > with what Debian was doing. And that looks to work fine for > everything we care about, so applied with the use of a relative path > to find postgresql.conf.sample in the source tree. The build works wit

Re: postgres_fdw: using TABLESAMPLE to collect remote sample

Hello,   I find it a great idea to use TABLESAMPLE in postgres_fdw ANALYZE. Let me offer you some ideas how to resolve you problems.   Tomas Vondra < tomas.von...@enterprisedb.com > writes: > The other issue is which sampling method to use - we have SYSTEM and  > BERNOULLI built in, and the tsm_sy

Re: support for CREATE MODULE

On Wed, Feb 16, 2022 at 12:20 AM Pavel Stehule wrote: > > The main issue in this case is fact, so plpgsql is fully integrated to > Postgres (on second hand this integration is a big performance win). It is > pretty different from PL/SQL. In Oracle you have a package, or any other > similar featur

Re: pgsql: Move scanint8() to numutils.c

On Wed, Feb 16, 2022 at 6:09 AM Peter Eisentraut wrote: > I don't think we have ever systematically release-noted backend API > changes. I don't know whether that would be useful, but a complete > treatment would be a significant effort (speaking from experience of > porting the mentioned pglogic

Re: postgres_fdw and skip locked

On Mon, Feb 14, 2022 at 4:23 PM Alexander Pyhalov wrote: > > Hi. > > Now select ... for update ... [skip locked|nowait] options are not > pushed down to remote servers. I see the only reason is that we can > speak to pre-9.5 server, which doesn't understand skip locked option. > Are there any othe

Re: some aspects of our qsort might not be ideal

On Wed, Feb 16, 2022 at 2:29 AM John Naylor wrote: > Does anyone see a reason not to put in the necessary work to try it out? Seems reasonable to me. It's always a bit difficult, I feel, to know what test cases to use - almost any idea is going to have some case where it's worse than what we do t

Re: PGroonga index-only scan problem with yesterday’s PostgreSQL updates

Am Montag, dem 14.02.2022 um 16:02 -0500 schrieb Andrew Dunstan: > It occurred to me that this wasn't very well documented, so I created > some docco: > < > https://wiki.postgresql.org/wiki/PostgreSQL_Buildfarm_Howto#Testing_Ad > ditional_Software> Thx Andrew, i wasn't aware of this, too! I'm goin

Re: ICU for global collation

On 02.02.22 14:01, Peter Eisentraut wrote: Here is the main patch rebased on the various changes that have been committed in the meantime.  There is still some work to be done on the user interfaces of initdb, createdb, etc. I have split out the database-level collation version tracking into a

Re: Time to drop plpython2?

On 15.02.22 22:40, Andres Freund wrote: 1: plpython: Reject Python 2 during build configuration. There is a bit of redundancy in the new wording in installation.sgml: "The minimum required version is Python 3.2 or later." There is also a small bit in install-windows.sgml that would be worth

Re: support for CREATE MODULE

st 16. 2. 2022 v 14:17 odesílatel Jim Mlodgenski napsal: > > > On Wed, Feb 16, 2022 at 12:20 AM Pavel Stehule > wrote: > >> >> The main issue in this case is fact, so plpgsql is fully integrated to >> Postgres (on second hand this integration is a big performance win). It is >> pretty different

Re: postgres_fdw and skip locked

Ashutosh Bapat писал 2022-02-16 16:40: On Mon, Feb 14, 2022 at 4:23 PM Alexander Pyhalov wrote: Hi. Now select ... for update ... [skip locked|nowait] options are not pushed down to remote servers. I see the only reason is that we can speak to pre-9.5 server, which doesn't understand skip loc

Re: adding 'zstd' as a compression algorithm

On Tue, Feb 15, 2022 at 9:33 PM Michael Paquier wrote: > On Tue, Feb 15, 2022 at 02:33:32PM -0600, Justin Pryzby wrote: > > What I mean is that any patches which *use* the zstd support should update > > those for completeness. > > > > doc/src/sgml/config.sgml | 14 +--

Re: pgsql: Move scanint8() to numutils.c

Hi, On Wed, Feb 16, 2022 at 08:24:31AM -0500, Robert Haas wrote: > On Wed, Feb 16, 2022 at 6:09 AM Peter Eisentraut > wrote: > > I don't think we have ever systematically release-noted backend API > > changes. I don't know whether that would be useful, but a complete > > treatment would be a sig

Re: refactoring basebackup.c (zstd)

On Tue, Feb 15, 2022 at 12:59 PM Justin Pryzby wrote: > There's superfluous changes to ./configure unrelated to the changes in > configure.ac. Probably because you're using a different version of autotools, > or a vendor's patched copy. You can remove the changes with git checkout -p > or > sim

Re: refactoring basebackup.c

On 2022-Feb-14, Robert Haas wrote: > A more consistent way of writing the supported syntax would be like this: > > -Z, --compress={[{client|server}-]{gzip|lz4}}[:LEVEL]|LEVEL|none} > > I would be somewhat inclined to leave the level-only variant > undocumented and instead write it like this: >

Re: do only critical work during single-user vacuum?

On Wed, Feb 16, 2022 at 12:43 AM John Naylor wrote: > I'll put some effort in finding any way that it might not be robust. > After that, changing the message and docs is trivial. Great, thanks John. -- Peter Geoghegan

Re: refactoring basebackup.c

On Wed, Feb 16, 2022 at 11:11 AM Alvaro Herrera wrote: > This is hard to interpret for humans though because of the nested > brackets and braces. It gets considerably easier if you split it in > separate variants: > >-Z, --compress=[{client|server}-]{gzip|lz4}[:LEVEL] >-Z, --compress=LEVE

Re: USE_BARRIER_SMGRRELEASE on Linux?

On Tue, Feb 15, 2022 at 10:57:32PM -0800, Nathan Bossart wrote: > On Tue, Feb 15, 2022 at 10:14:04PM -0800, Nathan Bossart wrote: >> It looks like register_unlink_segment() is called prior to the checkpoint, >> but the checkpointer is not calling RememberSyncRequest() until after >> SyncPreCheckpoi

Re: do only critical work during single-user vacuum?

On Wed, Feb 16, 2022 at 2:29 AM Peter Geoghegan wrote: > > On Mon, Feb 14, 2022 at 10:04 PM John Naylor > wrote: > > Well, the point of inventing this new vacuum mode was because I > > thought that upon reaching xidStopLimit, we couldn't issue commands, > > period, under the postmaster. If it was

Re: Implementing Incremental View Maintenance

Hi, Nagata-san I am very interested in IMMV and read your patch but have some comments in v25-0007-Add-Incremental-View-Maintenance-support.patch and want to discuss with you. + /* For IMMV, we need to rewrite matview query */ + query = rewriteQueryForIMMV(query, into

check-world has suddenly started spewing stuff on stderr

$ make check-world >/dev/null 2022-02-16 11:57:47.548 EST [3339702] LOG: database system was not properly shut down; automatic recovery in progress 2022-02-16 11:57:47.612 EST [3339713] LOG: database system was not properly shut down; automatic recovery in progress 2022-02-16 11:57:59.379 EST [

Re: Race conditions in 019_replslot_limit.pl

Hi, On 2022-02-16 18:04:14 +0900, Masahiko Sawada wrote: > On Wed, Feb 16, 2022 at 3:22 PM Kyotaro Horiguchi > wrote: > > > > At Wed, 16 Feb 2022 14:58:23 +0900, Masahiko Sawada > > wrote in > > > Or it's possible that the process took a time to clean up the > > > temporary replication slot? >

Re: USE_BARRIER_SMGRRELEASE on Linux?

On Wed, Feb 16, 2022 at 08:44:42AM -0800, Nathan Bossart wrote: > On Tue, Feb 15, 2022 at 10:57:32PM -0800, Nathan Bossart wrote: >> On Tue, Feb 15, 2022 at 10:14:04PM -0800, Nathan Bossart wrote: >>> It looks like register_unlink_segment() is called prior to the checkpoint, >>> but the checkpointe

Re: refactoring basebackup.c

Hi Everyone, So, I went ahead and have now also implemented client side decompression for zstd. Robert separated[1] the ZSTD configure switch from my original patch of server side compression and also added documentation related to the switch. I have included that patch here in the patch series f

Re: do only critical work during single-user vacuum?

On Wed, Feb 16, 2022 at 8:48 AM Masahiko Sawada wrote: > FYI, I've tested the situation that I assumed autovacuum can not > correct the problem; when the system had already crossed xidStopLimit, > it keeps failing to vacuum on tables that appear in the front of the > list and have sufficient garba

Re: initdb / bootstrap design

Hi, On 2022-02-16 11:47:31 +0100, Peter Eisentraut wrote: > On 16.02.22 03:12, Andres Freund wrote: > > Sure, there's a few tokens that we replace in initdb. As it turns out > > there's > > only two rows that are actually variable. The username of the initial > > superuser in pg_authid and the pg

Re: do only critical work during single-user vacuum?

On Wed, Feb 16, 2022 at 12:51 PM Peter Geoghegan wrote: > Good news! +1. But I think we might want to try to write documentation around this. We should explicitly tell people NOT to use single-user mode, because that stupid message has been there for a long time and a lot of people have probably

improve --with-lz4 install documentation

Now that lz4 also supports backup compression, decompression, and more future enhancements that can be done here, I think it is better to make the --with-lz4 description more generic than adding specific details in there. Attached is the patch to remove the specifics related to WAL and TOAST compr

Re: PGEventProcs must not be allowed to break libpq

I wrote: > ... more generally, it seems to me that allowing a failing PGEventProc > to cause this to happen is just not sane. It breaks absolutely > every guarantee you might think we have about how libpq will behave. > As an example that seems very plausible currently, if an event proc > doesn't

Re: do only critical work during single-user vacuum?

On Wed, Feb 16, 2022 at 9:56 AM Robert Haas wrote: > +1. But I think we might want to try to write documentation around > this. We should explicitly tell people NOT to use single-user mode, > because that stupid message has been there for a long time and a lot > of people have probably internalize

Re: do only critical work during single-user vacuum?

Hi, On 2022-02-16 10:14:19 -0800, Peter Geoghegan wrote: > Absolutely -- couldn't agree more. Do you think it's worth targeting > 14 here, or just HEAD? I'd go for HEAD first, but wouldn't protest against 14. > I'm pretty sure that some people believe that wraparound can cause > actual data cor

Re: initdb / bootstrap design

Andres Freund writes: > Sure, there's a few tokens that we replace in initdb. As it turns out there's > only two rows that are actually variable. The username of the initial > superuser in pg_authid and the pg_database row for template 1, where encoding, > lc_collate and lc_ctype varies. The rest

Re: do only critical work during single-user vacuum?

On Wed, Feb 16, 2022 at 10:18 AM Andres Freund wrote: > > I'm pretty sure that some people believe that wraparound can cause > > actual data corruption > > Well, historically they're not wrong. True, but the most recent version where that's actually possible is PostgreSQL 8.0, which was released

Re: Allow root ownership of client certificate key

Hi Tom, On 1/18/22 14:41, Tom Lane wrote: David Steele writes: [ client-key-perm-002.patch ] I took a quick look at this and agree with the proposed behavior change, but also with your self-criticisms: We may want to do the same on the server side to make the code blocks look more similar.

Re: do only critical work during single-user vacuum?

On Wed, Feb 16, 2022 at 10:27 AM Peter Geoghegan wrote: > True, but the most recent version where that's actually possible is > PostgreSQL 8.0, which was released in early 2005. It just occurred to me that the main historic reason for the single user mode advice was the lack of virtual XIDs. The

Re: Observability in Postgres

On Wed, 2022-02-16 at 02:10 -0500, Greg Stark wrote: > On Tue, 15 Feb 2022 at 17:37, Magnus Hagander wrote: > > > But I think you'll run into a different problem much earlier. Pretty > > much everything out there is going to want to speak http(s). How are > > you going to terminate that, especial

Re: USE_BARRIER_SMGRRELEASE on Linux?

Hi, On 2022-02-16 09:37:21 -0800, Nathan Bossart wrote: > I've also figured out a > way to reproduce the issue without the pre-allocation patches applied: > > 1. In checkpointer.c, add a 30 second sleep before acquiring ckpt_lck to >increment ckpt_started. > 2. In session 1, run the following

Re: Observability in Postgres

Hi, On Wed, Feb 16, 2022 at 12:48:11AM -0500, Greg Stark wrote: > But on further thought I think what you're asking is whether there are > standard database metrics and standard names for them. A lot of this > work has already been done with pg_exporter but it is worth looking at > other database

Re: initdb / bootstrap design

Hi, On 2022-02-16 13:24:41 -0500, Tom Lane wrote: > I remembered the reason why it's done that way: if we replaced those > values during genbki.pl, the contents of postgres.bki would become > architecture-dependent, belying its distribution as a "share" file. > While we don't absolutely have to co

Re: Report checkpoint progress with pg_stat_progress_checkpoint (was: Report checkpoint progress in server logs)

On Tue, 15 Feb 2022 at 13:16, Nitin Jadhav wrote: > > > Apart from above fields, I am planning to add few more fields to the > > view in the next patch. That is, process ID of the backend process > > which triggered a CHECKPOINT command, checkpoint start location, filed > > to indicate whether it

Re: Lowering the ever-growing heap->pd_lower

On Tue, Feb 15, 2022 at 10:48 AM Matthias van de Meent wrote: > Peter Geoghegan asked for good arguments for the two changes > implemented. Below are my arguments detailed, with adversarial loads > that show the problematic behaviour of the line pointer array that is > fixed with the patch. Why i

Re: Time to drop plpython2?

Hi, On 2022-02-16 15:43:19 +0100, Peter Eisentraut wrote: > On 15.02.22 22:40, Andres Freund wrote: > > 1: plpython: Reject Python 2 during build configuration. > > There is a bit of redundancy in the new wording in installation.sgml: > > "The minimum required version is Python 3.2 or > later."

Re: Report checkpoint progress with pg_stat_progress_checkpoint (was: Report checkpoint progress in server logs)

On Thu, 10 Feb 2022 at 07:53, Nitin Jadhav wrote: > > > > We need at least a trace of the number of buffers to sync (num_to_scan) > > > before the checkpoint start, instead of just emitting the stats at the > > > end. > > > > > > Bharat, it would be good to show the buffers synced counter and th

Re: Time to drop plpython2?

On 02/16/22 14:58, Andres Freund wrote: >> "The minimum required version is Python 3.2 or >> later." > > I stared for a bit, and I just don't see the redundancy? "minimum ... or later" maybe? Regards, -Chap

Re: do only critical work during single-user vacuum?

On Wed, Feb 16, 2022 at 1:28 PM Peter Geoghegan wrote: > On Wed, Feb 16, 2022 at 10:18 AM Andres Freund wrote: > > > I'm pretty sure that some people believe that wraparound can cause > > > actual data corruption > > > > Well, historically they're not wrong. > > True, but the most recent version

Re: do only critical work during single-user vacuum?

On Wed, Feb 16, 2022 at 2:18 PM Peter Geoghegan wrote: > It seems as if the advice about single user mode persisted for no > great reason at all. Technically there were some remaining reasons to > keep it around (like the truncation thing), but overall these > secondary reasons could have been add

Re: Lowering the ever-growing heap->pd_lower

On Wed, 16 Feb 2022 at 20:54, Peter Geoghegan wrote: > > On Tue, Feb 15, 2022 at 10:48 AM Matthias van de Meent > wrote: > > Peter Geoghegan asked for good arguments for the two changes > > implemented. Below are my arguments detailed, with adversarial loads > > that show the problematic behaviou

Re: check-world has suddenly started spewing stuff on stderr

On 16/02/2022 19:04, Tom Lane wrote: $ make check-world >/dev/null 2022-02-16 11:57:47.548 EST [3339702] LOG: database system was not properly shut down; automatic recovery in progress 2022-02-16 11:57:47.612 EST [3339713] LOG: database system was not properly shut down; automatic recovery in

Re: do only critical work during single-user vacuum?

On Wed, Feb 16, 2022 at 12:11 PM Robert Haas wrote: > No, I think it's PostgreSQL 13, because before the vacuum failsafe > thing you could end up truncating enough tables during vacuum > operations to actually wrap around. Why wouldn't the xidStopLimit thing prevent actual incorrect answers to qu

Re: Time to drop plpython2?

On 2022-02-16 15:05:36 -0500, Chapman Flack wrote: > On 02/16/22 14:58, Andres Freund wrote: > >> "The minimum required version is Python 3.2 or > >> later." > > > > I stared for a bit, and I just don't see the redundancy? > > "minimum ... or later" maybe? Ah. Thanks.

Re: initdb / bootstrap design

Andres Freund writes: > On 2022-02-16 13:24:41 -0500, Tom Lane wrote: >> I remembered the reason why it's done that way: if we replaced those >> values during genbki.pl, the contents of postgres.bki would become >> architecture-dependent, belying its distribution as a "share" file. > Hm. Architec

killing perl2host

Largely following a recipe from Andres, I have migrated buildfarm animals fairywren and jacana to a setup that shouldn't need (and in fact won't be able to use) PostgreSQL::Test:Utils::perl2host(). AFAICT these two are the only buildfarm animals that run TAP tests under msys. See discussion at

Re: USE_BARRIER_SMGRRELEASE on Linux?

On Wed, Feb 16, 2022 at 11:27:31AM -0800, Andres Freund wrote: > Did you check whether this is a problem recently introduced or long-lived? I've reproduced it back to v9.3. I'm assuming it's much older than that. > Does USE_BARRIER_SMGRRELEASE actually prevent this problem? Or was it just > that

Re: killing perl2host

Hi, On 2022-02-16 15:46:28 -0500, Andrew Dunstan wrote: > I suggest that we apply this patch: +1 > and if nothing breaks in a few days I will set about a more thorough > removal of perl2host() and adjusting everywhere it's called, and we can > forget that the whole sorry mess ever happened :-)

Re: do only critical work during single-user vacuum?

On Wed, Feb 16, 2022 at 3:21 PM Peter Geoghegan wrote: > On Wed, Feb 16, 2022 at 12:11 PM Robert Haas wrote: > > No, I think it's PostgreSQL 13, because before the vacuum failsafe > > thing you could end up truncating enough tables during vacuum > > operations to actually wrap around. > > Why wou

Re: refactoring basebackup.c

On Wed, Feb 16, 2022 at 12:46 PM Jeevan Ladhe wrote: > So, I went ahead and have now also implemented client side decompression > for zstd. > > Robert separated[1] the ZSTD configure switch from my original patch > of server side compression and also added documentation related to > the switch. I

Re: killing perl2host

On 2/16/22 16:01, Andres Freund wrote: > Hi, > > On 2022-02-16 15:46:28 -0500, Andrew Dunstan wrote: >> I suggest that we apply this patch: > +1 > >> and if nothing breaks in a few days I will set about a more thorough >> removal of perl2host() and adjusting everywhere it's called, and we can >>

Preventing indirection for IndexPageGetOpaque for known-size page special areas

Hi, I noticed that effectively all indexes use the special region of a page to store some index-specific data on the page. In all cases I've noticed, this is a constant-sized struct, located at what is effectively a fixed offset from the end of the page; indicated on the page by pd_special; and ac

Re: adding 'zstd' as a compression algorithm (initdb/lz4)

On Tue, Feb 15, 2022 at 11:54:10AM -0800, Andres Freund wrote: > > Isn't it an incontrovertible fact that LZ4 is superior to pglz in > > every way? LZ4 is pretty much its successor. And so it seems totally > > fine to assume that users will always want to use the clearly better > > option, and that

Small TAP tests cleanup for Windows and unused modules

Seeing msys in TAP tests mentioned in a thread [1] tonight reminded me about two related (well, one of them) patches I had sitting around, so rather than forgetting again here are some small cleanups. 0001 attempts to streamline how we detect Windows in the TAP tests (after that there is a single

Re: do only critical work during single-user vacuum?

On Wed, Feb 16, 2022 at 1:04 PM Robert Haas wrote: > No, what I'm saying is that people running older versions routinely > run VACUUM in single-user mode because otherwise it fails due to the > truncation issue. But once they go into single-user mode they lose > protection. Seems logically consis

Re: Small TAP tests cleanup for Windows and unused modules

On 2/16/22 16:36, Daniel Gustafsson wrote: > Seeing msys in TAP tests mentioned in a thread [1] tonight reminded me about > two related (well, one of them) patches I had sitting around, so rather than > forgetting again here are some small cleanups. > > 0001 attempts to streamline how we detect W

Re: Small TAP tests cleanup for Windows and unused modules

> On 16 Feb 2022, at 23:04, Andrew Dunstan wrote: > > On 2/16/22 16:36, Daniel Gustafsson wrote: >> Seeing msys in TAP tests mentioned in a thread [1] tonight reminded me about >> two related (well, one of them) patches I had sitting around, so rather than >> forgetting again here are some small

Re: Small TAP tests cleanup for Windows and unused modules

On 2/16/22 17:04, Andrew Dunstan wrote: > On 2/16/22 16:36, Daniel Gustafsson wrote: >> Seeing msys in TAP tests mentioned in a thread [1] tonight reminded me about >> two related (well, one of them) patches I had sitting around, so rather than >> forgetting again here are some small cleanups. >>

Re: killing perl2host

Hi, On February 16, 2022 1:10:35 PM PST, Andrew Dunstan wrote: > >On 2/16/22 16:01, Andres Freund wrote: >> Hi, >> >> On 2022-02-16 15:46:28 -0500, Andrew Dunstan wrote: >>> I suggest that we apply this patch: >> +1 >> >>> and if nothing breaks in a few days I will set about a more thorough >>>

Re: Small TAP tests cleanup for Windows and unused modules

Hi, On February 16, 2022 2:04:01 PM PST, Andrew Dunstan wrote: > >On 2/16/22 16:36, Daniel Gustafsson wrote: >> Seeing msys in TAP tests mentioned in a thread [1] tonight reminded me about >> two related (well, one of them) patches I had sitting around, so rather than >> forgetting again here ar

Re: libpq async duplicate error results

I wrote: >>> An idea that I don't have time to pursue right now is to track >>> how much of conn->errorMessage has been read out by PQgetResult, >>> and only report newly-added text in later PQgetResult calls of >>> a series, while PQerrorMessage would continue to report the >>> whole thing. Buffe

Re: pgsql: Add TAP test to automate the equivalent of check_guc

On Wed, Feb 16, 2022 at 01:38:51PM +0100, Christoph Berg wrote: > The build works with the "Add TAP test to automate the equivalent of > check_guc, take two" commit. Thanks! Thanks for double-checking, Christoph! > (Tests are still failing for > https://www.postgresql.org/message-id/YgjwrkEvNEqoz

Re: pgsql: Add TAP test to automate the equivalent of check_guc

On Wed, Feb 16, 2022 at 7:24 PM Michael Paquier wrote: > On Wed, Feb 16, 2022 at 01:38:51PM +0100, Christoph Berg wrote: > > The build works with the "Add TAP test to automate the equivalent of > > check_guc, take two" commit. Thanks! > > Thanks for double-checking, Christoph! > > > (Tests are sti

Re: pgsql: Add TAP test to automate the equivalent of check_guc

On Wed, Feb 16, 2022 at 07:39:26PM -0500, Robert Haas wrote: > Sorry, I saw that and then forgot about it ... but isn't it 3 days, > not 4 weeks? In any case, I'm happy to have you take care of it, but I > can also look at it tomorrow if you prefer. Ugh. I looked at the top of the thread and saw

Re: O(n) tasks cause lengthy startups and checkpoints

Here is another rebased patch set. -- Nathan Bossart Amazon Web Services: https://aws.amazon.com >From c11a6893d2d509df1389a1c03081b6cc563d5683 Mon Sep 17 00:00:00 2001 From: Nathan Bossart Date: Wed, 5 Jan 2022 19:24:22 + Subject: [PATCH v5 1/8] Introduce custodian. The custodian process i

Re: Postgres restart in the middle of exclusive backup and the presence of backup_label file

Here is a rebased patch. -- Nathan Bossart Amazon Web Services: https://aws.amazon.com >From 8fc744a0b22a1fff9f3470bfdc0e08d9dd5da5be Mon Sep 17 00:00:00 2001 From: Nathan Bossart Date: Wed, 1 Dec 2021 23:50:49 + Subject: [PATCH v2 1/1] remove exclusive backup mode --- doc/src/sgml/backup.

Re: libpq async duplicate error results

Hi, On 2022-02-16 18:51:37 -0500, Tom Lane wrote: > This seems workable, and you'll notice it fixes the duplicated text > in the test case Andres was worried about. Cool. I find it mildly scary that we didn't have any other tests verifying the libpq side of connection termination. Seems like we

Re: Nonrandom scanned_pages distorts pg_class.reltuples set by VACUUM

On Sun, Feb 13, 2022 at 1:43 PM Peter Geoghegan wrote: > This fixes the observed problem directly. It also makes the code > robust against other similar problems that might arise in the future. > The risk that comes from trusting that scanned_pages is a truly random > sample (given these condition

Re: Race conditions in 019_replslot_limit.pl

Andres Freund writes: > I think the test is telling us that something may be broken. We shouldn't > silence that without at least some understanding what it is. I looked at the recent failure on komodoensis [1], and I think what is happening is just that the walsender for the basebackup run (laun

Re: libpq async duplicate error results

Andres Freund writes: > On 2022-02-16 18:51:37 -0500, Tom Lane wrote: >> +/* Also, do nothing if the argument is OOM_result */ >> +if (res == unconstify(PGresult *, &OOM_result)) >> +return; > Wouldn't it make more sense to make res const, rather than unconstifying > &OOM_resu

Re: Small TAP tests cleanup for Windows and unused modules

On Wed, Feb 16, 2022 at 05:36:14PM -0500, Andrew Dunstan wrote: > More specifically, all the tests in question are now passing on jacana > and fairywren, and their $Config{osname} is NOT 'msys' (it's 'MSWin32'). Indeed. 0001 is incorrect. > So we should simply remove any line that ends "if $Conf

Re: refactoring basebackup.c

Thanks for the comments Robert. I have addressed your comments in the attached patch v13-0002-ZSTD-add-server-side-compression-support.patch. Rest of the patches are similar to v12, but just bumped the version number. > It will be good if we can also fix > CreateWalTarMethod to support LZ4 and ZST

  1   2   >