Re: pg_upgrade and logical replication

On Mon, Sep 25, 2023 at 05:35:18AM +, Hayato Kuroda (Fujitsu) wrote: > Personally, I prefer to change max_logical_replication_workers. Mainly there > are > two reasons: > > 1. Your approach must be back-patched to older versions which support logical >replication feature, but the oldest

Re: Doesn't pgstat_report_wal() handle the argument "force" incorrectly

On 2023-09-25 14:38, Michael Paquier wrote: We would not wait on the lock if force=false, which would do nowait=true. And !force reads the same to me as force=false. Anyway, I am OK to remove this part. That seems to confuse you, so you may not be the only one who would read this comment.

Re: [PoC] pg_upgrade: allow to upgrade publisher node

On Fri, Sep 22, 2023 at 12:11 PM Amit Kapila wrote: > > Yeah, both by tests and manually verifying the WAL records. Basically, > we need to care about records that could be generated by background > processes like checkpointer/bgwriter or can be generated during system > table scans. You may want

Re: Doesn't pgstat_report_wal() handle the argument "force" incorrectly

On Mon, Sep 25, 2023 at 02:16:22PM +0900, Ryoga Yoshida wrote: > On 2023-09-25 12:47, Michael Paquier wrote: > in attached file >> +/* like in pgstat.c, don't wait for lock acquisition when !force */ > > Isn't it the case with force=true and !force that it doesn't wait for the > lock

RE: pg_upgrade and logical replication

Dear Michael, > I'd like to propose a check > for IsBinaryUpgrade into ApplyLauncherRegister() instead as it makes > no real sense to start apply workers in this context. That would be > equivalent to max_logical_replication_workers = 0. Personally, I prefer to change

Re: Row pattern recognition

