Re: [PATCH] Disable bgworkers during servers start in pg_upgrade

Michael Paquier a écrit : @@ -5862,6 +5862,9 @@ do_start_bgworker(RegisteredBgWorker *rw) static bool bgworker_should_start_now(BgWorkerStartTime start_time) { + if (IsBinaryUpgrade) + return false; + Using -c max_worker_processes=0 would just have the same effect, no?

Re: Async-unsafe functions in signal handlers

As far as I understand, the main problem with backtrace_symbols() is the internal malloc() call. Backend can lock forever if malloc() was interrupted by a signal and then was evaluated again in a signal handler. At the moment Greenplum uses "addr2line -s -e» (on Linux) and "atos -o" (on macOS)

Re: [PATCH] Disable bgworkers during servers start in pg_upgrade

On Thu, Aug 26, 2021 at 3:15 PM Denis Laxalde wrote: > > Michael Paquier a écrit : > >> @@ -5862,6 +5862,9 @@ do_start_bgworker(RegisteredBgWorker *rw) > >> static bool > >> bgworker_should_start_now(BgWorkerStartTime start_time) > >> { > >> +if (IsBinaryUpgrade) > >> +return

cannot access to postgres-git via ssh

Hello. I'm facing a difficulty on cloning a repository via ssh. I understand that git repository can be accessed via http, git and ssh protocol, and ssh access uses the ssh public key registered in community account profile. I registered one in ecdsa-sha2-nistp256 that I believe the server accept

Re: [bug] Logical Decoding of relation rewrite with toast does not reset toast_hash

On Wed, Aug 25, 2021 at 11:26 AM Drouvot, Bertrand wrote: > > I just saw that the patch has been committed. > > Thanks for your help and time on this. > > I'll mark the corresponding commitfest entry as "Committed". > Thanks for your work on this. I have also marked it closed in PostgreSQL_14_Ope

Re: Separate out FileSet from SharedFileSet (was Re: pgsql: pgstat: Bring up pgstat in BaseInit() to fix uninitialized use o)

On Thu, Aug 26, 2021 at 11:47 AM Dilip Kumar wrote: > > On Wed, Aug 25, 2021 at 5:49 PM Amit Kapila wrote: >> >> On Tue, Aug 24, 2021 at 3:55 PM Dilip Kumar wrote: >> > >> > On Tue, Aug 24, 2021 at 12:26 PM Amit Kapila >> > wrote: >> > >> >> The first patch looks good to me. I have made minor

list of acknowledgments for PG14

Attached is the plain-text list of acknowledgments for the PG14 release notes, current through today. Please check for problems such as wrong sorting, duplicate names in different variants, or names in the wrong order etc. (Note that the current standard is given name followed by surname, i

Re: list of acknowledgments for PG14

> On 26 Aug 2021, at 10:41, Peter Eisentraut > wrote: > Attached is the plain-text list of acknowledgments for the PG14 release > notes, current through today. Please check for problems such as wrong > sorting, duplicate names in different variants, or names in the wrong order > etc. (Note

Re: prevent immature WAL streaming

At Thu, 26 Aug 2021 03:24:48 +, "Bossart, Nathan" wrote in > On 8/25/21, 5:40 PM, "Kyotaro Horiguchi" wrote: > > At Wed, 25 Aug 2021 18:18:59 +, "Bossart, Nathan" > > wrote in > >> Let's say we have the following situation (F = flush, E = earliest > >> registered boundary, and L = lat

Re: list of acknowledgments for PG14

On Thu, Aug 26, 2021 at 5:41 PM Peter Eisentraut wrote: > Attached is the plain-text list of acknowledgments for the PG14 release > notes, current through today. Please check for problems such as wrong > sorting, duplicate names in different variants, or names in the wrong > order etc. (Note tha

Trap errors from streaming child in pg_basebackup to exit early

When using pg_basebackup with WAL streaming (-X stream), we have observed on a number of times in production that the streaming child exited prematurely (to no fault of the code it seems, most likely due to network middleboxes), which cause the backup to fail but only after it has run to completion

Re: cannot access to postgres-git via ssh

On Thu, Aug 26, 2021 at 9:34 AM Kyotaro Horiguchi wrote: > > Hello. > > I'm facing a difficulty on cloning a repository via ssh. > > I understand that git repository can be accessed via http, git and ssh > protocol, and ssh access uses the ssh public key registered in > community account profile.

Re: row filtering for logical replication

On Wed, Aug 25, 2021 at 10:22 AM Euler Taveira wrote: > > > [By the way, it took some time to extract what you changed. Since we're > trading > patches, I personally appreciate if you can send a patch on the top of the > current one. I have some changes too and it is time consuming incorpora

Error code for checksum failure in origin.c

Hi. In the code in src/backend/replication/logical/origin.c, the error code "ERRCODE_CONFIGURATION_LIMIT_EXCEEDED" is given when a checksum check results in an error, but "ERRCODE_ DATA_CORRUPTED" seems to be more appropriate. diff --git a/src/backend/replication/logical/orig

verify_heapam for sequences?

Is there a reason why contrib/amcheck/verify_heapam.c does not want to run on sequences? If I take out the checks, it appears to work. Is this an oversight? Or if there is a reason, maybe it could be stated in a comment, at least.

Re: Error code for checksum failure in origin.c

On Thu, Aug 26, 2021 at 3:18 PM Kasahara Tatsuhito wrote: > > Hi. > > In the code in src/backend/replication/logical/origin.c, > the error code "ERRCODE_CONFIGURATION_LIMIT_EXCEEDED" is given > when a checksum check results in an error, > but "ERRCODE_ DATA_CORRUPTED" seems to be more appropriate.

Re: row filtering for logical replication

On Thu, Aug 26, 2021 at 3:00 PM Amit Kapila wrote: > > On Thu, Aug 26, 2021 at 9:51 AM Peter Smith wrote: > > > > On Thu, Aug 26, 2021 at 1:20 PM Amit Kapila wrote: > > > > > > On Thu, Aug 26, 2021 at 7:37 AM Peter Smith wrote: > > > > > > > > On Wed, Aug 25, 2021 at 3:28 PM Amit Kapila > > >

Re: Error code for checksum failure in origin.c

> On 26 Aug 2021, at 12:03, Amit Kapila wrote: > > On Thu, Aug 26, 2021 at 3:18 PM Kasahara Tatsuhito > wrote: >> >> Hi. >> >> In the code in src/backend/replication/logical/origin.c, >> the error code "ERRCODE_CONFIGURATION_LIMIT_EXCEEDED" is given >> when a checksum check results in an error

Re: Failure of subscription tests with topminnow

On Thu, Aug 26, 2021 at 2:45 PM Masahiko Sawada wrote: > I think that it’s possible that the orders of the process writing > disconnections logs and setting 0 to walsender's pid are mismatched. > We set 0 to walsender's pid in WalSndKill() that is called during > on_shmem_exit callback. Once we s

Re: Skipping logical replication transactions on subscriber side

On Thu, Aug 26, 2021 at 3:09 PM Amit Kapila wrote: > > On Thu, Aug 26, 2021 at 9:50 AM Masahiko Sawada wrote: > > > > On Thu, Aug 26, 2021 at 12:51 PM Amit Kapila > > wrote: > > > > Yeah, I agree that it's a handy way to detect missing a switch case > > but I think that we don't necessarily nee

Re: row filtering for logical replication

On Thu, Aug 26, 2021 at 3:41 PM Peter Smith wrote: > > On Thu, Aug 26, 2021 at 3:00 PM Amit Kapila wrote: > > > > On Thu, Aug 26, 2021 at 9:51 AM Peter Smith wrote: > > > > > > On Thu, Aug 26, 2021 at 1:20 PM Amit Kapila > > > wrote: > > > > > > > > On Thu, Aug 26, 2021 at 7:37 AM Peter Smith

Re: Minimal logical decoding on standbys

I noticed the tests added in this patch set are very slow. Here are some of the timings: ... [13:26:59] t/018_wal_optimize.pl ok13976 ms [13:27:13] t/019_replslot_limit.pl .. ok10976 ms [13:27:24] t/020_archive_status.pl .. ok 6190 ms [13:27:

Re: list of acknowledgments for PG14

On 26.08.21 10:48, Daniel Gustafsson wrote: On 26 Aug 2021, at 10:41, Peter Eisentraut wrote: Attached is the plain-text list of acknowledgments for the PG14 release notes, current through today. Please check for problems such as wrong sorting, duplicate names in different variants, or na

Re: Skipping logical replication transactions on subscriber side

On Thu, Aug 26, 2021 at 4:42 PM Masahiko Sawada wrote: > > On Thu, Aug 26, 2021 at 3:09 PM Amit Kapila wrote: > > 1. > > + if (errarg->rel) > > + appendStringInfo(&buf, _(" for replication target relation \"%s.%s\""), > > + errarg->rel->remoterel.nspname, > > + errarg->rel->remoterel.relname); >

Re: pg_receivewal starting position

Le jeudi 29 juillet 2021, 11:09:40 CEST Ronan Dunklau a écrit : > Patch 0001 adds the new READ_REPLICATION_SLOT command. > It returns for a given slot the type, restart_lsn, flush_lsn, > restart_lsn_timeline and flush_lsn_timeline. > The timelines are determined by reading the current timeline hist

Re: Skipping logical replication transactions on subscriber side

On Thu, Aug 26, 2021 at 9:11 PM Amit Kapila wrote: > > On Thu, Aug 26, 2021 at 4:42 PM Masahiko Sawada wrote: > > > > On Thu, Aug 26, 2021 at 3:09 PM Amit Kapila wrote: > > > 1. > > > + if (errarg->rel) > > > + appendStringInfo(&buf, _(" for replication target relation \"%s.%s\""), > > > + errar

AIX: Symbols are missing in libpq.a

Hi, While porting postgresql-odbc v13 to AIX, we have found that (at least) 2 symbols are missing in libpq.a provided by the port of PostgreSQL v13.1 to AIX 7.1 by the BullFreeware project : pg_char_to_encoding pg_encoding_to_char Looking at details, it appears that these symbols are present i

Re: [PATCH] Disable bgworkers during servers start in pg_upgrade

On Thu, Aug 26, 2021 at 03:24:33PM +0800, Julien Rouhaud wrote: > On Thu, Aug 26, 2021 at 3:15 PM Denis Laxalde > wrote: > > > > Michael Paquier a écrit : > > >> @@ -5862,6 +5862,9 @@ do_start_bgworker(RegisteredBgWorker *rw) > > >> static bool > > >> bgworker_should_start_now(BgWorkerStartTi

Re: [PATCH] Disable bgworkers during servers start in pg_upgrade

> On 26 Aug 2021, at 15:09, Bruce Momjian wrote: > On Thu, Aug 26, 2021 at 03:24:33PM +0800, Julien Rouhaud wrote: >> .. I still think that >> changing bgworker_should_start_now() is a better option. > > I am not sure. We have a lot of pg_upgrade code that turns off things > like autovacuum and

Re: [PATCH] Disable bgworkers during servers start in pg_upgrade

On Thu, Aug 26, 2021 at 03:38:23PM +0200, Daniel Gustafsson wrote: > > On 26 Aug 2021, at 15:09, Bruce Momjian wrote: > > On Thu, Aug 26, 2021 at 03:24:33PM +0800, Julien Rouhaud wrote: > > >> .. I still think that > >> changing bgworker_should_start_now() is a better option. > > > > I am not su

Re: [PATCH] Disable bgworkers during servers start in pg_upgrade

Le jeu. 26 août 2021 à 21:38, Daniel Gustafsson a écrit : > > On 26 Aug 2021, at 15:09, Bruce Momjian wrote: > > > Basically, pg_upgrade has avoided any backend changes that could be > > controlled by GUCs and I am not sure we want to start adding such > > changes for just this. > > In principle

Re: [PATCH] Disable bgworkers during servers start in pg_upgrade

> On 26 Aug 2021, at 15:43, Julien Rouhaud wrote: > > Le jeu. 26 août 2021 à 21:38, Daniel Gustafsson > a écrit : > > On 26 Aug 2021, at 15:09, Bruce Momjian > > wrote: > > > Basically, pg_upgrade has avoided any backend changes that could be >

Re: [PATCH] Disable bgworkers during servers start in pg_upgrade

Bruce Momjian a écrit : On Thu, Aug 26, 2021 at 03:38:23PM +0200, Daniel Gustafsson wrote: On 26 Aug 2021, at 15:09, Bruce Momjian wrote: On Thu, Aug 26, 2021 at 03:24:33PM +0800, Julien Rouhaud wrote: .. I still think that changing bgworker_should_start_now() is a better option. I am not sur

Re: Update of partition key on foreign server

2 авг. 2021 г., в 15:29, Илья Гладышев написал(а): Hi,I am currently looking into a partition constraint violation that occurs on update of a partition key on a foreign server. To reproduce it you can run:On server 1 using port 5432:

Re: Identify missing publications from publisher while create/alter subscription.

On Thu, Jul 15, 2021 at 5:57 PM vignesh C wrote: > > On Tue, Jul 6, 2021 at 8:09 PM vignesh C wrote: > > > > On Wed, Jun 30, 2021 at 8:23 PM vignesh C wrote: > > > > > > On Sun, Jun 6, 2021 at 11:55 AM vignesh C wrote: > > > > > > > > On Fri, May 7, 2021 at 6:44 PM vignesh C wrote: > > > > > >

Re: [PATCH] Disable bgworkers during servers start in pg_upgrade

On Thu, Aug 26, 2021 at 03:59:49PM +0200, Daniel Gustafsson wrote: > > On 26 Aug 2021, at 15:43, Julien Rouhaud wrote: > > > > Le jeu. 26 août 2021 à 21:38, Daniel Gustafsson > > a écrit : > > > On 26 Aug 2021, at 15:09, Bruce Momjian > > > wrote

Re: prevent immature WAL streaming

So I'm again distracted by something else, so here's what will have to pass for v3 for the time being. -- Álvaro Herrera 39°49'30"S 73°17'W — https://www.EnterpriseDB.com/ diff --git a/src/backend/access/transam/xlog.c b/src/backend/access/transam/xlog.c index 24165ab03e..43495b8260 1

Re: Printing backtrace of postgres processes

On Wed, Jul 21, 2021 at 10:56 PM vignesh C wrote: > > On Wed, Jul 21, 2021 at 3:52 PM Bharath Rupireddy > wrote: > > > > On Tue, Jul 13, 2021 at 9:03 PM vignesh C wrote: > > > > > > On Wed, May 12, 2021 at 2:27 AM Robert Haas wrote: > > > > > > > > Maybe we should have a role that is specifica

Re: preserving db/ts/relfilenode OIDs across pg_upgrade (was Re: storing an explicit nonce)

On Tue, Aug 17, 2021 at 2:50 PM Robert Haas wrote: > > Less sure that this is a good idea, though. In particular, I do not > > think that you can make it work in the face of > > alter database template1 rename to oops; > > create database template1; > > That is a really good point

Re: badly calculated width of emoji in psql

I wrote: > On Tue, Aug 24, 2021 at 1:50 PM Jacob Champion wrote: > It seems the logical thing to do is revert my 0001 and 0002 and go back to something much closer to Jacob's patch, plus a big comment explaining that the order in which the searches happen matters. I pushed Jacob's patch with the

Re: preserving db/ts/relfilenode OIDs across pg_upgrade (was Re: storing an explicit nonce)

On Thu, Aug 26, 2021 at 11:00:47AM -0400, Robert Haas wrote: > Anyone see a flaw in that analysis? I am still waiting to hear the purpose of this preservation. As long as you don't apply the patch, I guess I will just stop asking. -- Bruce Momjian https://momjian.us EDB

Re: badly calculated width of emoji in psql

On Wed, 2021-08-25 at 16:15 -0400, John Naylor wrote: > On Tue, Aug 24, 2021 at 1:50 PM Jacob Champion wrote: > > > > Does there need to be any sanity check for overlapping ranges between > > the combining and fullwidth sets? The Unicode data on a dev's machine > > would have to be broken somehow

Re: Logical replication - schema change not invalidating the relation cache

On Fri, Jul 16, 2021 at 10:51 PM vignesh C wrote: > > On Sat, Jul 3, 2021 at 11:23 AM Dilip Kumar wrote: > > > > On Fri, Jul 2, 2021 at 12:03 PM Dilip Kumar wrote: > > > > > > Yeah, this looks like a bug. I will look at the patch. > > > > > > > While looking into this, I think the main cause of

Re: preserving db/ts/relfilenode OIDs across pg_upgrade (was Re: storing an explicit nonce)

On Thu, Aug 26, 2021 at 11:24 AM Bruce Momjian wrote: > On Thu, Aug 26, 2021 at 11:00:47AM -0400, Robert Haas wrote: > > Anyone see a flaw in that analysis? > > I am still waiting to hear the purpose of this preservation. As long as > you don't apply the patch, I guess I will just stop asking. Y

Re: speed up verifying UTF-8

I wrote: > Naively, the shift-based DFA requires 64-bit integers to encode the transitions, but I recently came across an idea from Dougall Johnson of using the Z3 SMT solver to pack the transitions into 32-bit integers [1]. That halves the size of the transition table for free. I adapted that eff

Re: preserving db/ts/relfilenode OIDs across pg_upgrade (was Re: storing an explicit nonce)

Greetings, * Bruce Momjian (br...@momjian.us) wrote: > On Thu, Aug 26, 2021 at 11:00:47AM -0400, Robert Haas wrote: > > Anyone see a flaw in that analysis? > > I am still waiting to hear the purpose of this preservation. As long as > you don't apply the patch, I guess I will just stop asking. I

Re: preserving db/ts/relfilenode OIDs across pg_upgrade (was Re: storing an explicit nonce)

Greetings, * Robert Haas (robertmh...@gmail.com) wrote: > On Tue, Aug 17, 2021 at 2:50 PM Robert Haas wrote: > > > Less sure that this is a good idea, though. In particular, I do not > > > think that you can make it work in the face of > > > alter database template1 rename to oops; > > >

Re: preserving db/ts/relfilenode OIDs across pg_upgrade (was Re: storing an explicit nonce)

On Thu, Aug 26, 2021 at 11:35:01AM -0400, Robert Haas wrote: > On Thu, Aug 26, 2021 at 11:24 AM Bruce Momjian wrote: > > On Thu, Aug 26, 2021 at 11:00:47AM -0400, Robert Haas wrote: > > > Anyone see a flaw in that analysis? > > > > I am still waiting to hear the purpose of this preservation. As l

Re: badly calculated width of emoji in psql

čt 26. 8. 2021 v 17:25 odesílatel Jacob Champion napsal: > On Wed, 2021-08-25 at 16:15 -0400, John Naylor wrote: > > On Tue, Aug 24, 2021 at 1:50 PM Jacob Champion > wrote: > > > > > > Does there need to be any sanity check for overlapping ranges between > > > the combining and fullwidth sets? T

Re: preserving db/ts/relfilenode OIDs across pg_upgrade (was Re: storing an explicit nonce)

On Thu, Aug 26, 2021 at 11:36:51AM -0400, Stephen Frost wrote: > Greetings, > > * Bruce Momjian (br...@momjian.us) wrote: > > On Thu, Aug 26, 2021 at 11:00:47AM -0400, Robert Haas wrote: > > > Anyone see a flaw in that analysis? > > > > I am still waiting to hear the purpose of this preservation.

Re: preserving db/ts/relfilenode OIDs across pg_upgrade (was Re: storing an explicit nonce)

On Thu, Aug 26, 2021 at 11:39 AM Stephen Frost wrote: > This looks like a pretty good analysis to me. As it relates to the > question about allowing users to specify an OID, I'd be inclined to > allow it but only for OIDs >64k. We've certainly reserved things in the > past and I don't see any is

Re: speed up verifying UTF-8

>Attached is v23 incorporating the 32-bit transition table, with the necessary comment adjustments 32bit table is nice. Would you please replace https://github.com/BobSteagall/utf_utils/blob/master/src/utf_utils.cpp URL with https://github.com/BobSteagall/utf_utils/blob/6b7a465265de2f5fa6133d653

Re: [PoC] Federated Authn/z with OAUTHBEARER

On Wed, 2021-08-25 at 15:25 -0700, Zhihong Yu wrote: > > Hi, > For v2-0001-common-jsonapi-support-FRONTEND-clients.patch : > > + /* Clean up. */ > + termJsonLexContext(&lex); > > At the end of termJsonLexContext(), empty is copied to lex. For stack > based JsonLexContext, the copy seems unn

Re: [PoC] Federated Authn/z with OAUTHBEARER

On Thu, Aug 26, 2021 at 9:13 AM Jacob Champion wrote: > On Wed, 2021-08-25 at 15:25 -0700, Zhihong Yu wrote: > > > > Hi, > > For v2-0001-common-jsonapi-support-FRONTEND-clients.patch : > > > > + /* Clean up. */ > > + termJsonLexContext(&lex); > > > > At the end of termJsonLexContext(), empty

Re: preserving db/ts/relfilenode OIDs across pg_upgrade (was Re: storing an explicit nonce)

Greetings, * Bruce Momjian (br...@momjian.us) wrote: > On Thu, Aug 26, 2021 at 11:36:51AM -0400, Stephen Frost wrote: > > * Bruce Momjian (br...@momjian.us) wrote: > > > On Thu, Aug 26, 2021 at 11:00:47AM -0400, Robert Haas wrote: > > > > Anyone see a flaw in that analysis? > > > > > > I am still

Re: preserving db/ts/relfilenode OIDs across pg_upgrade (was Re: storing an explicit nonce)

On Thu, Aug 26, 2021 at 11:48 AM Bruce Momjian wrote: > I am find to add it if it is minor, but I want to see the calculus of > its value vs complexity, which I have not seen spelled out. I don't think it's going to be all that complicated, but we're going to have to wait until we have something

Re: preserving db/ts/relfilenode OIDs across pg_upgrade (was Re: storing an explicit nonce)

Greetings, * Robert Haas (robertmh...@gmail.com) wrote: > On Thu, Aug 26, 2021 at 11:39 AM Stephen Frost wrote: > > This looks like a pretty good analysis to me. As it relates to the > > question about allowing users to specify an OID, I'd be inclined to > > allow it but only for OIDs >64k. We'

Re: preserving db/ts/relfilenode OIDs across pg_upgrade (was Re: storing an explicit nonce)

On Thu, Aug 26, 2021 at 12:34:56PM -0400, Stephen Frost wrote: > * Bruce Momjian (br...@momjian.us) wrote: > > On Thu, Aug 26, 2021 at 11:36:51AM -0400, Stephen Frost wrote: > > > * Bruce Momjian (br...@momjian.us) wrote: > > > > On Thu, Aug 26, 2021 at 11:00:47AM -0400, Robert Haas wrote: > > > >

Re: preserving db/ts/relfilenode OIDs across pg_upgrade (was Re: storing an explicit nonce)

On Thu, Aug 26, 2021 at 12:37:19PM -0400, Robert Haas wrote: > On Thu, Aug 26, 2021 at 11:48 AM Bruce Momjian wrote: > > I am find to add it if it is minor, but I want to see the calculus of > > its value vs complexity, which I have not seen spelled out. > > I don't think it's going to be all tha

Re: preserving db/ts/relfilenode OIDs across pg_upgrade (was Re: storing an explicit nonce)

Greetings, * Bruce Momjian (br...@momjian.us) wrote: > On Thu, Aug 26, 2021 at 12:34:56PM -0400, Stephen Frost wrote: > > * Bruce Momjian (br...@momjian.us) wrote: > > > On Thu, Aug 26, 2021 at 11:36:51AM -0400, Stephen Frost wrote: > > > > * Bruce Momjian (br...@momjian.us) wrote: > > > > > On Th

Re: preserving db/ts/relfilenode OIDs across pg_upgrade (was Re: storing an explicit nonce)

On Thu, Aug 26, 2021 at 01:03:54PM -0400, Stephen Frost wrote: > Yes, we're talking about either incremental (or perhaps differential) > backup where only the files which are actually different would be backed > up. Just like with PG, I can't provide any complete guarantees that > we'd be able to

Re: preserving db/ts/relfilenode OIDs across pg_upgrade (was Re: storing an explicit nonce)

On Thu, Aug 26, 2021 at 12:51 PM Bruce Momjian wrote: > I just don't want to add requirements/complexity to pg_upgrade without > clearly stated reasons because future database changes will need to > honor this new preservation behavior. Well, I agree that it's good to have reasons clearly stated

Re: preserving db/ts/relfilenode OIDs across pg_upgrade (was Re: storing an explicit nonce)

Greetings, * Bruce Momjian (br...@momjian.us) wrote: > On Thu, Aug 26, 2021 at 01:03:54PM -0400, Stephen Frost wrote: > > Yes, we're talking about either incremental (or perhaps differential) > > backup where only the files which are actually different would be backed > > up. Just like with PG, I

Re: preserving db/ts/relfilenode OIDs across pg_upgrade (was Re: storing an explicit nonce)

On Thu, Aug 26, 2021 at 01:20:38PM -0400, Robert Haas wrote: > So I think this proposed change is in the safe direction. If > relfilenodes were currently preserved and we wanted to make them not > be preserved, then I think you would be quite right to say "whoa, > whoa, that could be a problem." In

Re: preserving db/ts/relfilenode OIDs across pg_upgrade (was Re: storing an explicit nonce)

On Thu, Aug 26, 2021 at 01:24:46PM -0400, Stephen Frost wrote: > Greetings, > > * Bruce Momjian (br...@momjian.us) wrote: > > On Thu, Aug 26, 2021 at 01:03:54PM -0400, Stephen Frost wrote: > > > Yes, we're talking about either incremental (or perhaps differential) > > > backup where only the files

Re: verify_heapam for sequences?

> On Aug 26, 2021, at 3:03 AM, Peter Eisentraut > wrote: > > > Is there a reason why contrib/amcheck/verify_heapam.c does not want to run on > sequences? If I take out the checks, it appears to work. Is this an > oversight? Or if there is a reason, maybe it could be stated in a comment,

Re: Mark all GUC variable as PGDLLIMPORT

On Thu, Aug 26, 2021 at 3:38 AM Julien Rouhaud wrote: > > On Thu, Aug 26, 2021 at 1:51 AM Alvaro Herrera > wrote: > > > > On 2021-Aug-25, Magnus Hagander wrote: > > > > > The thing we need the PGDLLIMPORT definition for is to *import* them > > > on the other end? > > > > Oh ... so modules that a

Re: Mark all GUC variable as PGDLLIMPORT

On Thu, Aug 26, 2021 at 3:42 PM Magnus Hagander wrote: > Ugly as it is, I wonder if there's a chance we could just process all > the headers at install times and inject the PGDLLIMPORT. We know which > symvols it is on account of what we're getting in the DEF file. > > Not saying that's not a very

Re: Async-unsafe functions in signal handlers

On Wed, Aug 25, 2021 at 10:22 AM Denis Smirnov wrote: > I am going to refactor Greenplum backtraces for error messages and want to > make it more compatible with PostgreSQL code. Backtraces in PostgreSQL were > introduced by 71a8a4f6e36547bb060dbcc961ea9b57420f7190 commit (original > discussion

Re: Async-unsafe functions in signal handlers

Robert Haas writes: > That is a great question. I think bgworker_die() is extremely > dangerous and ought to be removed. I can't see how that can ever be > safe. Agreed, it looks pretty dangerous from here. The equivalent (and far better battle-tested) signal handlers in postgres.c are a lot mor

Re: Mark all GUC variable as PGDLLIMPORT

On 8/26/21 3:57 PM, Robert Haas wrote: > On Thu, Aug 26, 2021 at 3:42 PM Magnus Hagander wrote: >> Ugly as it is, I wonder if there's a chance we could just process all >> the headers at install times and inject the PGDLLIMPORT. We know which >> symvols it is on account of what we're getting in

amcheck/verify_heapam doesn't check for interrupts

I just noticed that the new heapam amcheck verification code can take a very long time to respond to cancellations from pg_amcheck -- I saw that it took over 2 minutes on a large database on my workstation. It looks like we neglect to call CHECK_FOR_INTERRUPTS() anywhere inside verify_heapam.c. Is

Re: row filtering for logical replication

On Thu, Aug 26, 2021 at 9:13 PM Amit Kapila wrote: > > On Thu, Aug 26, 2021 at 3:41 PM Peter Smith wrote: > > > > On Thu, Aug 26, 2021 at 3:00 PM Amit Kapila wrote: > > > > > > On Thu, Aug 26, 2021 at 9:51 AM Peter Smith wrote: > > > > > > > > On Thu, Aug 26, 2021 at 1:20 PM Amit Kapila > > >

CFM for september commitfest

Hi everyone, Do we already have a ${subject}? Otherwise I could offer my self. If anyone agree, this would be my first time as CFM as I would appreciate some help. -- Jaime Casanova Director de Servicios Profesionales SystemGuards - Consultores de PostgreSQL

Re: amcheck/verify_heapam doesn't check for interrupts

> On Aug 26, 2021, at 2:38 PM, Peter Geoghegan wrote: > > It looks like we neglect to call CHECK_FOR_INTERRUPTS() anywhere > inside verify_heapam.c. Is there any reason for this? Not any good one that I can see. > Can't we just > put a CHECK_FOR_INTERRUPTS() at the top of the outermost loop,

Re: [PATCH] Disable bgworkers during servers start in pg_upgrade

On Thu, Aug 26, 2021 at 10:34:48AM -0400, Bruce Momjian wrote: > On Thu, Aug 26, 2021 at 03:59:49PM +0200, Daniel Gustafsson wrote: >> Agreed, in this particular case I think there is merit to the idea of >> enforcing >> it in the backend. > > OK, works for me Indeed, there is some history here

Re: The Free Space Map: Problems and Opportunities

On Wed, Aug 25, 2021 at 10:58 AM Robert Haas wrote: > Makes sense. I'm glad that the big picture stuff makes sense to you. > I think one of the big implementation challenges here is > coping with the scenario where there's not enough shared memory > available ... or else somehow making that impo

Re: amcheck/verify_heapam doesn't check for interrupts

On Thu, Aug 26, 2021 at 4:24 PM Mark Dilger wrote: > > On Aug 26, 2021, at 2:38 PM, Peter Geoghegan wrote: > > It looks like we neglect to call CHECK_FOR_INTERRUPTS() anywhere > > inside verify_heapam.c. Is there any reason for this? > > Not any good one that I can see. Seems that way. Want to p

Re: amcheck/verify_heapam doesn't check for interrupts

> On Aug 26, 2021, at 4:39 PM, Peter Geoghegan wrote: > >> Not any good one that I can see. > > Seems that way. Want to post a patch? Sure. I just posted another unrelated patch for amcheck this morning, so it seems a good day for it :) — Mark Dilger EnterpriseDB: http://www.enterprisedb.

Re: Mark all GUC variable as PGDLLIMPORT

On Thu, Aug 26, 2021 at 05:10:39PM -0400, Andrew Dunstan wrote: > On 8/26/21 3:57 PM, Robert Haas wrote: >> On Thu, Aug 26, 2021 at 3:42 PM Magnus Hagander wrote: >>> Ugly as it is, I wonder if there's a chance we could just process all >>> the headers at install times and inject the PGDLLIMPORT.

Re: amcheck/verify_heapam doesn't check for interrupts

> On Aug 26, 2021, at 4:41 PM, Mark Dilger wrote: > >> Seems that way. Want to post a patch? > > Sure. v1-0001-Add-CHECK_FOR_INTERRUPTS-to-verify_heapam.patch Description: Binary data — Mark Dilger EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company

Re: log_autovacuum in Postgres 14 -- ordering issue

On Wed, Aug 25, 2021 at 08:23:04PM -0400, Alvaro Herrera wrote: > On 2021-Aug-25, Peter Geoghegan wrote: >> This seems like a release housekeeping task to me. I'll come up with >> a patch targeting 14 and master in a few days. > > Agreed, thanks. Sorry for the late reply here. Indeed, I can see

Re: Mark all GUC variable as PGDLLIMPORT

On Fri, Aug 27, 2021 at 3:42 AM Magnus Hagander wrote: > > Yeah, but that does move the problem to the other side doesn't it? So > if you (as a pure test of course) were to remove the variable > completely from the included header and just declare it manually with > PGDLLSPEC in your file, it shou

Re: [PATCH] Disable bgworkers during servers start in pg_upgrade

On Fri, Aug 27, 2021 at 7:31 AM Michael Paquier wrote: > > Indeed, there is some history here with autovacuum. I have not been > careful enough to check that. Still, putting a check on > IsBinaryUpgrade in bgworker_should_start_now() would mean that we > still keep track of the set of bgworkers

Re: amcheck/verify_heapam doesn't check for interrupts

Patch committed. Thanks! -- Peter Geoghegan

Re: [PATCH] Disable bgworkers during servers start in pg_upgrade

On Fri, Aug 27, 2021 at 09:34:24AM +0800, Julien Rouhaud wrote: > That shouldn't lead to any problem right? Well, bgworker_should_start_now() does not exist for that, and RegisterBackgroundWorker() is the one doing the classification job, so it would be more consistent to keep everything under con

Re: cannot access to postgres-git via ssh

At Thu, 26 Aug 2021 16:34:25 +0900 (JST), Kyotaro Horiguchi wrote in > Hello. Hmm. I found w...@postgresql.org more appropriate place to ask this question. Please ignore this. regards. -- Kyotaro Horiguchi NTT Open Source Software Center

Re: [PoC] Federated Authn/z with OAUTHBEARER

On Thu, Aug 26, 2021 at 04:13:08PM +, Jacob Champion wrote: > Do you mean heap-based? i.e. destroyJsonLexContext() does an > unnecessary copy before free? Yeah, in that case it's not super useful, > but I think I'd want some evidence that the performance hit matters > before optimizing it. As

Re: [PATCH] Disable bgworkers during servers start in pg_upgrade

On Fri, Aug 27, 2021 at 10:02 AM Michael Paquier wrote: > > On Fri, Aug 27, 2021 at 09:34:24AM +0800, Julien Rouhaud wrote: > > That shouldn't lead to any problem right? > > Well, bgworker_should_start_now() does not exist for that, and > RegisterBackgroundWorker() is the one doing the classificat

Re: row filtering for logical replication

On Fri, Aug 27, 2021 at 3:31 AM Peter Smith wrote: > > On Thu, Aug 26, 2021 at 9:13 PM Amit Kapila wrote: > > > > On Thu, Aug 26, 2021 at 3:41 PM Peter Smith wrote: > > > > Apart from Truncate, it will also be a waste if any error happens > > before actually evaluating the filter, tomorrow there

Re: pg_receivewal starting position

On Thu, Aug 26, 2021 at 02:14:27PM +0200, Ronan Dunklau wrote: > Following the discussion at [1], I refactored the implementation into > streamutil and added a third patch making use of it in pg_basebackup itself > in > order to fail early if the replication slot doesn't exist, so please find >

Re: [PATCH] Tab completion for ALTER TABLE … ADD …

On Tue, Aug 03, 2021 at 12:48:38PM +0100, Dagfinn Ilmari Mannsåker wrote: > The other day I noticed that there's no tab completion after ALTER TABLE > … ADD, so here's a patch. In addition to COLUMN and all the table > constraint types, it also completes with the list of unique indexes on > the ta

Re: Error code for checksum failure in origin.c

On Thu, Aug 26, 2021 at 4:11 PM Daniel Gustafsson wrote: > > > On 26 Aug 2021, at 12:03, Amit Kapila wrote: > > > > On Thu, Aug 26, 2021 at 3:18 PM Kasahara Tatsuhito > > wrote: > >> > >> Hi. > >> > >> In the code in src/backend/replication/logical/origin.c, > >> the error code "ERRCODE_CONFIGUR

Re: Skipping logical replication transactions on subscriber side

On Thu, Aug 26, 2021 at 6:24 PM Masahiko Sawada wrote: > > On Thu, Aug 26, 2021 at 9:11 PM Amit Kapila wrote: > > > > > > Okay, changed accordingly. Additionally, I have changed the code which > > sets timestamp to (unset) when it is 0 so that it won't display the > > timestamp in that case. I ha

Re: [PATCH] Disable bgworkers during servers start in pg_upgrade

On Fri, Aug 27, 2021 at 11:25:19AM +0800, Julien Rouhaud wrote: > Right now AFAICT there's no official API to check if a call to > RegisterBackgroundWorker() succeeded or not, but an extension could > check by itself using BackgroundWorkerList in bgworker_internals.h, > and error out or something i

Fix erroneous parallel execution when modifying CTE is present in rewritten query

Hi Hackers, There is a known bug in the query rewriter: if a query that has a modifying CTE is re-written, the hasModifyingCTE flag is not getting set in the re-written query. This bug can result in the query being allowed to execute in parallel-mode, which results in an error. For more details f

Re: pgstat_send_connstats() introduces unnecessary timestamp and UDP overhead

On Wed, Aug 25, 2021 at 01:20:03AM -0700, Andres Freund wrote: > On 2021-08-25 12:51:58 +0900, Michael Paquier wrote: > As I said before, this ship has long sailed: > > typedef struct PgStat_MsgTabstat > { > PgStat_MsgHdr m_hdr; > Oid m_databaseid; > int

Re: Error code for checksum failure in origin.c

On Fri, Aug 27, 2021 at 10:02:26AM +0530, Amit Kapila wrote: > I think we need to backpatch this till 9.6 as this is introduced by > commit 5aa2350426. Any objections to that? None. -- Michael signature.asc Description: PGP signature

Re: Separate out FileSet from SharedFileSet (was Re: pgsql: pgstat: Bring up pgstat in BaseInit() to fix uninitialized use o)

On Thu, Aug 26, 2021 at 2:10 PM Amit Kapila wrote: > > Thanks, Sawada-San and Dilip for confirmation. I would like to commit > this and the second patch (the second one still needs some more > testing and review) for PG-15 as there is no bug per-se related to > this work in PG-14 but I see an arg

Re: Error code for checksum failure in origin.c

On Fri, Aug 27, 2021 at 1:32 PM Amit Kapila wrote: > > On Thu, Aug 26, 2021 at 4:11 PM Daniel Gustafsson wrote: > > > > > On 26 Aug 2021, at 12:03, Amit Kapila wrote: > > > > > > On Thu, Aug 26, 2021 at 3:18 PM Kasahara Tatsuhito > > > wrote: > > >> > > >> Hi. > > >> > > >> In the code in src/b

  1   2   >