Re: Estimating HugePages Requirements?

On Wed, Aug 11, 2021 at 11:23:52PM +, Bossart, Nathan wrote: > I think BootstrapModeMain() makes the most sense. It fits in nicely > with the --check logic that's already there. With v3, the following > command can be used to retrieve the amount of shared memory required. > > postgre

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 at 10:56 AM houzj.f...@fujitsu.com wrote: > > 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) > > - * top

Re: Added schema level support for publication.

On Thu, Aug 26, 2021 at 7:52 AM tanghy.f...@fujitsu.com wrote: > > On Wednesday, August 25, 2021 5:37 PM vignesh C wrote: > > > > Attached v21 patch has the changes based on the new syntax and fixes > > few of the other review comments provided by reviewers. > > > > Thanks for your new patch. I s

Re: [PATCH] pgbench: add multiconnect option

On Thu, Jul 01, 2021 at 12:22:45PM +0200, Fabien COELHO wrote: > Good. I was thinking of adding such capability, possibly for handling > connection errors and reconnecting… round-robin and random make sense. I am wondering how round-robin would work with -C, though? Would you just reuse the same

Re: [PATCH] Proof of concept for GUC improvements

On Thu, Aug 19, 2021 at 03:58:57PM -0700, David G. Johnston wrote: > I'm at -0.5 as to whether such a patch would actually be an improvement or > whether the added possibilities would just be confusing and, because it is > all optional, indefinitely so. FWIW, I find this proposition of introducing

Re: perlcritic: prohibit map and grep in void conext

On Wed, Jul 28, 2021 at 01:26:23PM +0200, Daniel Gustafsson wrote: > I'm fine with increasing this policy, but I don't have strong feelings. If we > feel the perlcritic policy change is too much, I would still prefer to go > ahead > with the map rewrite part of the patch though. I have no issue

Re: [PATCH] test/ssl: rework the sslfiles Makefile target

On Fri, Aug 13, 2021 at 12:08:16AM +, Jacob Champion wrote: > (Things would get hairier if someone included the SSL Makefile > somewhere else, but I don't see anyone doing that now and I don't know > why someone would.) That would not happen. Hopefully. > But -- if I do spend the time to ans

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 u

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) + cxt->accessMet

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

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

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

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 tr

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

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

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

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

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

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 shou

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: 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: http://www.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 p

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

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

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 mor

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

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)

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

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)

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. We'

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 still

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

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)

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

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

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 principle

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

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

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

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

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

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 a/src/backend/replication/logical/orig

  1   2   >