> On Fri, Sep 22, 2023, 3:13 AM Tatsuo Ishii wrote: > >> > Op 9/22/23 om 07:16 schreef Tatsuo Ishii: >> >>> Attached is the fix against v6 patch. I will include this in upcoming >> >>> v7 patch. >> >> Attached is the v7 patch. It includes the fix mentioned above. Also >> > (Champion's address

Re: Doesn't pgstat_report_wal() handle the argument "force" incorrectly

On 2023-09-25 12:47, Michael Paquier wrote: in attached file + /* like in pgstat.c, don't wait for lock acquisition when !force */ Isn't it the case with force=true and !force that it doesn't wait for the lock acquisition. In fact, force may be false. Ryoga Yoshida

Re: SQL:2011 application time

On Wed, Sep 20, 2023 at 10:50 AM Paul Jungwirth wrote: > > On 9/17/23 20:11, jian he wrote: > > small issues so far I found, v14. > > Thank you again for the review! v15 is attached. > hi. some tiny issues. IN src/backend/utils/adt/ri_triggers.c else { appendStringInfo(, "SELECT 1 FROM %s%s x",

Re: pg_upgrade and logical replication

On Fri, Sep 22, 2023 at 4:36 AM Michael Paquier wrote: > > On Thu, Sep 21, 2023 at 02:35:55PM +0530, Amit Kapila wrote: > > It is because after upgrade of both publisher and subscriber, the > > subscriptions won't work. Both publisher and subscriber should work, > > otherwise, the logical

Re: Postgres picks suboptimal index after building of an extended statistics

On 12/8/2021 06:26, Tomas Vondra wrote: On 8/11/21 2:48 AM, Peter Geoghegan wrote: On Wed, Jun 23, 2021 at 7:19 AM Andrey V. Lepikhov wrote: Ivan Frolkov reported a problem with choosing a non-optimal index during a query optimization. This problem appeared after building of an extended

Re: Synchronizing slots from primary to standby

On Fri, Sep 22, 2023 at 3:48 PM Amit Kapila wrote: > > On Thu, Sep 21, 2023 at 9:16 AM shveta malik wrote: > > > > On Tue, Sep 19, 2023 at 10:29 AM shveta malik > > wrote: > > > > Currently in patch001, synchronize_slot_names is a GUC on both primary > > and physical standby. This GUC tells

Re: Synchronizing slots from primary to standby

On Fri, Sep 22, 2023 at 6:01 PM Drouvot, Bertrand wrote: > > Hi, > > Thanks for all the work that has been done on this feature, and sorry > to have been quiet on it for so long. Thanks for looking into this. > > On 9/18/23 12:22 PM, shveta malik wrote: > > On Wed, Sep 13, 2023 at 4:48 PM

Re: Remove MSVC scripts from the tree

On Fri, Sep 22, 2023 at 08:06:57AM +0200, Peter Eisentraut wrote: > First we need to fix things so that we can build using meson from a > distribution tarball, which is the subject of > . Thanks, missed this one. -- Michael signature.asc Description:

Re: Doesn't pgstat_report_wal() handle the argument "force" incorrectly

On Mon, Sep 25, 2023 at 11:27:27AM +0900, Ryoga Yoshida wrote: > Thank you for the review. Certainly, adding a comments is a good idea. I > added a comment. Hmm. How about the attached version with some tweaks? -- Michael diff --git a/src/backend/utils/activity/pgstat_wal.c

Re: Report planning memory in EXPLAIN ANALYZE

Hi Ashutosh, On Fri, Sep 22, 2023 at 5:56 PM Ashutosh Bapat wrote: > Hi Andy, > Thanks for your feedback. > > On Fri, Sep 22, 2023 at 8:22 AM Andy Fan wrote: > > > > 1). The commit message of patch 1 just says how it does but doesn't > > say why it does. After reading through the discussion, I

Re: Confused about gram.y referencs in Makefile?

On Mon, 25 Sep 2023 at 11:17, Tom Lane wrote: > Japin Li writes: >> I find src/backend/utils/mb/Unicode/Makefile has the following comments: > >>> # Note that while each script call produces two output files, to be >>> # parallel-make safe we need to split this into two rules. (See for >>> #

Re: Confused about gram.y referencs in Makefile?

Japin Li writes: > I find src/backend/utils/mb/Unicode/Makefile has the following comments: >> # Note that while each script call produces two output files, to be >> # parallel-make safe we need to split this into two rules. (See for >> # example gram.y for more explanation.) > I could not

Confused about gram.y referencs in Makefile?

Hi, hackers I find src/backend/utils/mb/Unicode/Makefile has the following comments: > # Note that while each script call produces two output files, to be > # parallel-make safe we need to split this into two rules. (See for > # example gram.y for more explanation.) > # I could not find the

Confused about gram.y referencs in Makefile?

Hi, hackers I find src/backend/utils/mb/Unicode/Makefile has the following comments: > # Note that while each script call produces two output files, to be > # parallel-make safe we need to split this into two rules. (See for > # example gram.y for more explanation.) > # I could not find the

Re: Doesn't pgstat_report_wal() handle the argument "force" incorrectly

On 2023-09-25 09:56, Michael Paquier wrote: It seems to me that you are right here. It would make sense to me to say that force=true is equivalent to nowait=false, as in "I'm OK to wait on the lockas I want to make sure that the stats are flushed at this point". Currently force=true means

Re: Synchronizing slots from primary to standby

FYI -- v19 failed to apply cleanly with the latest HEAD. [postgres@CentOS7-x64 oss_postgres_misc]$ git apply ../patches_misc/v19-0001-Allow-logical-walsenders-to-wait-for-physical-st.patch error: patch failed: src/test/recovery/meson.build:44 error: src/test/recovery/meson.build: patch does not

Re: pg_upgrade and logical replication

On Wed, Sep 20, 2023 at 09:38:56AM +0900, Michael Paquier wrote: > And this code path is used to start postmaster instances for old and > new clusters. So it seems to me that it is incorrect if this is not > conditional based on the cluster version. Avoiding the startup of bgworkers during

Re: Doesn't pgstat_report_wal() handle the argument "force" incorrectly

On Fri, Sep 22, 2023 at 01:58:37PM +0900, Ryoga Yoshida wrote: > pgstat_report_wal() calls pgstat_flush_wal() and pgstat_flush_io(). When > calling them, pgstat_report_wal() specifies its argument "force" as the > argument of them, as follows. But according to the code of > pgstat_flush_wal() and

Re: DROP DATABASE is interruptible

I noticed that this patch set introduced this pg_dump test: On 12.07.23 03:59, Andres Freund wrote: + 'CREATE DATABASE invalid...' => { + create_order => 1, + create_sql => q(CREATE DATABASE invalid; UPDATE pg_database SET datconnlimit = -2 WHERE datname =

Re: Fix bug in VACUUM and ANALYZE docs

On Sun, Sep 24, 2023 at 06:30:32PM -0500, Karl O. Pinc wrote: > I signed up to review, but I think that perhaps commitfest > https://commitfest.postgresql.org/45/4574/ > needs marking as applied and done? Indeed. I did not notice that there was a CF entry for this one. Closed it now. -- Michael

Re: GUC for temporarily disabling event triggers

On Fri, Sep 22, 2023 at 05:29:01PM +0200, Daniel Gustafsson wrote: > Since the main driver for this is to reduce the usage/need for single-user > mode > I also reworded the patch slightly. Instead of phrasing this as an > alternative > to single-user mode, I reversed it such that single-user

Re: Fix bug in VACUUM and ANALYZE docs

On Wed, 20 Sep 2023 13:39:02 +0900 Michael Paquier wrote: > On Wed, Sep 20, 2023 at 09:43:15AM +0900, Shinya Kato wrote: > > You're right. It looks good to me. > > Right, it feels like there has been a lot of copy-paste in this area > of the docs. Applied down to 16. I signed up to review,

Various small doc improvements; plpgsql, schemas, permissions, oidvector

Hi, I have made various, mostly unrelated to each other, small improvements to the documentation. These are usually in the areas of plpgsql, schemas, and permissions. Most change 1 lines, but some supply short overviews. "Short" is subjective, so if these need to be broken into different

Re: Invalidate the subscription worker in cases where a user loses their superuser status

On Sat, 23 Sept 2023 at 11:28, Amit Kapila wrote: > > On Sat, Sep 23, 2023 at 1:27 AM vignesh C wrote: > > > > > > Fixed this issue by checking if the subscription owner has changed > > from superuser to non-superuser in case the pg_authid rows changes. > > The attached patch has the changes for

Re: Eager page freeze criteria clarification

On Sat, Sep 23, 2023 at 3:53 PM Melanie Plageman wrote: > > Workload F: > > +--++-++--+ > | algo | WAL GB | cptr bgwriter writes| other reads/writes | IO time AV > worker| >

Re: How to Know the number of attrs?

On 2023-09-24 20:56 +0800, jacktby jacktby wrote: > typedef struct TupleDescData > { > int natts; /* number of attributes > in the tuple */ > Oid tdtypeid; /* composite type ID > for tuple type */ > int32

How to Know the number of attrs?

typedef struct TupleDescData { int natts; /* number of attributes in the tuple */ Oid tdtypeid; /* composite type ID for tuple type */ int32 tdtypmod; /* typmod for tuple type

How to Know the number of attrs?

typedef struct TupleDescData { int natts; /* number of attributes in the tuple */ Oid tdtypeid; /* composite type ID for tuple type */ int32 tdtypmod; /* typmod for tuple type

Re: bug fix and documentation improvement about vacuumdb

LGTM too! >> a bit to make the diff smaller, I couldn't think from that perspective. Thanks for your update, Daniel-san. Masaki Kuwamura