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

On Fri, Aug 27, 2021 at 12:41 PM Michael Paquier wrote: > > Perhaps. That feels like a topic different than what's discussed > here, though, because we don't really need to check if a bgworker has > been launched or not. We just need to make sure that it never runs in > the context of a binary

Re: create table like: ACCESS METHOD

On Tue, Jun 01, 2021 at 02:10:45PM -0500, Justin Pryzby wrote: > rebased and alphabetized + /* ACCESS METHOD doesn't apply and isn't copied for partitioned tables */ + if ((table_like_clause->options & CREATE_TABLE_LIKE_ACCESS_METHOD) != 0 && + !cxt->ispartitioned) +

Re: Failure of subscription tests with topminnow

On Thu, Aug 26, 2021 at 4:28 PM Ajin Cherian wrote: > > On Thu, Aug 26, 2021 at 2:45 PM Masahiko Sawada wrote: > > Attaching a patch on head that modifies this particular script to also > consider the state of the walsender. > I think the fix is correct but similar changes are required in

Re: log_autovacuum in Postgres 14 -- ordering issue

On Wed, Aug 25, 2021 at 5:02 PM Peter Geoghegan wrote: > > I like it better than the current layout, so +1. > > This seems like a release housekeeping task to me. I'll come up with > a patch targeting 14 and master in a few days. Here is a patch that outputs log_autovacuum's lines in this

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

On Fri, Aug 27, 2021 1:25 PM Dilip Kumar wrote: > 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

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 2:18 PM Dilip Kumar wrote: > The patch looks good to me, I have rebased 0002 atop > this patch and also done some cosmetic fixes in 0002.  Here are some comments for the 0002 patch. 1) - * toplevel transaction. Each subscription has a separate set of files. + * toplevel

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

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

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: 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

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

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

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

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

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

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: 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

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

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: 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: [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

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 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: 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

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

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: 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: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:

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

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

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: 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

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: 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 > >

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.

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

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

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 >

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

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

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: 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

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."

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,

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)

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)

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

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

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)

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.

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, * 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

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(); > > > > At the end of termJsonLexContext(), empty is

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(); > > At the end of termJsonLexContext(), empty is copied to lex. For stack > based JsonLexContext, the copy seems

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

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

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

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?

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

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)

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.

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

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.

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

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: 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

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

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

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

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

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 > > >

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: 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: [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

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

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

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

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

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 > > >>

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

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(, _(" for replication target relation \"%s.%s\""), > > > +

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

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(, _(" for replication target relation \"%s.%s\""), > > + errarg->rel->remoterel.nspname, > > + errarg->rel->remoterel.relname); > > +

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

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

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: 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

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

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

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 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

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.

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

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

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.

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

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

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 =

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

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,

  1   2   >