RE: Slow catchup of 2PC (twophase) transactions on replica in LR

2024-05-15 Thread Hayato Kuroda (Fujitsu)
l.org/message-id/OSBPR01MB25522052F9F3E3AAD3BA2A8CF5ED2%40OSBPR01MB2552.jpnprd01.prod.outlook.com Best Regards, Hayato Kuroda FUJITSU LIMITED https://www.fujitsu.com/

RE: Fix src/test/subscription/t/029_on_error.pl test when wal_debug is enabled

2024-05-15 Thread Hayato Kuroda (Fujitsu)
r confirmation purpose. This worked well on my environment. Ian, how about you? Best Regards, Hayato Kuroda FUJITSU LIMITED https://www.fujitsu.com/ fix_029.diff Description: fix_029.diff

RE: Slow catchup of 2PC (twophase) transactions on replica in LR

2024-05-14 Thread Hayato Kuroda (Fujitsu)
where for these boolean parameters, instead of sometimes using > different values like on|off. > > What do you think? It's OK for me to make message/code comments consistent. Not sure the documentation, but followed only my part. [1]: https://www.postgresql.org/message-id/OSBPR01

RE: Slow catchup of 2PC (twophase) transactions on replica in LR

2024-05-13 Thread Hayato Kuroda (Fujitsu)
sql('postgres', "ALTER SUBSCRIPTION > regress_sub ENABLE;"); > + > > What does "Apart from the above" mean? Be more explicit. Clarified like "Apart from the last ALTER SUBSCRIPTION command...". > 9. > +# Verify the prepared transaction are aborted > $result = $node_subscriber->safe_psql('postgres', > "SELECT count(*) FROM pg_prepared_xacts;"); > is($result, q(0), "prepared transaction done by worker is aborted"); > > /transaction are aborted/transaction was aborted/ Fixed. [1]: https://www.postgresql.org/message-id/OSBPR01MB2552FEA48D265EA278AA9F7AF5E22%40OSBPR01MB2552.jpnprd01.prod.outlook.com Best Regards, Hayato Kuroda FUJITSU LIMITED https://www.fujitsu.com/

RE: Slow catchup of 2PC (twophase) transactions on replica in LR

2024-05-13 Thread Hayato Kuroda (Fujitsu)
. > +$result = $node_subscriber->safe_psql('postgres', > +"SELECT count(*) FROM pg_prepared_xacts;"); > +is($result, q(0), "prepared transaction done by worker is aborted"); > + > > /the prepared transaction are aborted/any prepared transactions are aborted/ Fixed. [1]: https://www.postgresql.org/message-id/OSBPR01MB2552FEA48D265EA278AA9F7AF5E22%40OSBPR01MB2552.jpnprd01.prod.outlook.com Best Regards, Hayato Kuroda FUJITSU LIMITED https://www.fujitsu.com/

RE: Improving the latch handling between logical replication launcher and worker processes.

2024-05-09 Thread Hayato Kuroda (Fujitsu)
and 2) subscription is created before attaching. In this case, the launcher will become un-sleepable because the latch is set but won't be reset. It may waste the CPU time. Best Regards, Hayato Kuroda FUJITSU LIMITED https://www.fujitsu.com/

RE: Slow catchup of 2PC (twophase) transactions on replica in LR

2024-05-09 Thread Hayato Kuroda (Fujitsu)
er to say 'force_alter = true' instead > of 'force_alter = on'. Fixed. Actually not sure it is better because I'm not a native. > 8. > $result = $node_subscriber->safe_psql('postgres', > "SELECT count(*) FROM pg_prepared_xacts;"); > is($result, q(0), "prepared trans

RE: Slow catchup of 2PC (twophase) transactions on replica in LR

2024-05-09 Thread Hayato Kuroda (Fujitsu)
d based on your previous comments. > > 8. TAP test - subscription name > > It's better to rename the SUBSCRIPTION in this TAP test so you can > avoid getting log warnings like: > > psql::4: WARNING: subscriptions created by regression test > cases should have names starting with "regress_" > psql::4: NOTICE: created replication slot "sub" on publisher Modified, but it was included in 0001. Best Regards, Hayato Kuroda FUJITSU LIMITED https://www.fujitsu.com/

RE: Slow catchup of 2PC (twophase) transactions on replica in LR

2024-05-09 Thread Hayato Kuroda (Fujitsu)
efore* the COMMIT PREPARED > > # verify the inserted rows got replicated ok Modified like yours, but changed based on the suggestion by Grammarly. > 8. > IIUC this test will behave the same even if you DON'T do the toggle > 'two_phase = on'. So I wonder is there something more you can do to > test this scenario more convincingly? I found an indicator. When the apply starts, it outputs the current status of two_phase option. I added wait_for_log() to ensure below appeared. Thought? ``` ereport(DEBUG1, (errmsg_internal("logical replication apply worker for subscription \"%s\" two_phase is %s", MySubscription->name, MySubscription->twophasestate == LOGICALREP_TWOPHASE_STATE_DISABLED ? "DISABLED" : MySubscription->twophasestate == LOGICALREP_TWOPHASE_STATE_PENDING ? "PENDING" : MySubscription->twophasestate == LOGICALREP_TWOPHASE_STATE_ENABLED ? "ENABLED" : "?"))); ``` Best Regards, Hayato Kuroda FUJITSU LIMITED https://www.fujitsu.com/

RE: Slow catchup of 2PC (twophase) transactions on replica in LR

2024-05-09 Thread Hayato Kuroda (Fujitsu)
+ ereport(ERROR, > + (errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE), > + errmsg("cannot disable two_phase when uncommitted prepared > transactions present"), > + errhint("Resolve these transactions and try again"))); > > The comment "/* Add error message */" seems unnecessary. Yeah, this was an internal flag. Removed. Best Regards, Hayato Kuroda FUJITSU LIMITED https://www.fujitsu.com/

RE: Pgoutput not capturing the generated columns

2024-05-08 Thread Hayato Kuroda (Fujitsu)
data->include_generated_columns is referred four times in the function. Can you store the value to a varibable? c. pg_decode_change() ``` -true); +true, data->include_generated_columns ); ``` Please remove the blank.

RE: Slow catchup of 2PC (twophase) transactions on replica in LR

2024-05-08 Thread Hayato Kuroda (Fujitsu)
cription must be dropped because it also prepares a transaction. Moved before the test case and added comments. > 19. > +# Make sure that there is 0 prepared transaction on the subscriber > +$result = $node_subscriber->safe_psql('postgres', > + "SELECT count(*) FROM pg_prepa

RE: Slow catchup of 2PC (twophase) transactions on replica in LR

2024-04-23 Thread Hayato Kuroda (Fujitsu)
Dear hackers, Per recent commit (b29cbd3da), our patch needed to be rebased. Here is an updated version. Best Regards, Hayato Kuroda FUJITSU LIMITED https://www.fujitsu.com/ v6-0001-Allow-altering-of-two_phase-option-of-a-SUBSCRIPT.patch Description: v6-0001-Allow-altering-of-two_phase

RE: Slow catchup of 2PC (twophase) transactions on replica in LR

2024-04-22 Thread Hayato Kuroda (Fujitsu)
. Attached patch set is a ported version for PG16, which breaks ABI. This can be used for testing purpose, but it won't be pushed to REL_16_STABLE. At least, this patchset can pass my github CI. Can you apply and check whether your issue is solved? Best Regards, Hayato Kuroda FUJIT

RE: Slow catchup of 2PC (twophase) transactions on replica in LR

2024-04-22 Thread Hayato Kuroda (Fujitsu)
aborted at that time. ``` subscriber=# ALTER SUBSCRIPTION sub SET (two_phase = off, force_alter = on); ALTER SUBSCRIPTION subscriber=# SELECT * FROM pg_prepared_xacts ; transaction | gid | prepared | owner | database -+-+--+---+------ (0 rows) ``` Best Regard

RE: Slow catchup of 2PC (twophase) transactions on replica in LR

2024-04-22 Thread Hayato Kuroda (Fujitsu)
g a new feature (e.g., replication command) for minor updates is generally prohibited We must consider another approach for backpatching, but we do not have solutions for now. Best Regards, Hayato Kuroda FUJITSU LIMITED https://www.fujitsu.com/global/  

RE: Disallow changing slot's failover option in transaction block

2024-04-18 Thread Hayato Kuroda (Fujitsu)
in the upgrade mode, but your patch seems to remove the condition. Can you clarify the reason? Other than that, the patch LGTM. Best Regards, Hayato Kuroda FUJITSU LIMITED https://www.fujitsu.com/

RE: Disallow changing slot's failover option in transaction block

2024-04-18 Thread Hayato Kuroda (Fujitsu)
_phase parameters > specified in the subscription" > > [1]: > https://www.postgresql.org/docs/devel/sql-altersubscription.html#SQL-ALTER > SUBSCRIPTION-PARAMS-SET I see, thanks for the clarification. Agreed that the description is not conflict with option 2. Best Regards

RE: Disallow changing slot's failover option in transaction block

2024-04-18 Thread Hayato Kuroda (Fujitsu)
gt; two_phase can be considered as a streaming option, so it's fine to > change the two_phase along with START_REPLICATION command. (the > two_phase is not changed in subscription DDLs, but get changed in > START_REPLICATION command). But the failover is closely related to a > replication slot itself. > Sorry, I cannot find statements. Where did you refer? Best Regards, Hayato Kuroda FUJITSU LIMITED https://www.fujitsu.com/

RE: Disallow changing slot's failover option in transaction block

2024-04-16 Thread Hayato Kuroda (Fujitsu)
ould we add the restriction to the doc? I feel [1] can be updated. [1]:https://www.postgresql.org/docs/devel/sql-altersubscription.html#SQL-ALTERSUBSCRIPTION-PARAMS-SET Best Regards, Hayato Kuroda FUJITSU LIMITED https://www.fujitsu.com/

RE: Slow catchup of 2PC (twophase) transactions on replica in LR

2024-04-15 Thread Hayato Kuroda (Fujitsu)
Attached zip file contains the PoC and used script. You can refer what I really did. Best Regards, Hayato Kuroda FUJITSU LIMITED https://www.fujitsu.com/ <>

RE: Slow catchup of 2PC (twophase) transactions on replica in LR

2024-04-15 Thread Hayato Kuroda (Fujitsu)
. 0004 - checks whether there are transactions prepared on publisher. The backend connects to the publisher and confirms it. If found, rejects the ALTER SUBSCRIPTION command. 0005 - adds TAP test for it. Best Regards, Hayato Kuroda FUJITSU LIMITED https://www.fujitsu.com/

RE: Slow catchup of 2PC (twophase) transactions on replica in LR

2024-04-10 Thread Hayato Kuroda (Fujitsu)
s. What do you think? Alternative idea is that worker pass a list of prepared transaction as new option in START_REPLICATION. This can reduce the number of inter-node communications, but sometimes the list may be huge. Best Regards, Hayato Kuroda FUJITSU LIMITED https://www.fujitsu.com/

RE: Improve eviction algorithm in ReorderBuffer

2024-04-10 Thread Hayato Kuroda (Fujitsu)
er of stored transactions does not affect to the insert operation, we may able to add the node while creating ReorederBufferTXN and remove while cleaning up it. This can reduce branches in ReorderBufferChangeMemoryUpdate(). Best Regards, Hayato Kuroda FUJITSU LIMITED https://www.fujitsu.com/ <>

RE: Is this a problem in GenericXLogFinish()?

2024-04-09 Thread Hayato Kuroda (Fujitsu)
Dear Michael, > On Fri, Apr 05, 2024 at 06:22:58AM +0000, Hayato Kuroda (Fujitsu) wrote: > > Thanks for pointing out. Yes, we fixed a behavior by the commit aa5edbe37, > > but we missed the redo case. I made a fix patch based on the suggestion [1]. > > + bool

RE: Is this a problem in GenericXLogFinish()?

2024-04-05 Thread Hayato Kuroda (Fujitsu)
ogReaderState *record) writeopaque->hasho_nextblkno = xldata->nextblkno; } +if (xldata->ntups == 0 && +xldata->is_prim_bucket_same_wrt && +!xldata->is_prev_bucket_same_wrt) + elog(LOG, "XXX no

RE: Improve eviction algorithm in ReorderBuffer

2024-03-29 Thread Hayato Kuroda (Fujitsu)
ould be started with upper case? Best Regards, Hayato Kuroda FUJITSU LIMITED https://www.fujitsu.com/

RE: Synchronizing slots from primary to standby

2024-03-28 Thread Hayato Kuroda (Fujitsu)
361%40paquier.xyz Best Regards, Hayato Kuroda FUJITSU LIMITED https://www.fujitsu.com/

RE: pg_upgrade and logical replication

2024-03-27 Thread Hayato Kuroda (Fujitsu)
3A13 Yeah, I think it is an oversight in f17529. Previously subscriptions which receiving changes were confirmed to be caught up, I missed to add the line while restructuring the script. +1 for your fix. Best Regards, Hayato Kuroda FUJITSU LIMITED https://www.fujitsu.com/

RE: speed up a logical replica setup

2024-03-25 Thread Hayato Kuroda (Fujitsu)
o connect to another publisher as well - this may lead conflicts. This causes because both launcher/workers start after recovery finishes. So, based on the Ashutosh's point, should we remove such replication objects? Best Regards, Hayato Kuroda FUJITSU LIMITED https://www.fujitsu.com/

RE: speed up a logical replica setup

2024-03-25 Thread Hayato Kuroda (Fujitsu)
tarts. Alternative one is to ease the condition. How do you think? [1]: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=serinus=2024-03-25%2013%3A03%3A07 [2]: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=culicidae=2024-03-25%2013%3A53%3A58 Best Regards, Hayato Kuroda FUJITSU LIMITED https://www.fujitsu.com/

RE: speed up a logical replica setup

2024-03-25 Thread Hayato Kuroda (Fujitsu)
- I don't think it is not completely needed. If we can agree a specification in sometime, it's OK for me to add them. If you ask me, I still prefer Tomas's approach. Best Regards, Hayato Kuroda FUJITSU LIMITED https://www.fujitsu.com/

RE: speed up a logical replica setup

2024-03-25 Thread Hayato Kuroda (Fujitsu)
well. Both ways are OK, but I prefer to unify checks a bit. The number of working modes in the same executables should be reduced as much as possible. Also, I feel the current specification is acceptable. pg_upgrade checks one by one and exits soon in bad cases. If both old and new clusters have issues, the first run only reports the old one's issues. After DBA fixes and runs again, issues on the new cluster are output. [1]: https://www.postgresql.org/message-id/8d52c226-7e34-44f7-a919-759bf8d81541%40enterprisedb.com Best Regards, Hayato Kuroda FUJITSU LIMITED https://www.fujitsu.com/

RE: Have pg_basebackup write "dbname" in "primary_conninfo"?

2024-03-19 Thread Hayato Kuroda (Fujitsu)
SE="user=kuroda dbname=postgres" pg_basebackup -D data_N2 -R -v The primary_conninfo written in the file will be: primary_conninfo = 'user=hayato ... dbname=''user=kuroda dbname=postgres''' [1]: https://www.postgresql.org/docs/devel/libpq-pgservice.html [2]: https://www.postgresql.org/docs/devel/libpq-

RE: speed up a logical replica setup

2024-03-18 Thread Hayato Kuroda (Fujitsu)
`` > > > > Sorry if we have already discussed. I think the registration can be moved > > just > > before the boot of the standby. Before that, the callback will be no-op. > > But it can also stay where it is. What is the advantage of moving it later? I thought we could reduce the risk of bugs. Previously some bugs were reported because the registration is too early. However, this is not a strong opinion. Best Regards, Hayato Kuroda FUJITSU LIMITED https://www.fujitsu.com/

RE: PostgreSQL 17 Release Management Team & Feature Freeze

2024-03-18 Thread Hayato Kuroda (Fujitsu)
uld wait checking from you. Thanks. Best Regards, Hayato Kuroda FUJITSU LIMITED https://www.fujitsu.com/

RE: speed up a logical replica setup

2024-03-17 Thread Hayato Kuroda (Fujitsu)
* XXX this code was extracted from BootStrapXLOG(). ``` So, can we extract the common part to somewhere? Since system identifier is related with the controldata file, I think it can be located in controldata_util.c. 41. You said like below in [1], but I could not find the related fix. Can you clarify? > That's a good point. We should state in the documentation that GUCs specified > in > the command-line options are ignored during the execution. [1]: https://www.postgresql.org/message-id/40595e73-c7e1-463a-b8be-49792e870007%40app.fastmail.com Best Regards, Hayato Kuroda FUJITSU LIMITED https://www.fujitsu.com/global/

RE: PostgreSQL 17 Release Management Team & Feature Freeze

2024-03-17 Thread Hayato Kuroda (Fujitsu)
ript, not the feature. The issue has already been analyzed and the fix patch was pushed as f17529b710. Best Regards, Hayato Kuroda FUJITSU LIMITED https://www.fujitsu.com/

RE: speed up a logical replica setup

2024-03-10 Thread Hayato Kuroda (Fujitsu)
]: http://cfbot.cputube.org/highlights/all.html#4637 Best Regards, Hayato Kuroda FUJITSU LIMITED https://www.fujitsu.com/

RE: speed up a logical replica setup

2024-03-08 Thread Hayato Kuroda (Fujitsu)
t based on my comment [2] the feature was removed. It might be too optimistic. [1]: https://www.postgresql.org/message-id/TY3PR01MB9889CCBD4D9DAF8BD2F18541F56F2%40TY3PR01MB9889.jpnprd01.prod.outlook.com [2]: https://www.postgresql.org/message-id/TYCPR01MB12077756323B79042F29DDAEDF54C2%40TYCPR01MB12077.jpnprd01.prod.outlook.com Best Regards, Hayato Kuroda FUJITSU LIMITED https://www.fujitsu.com/

RE: speed up a logical replica setup

2024-03-06 Thread Hayato Kuroda (Fujitsu)
om [7]: https://www.postgresql.org/message-id/OS3PR01MB98828B15DD9502C91E0C50D7F57D2%40OS3PR01MB9882.jpnprd01.prod.outlook.com [8]: https://www.postgresql.org/message-id/be92c57b-82e1-4920-ac31-a8a04206db7b%40app.fastmail.com Best Regards, Hayato Kuroda FUJITSU LIMITED https://www.fujitsu.com/global

RE: Some shared memory chunks are allocated even if related processes won't start

2024-03-04 Thread Hayato Kuroda (Fujitsu)
he reference for the chunk might be remained. Overall, it may be needed that dsm_registry may be also extended. I do not start working yet, so will share results after trying them. Best Regards, Hayato Kuroda FUJITSU LIMITED https://www.fujitsu.com/

RE: Some shared memory chunks are allocated even if related processes won't start

2024-03-04 Thread Hayato Kuroda (Fujitsu)
me. Therefore, there is no way to re-alloc the shared memory. Best Regards, Hayato Kuroda FUJITSU LIMITED https://www.fujitsu.com/

RE: Some shared memory chunks are allocated even if related processes won't start

2024-03-04 Thread Hayato Kuroda (Fujitsu)
idea is still valid, which allows the allocation of shared memory dynamically. This is a bit efficient for the system which tuples won't be frozen. Thought? [1]: https://www.postgresql.org/docs/devel/routine-vacuuming.html#VACUUM-FOR-WRAPAROUND Best Regards, Hayato Kuroda FUJITSU LIMITED https://www.fujitsu.com/

RE: Some shared memory chunks are allocated even if related processes won't start

2024-03-03 Thread Hayato Kuroda (Fujitsu)
Dear Tom, Thanks for replying! > "Hayato Kuroda (Fujitsu)" writes: > > While reading codes, I found that ApplyLauncherShmemInit() and > AutoVacuumShmemInit() > > are always called even if they would not be launched. > > It may be able to reduce the start time t

Some shared memory chunks are allocated even if related processes won't start

2024-03-03 Thread Hayato Kuroda (Fujitsu)
/postgres/postgres/commit/8b2bcf3f287c79eaebf724cba57e5ff664b01e06 Best Regards, Hayato Kuroda FUJITSU LIMITED https://www.fujitsu.com/ dynamic_allocation.diff Description: dynamic_allocation.diff

RE: speed up a logical replica setup

2024-02-27 Thread Hayato Kuroda (Fujitsu)
shut down cleanly before running pg_rewind ``` Best Regards, Hayato Kuroda FUJITSU LIMITED https://www.fujitsu.com/

RE: Have pg_basebackup write "dbname" in "primary_conninfo"?

2024-02-27 Thread Hayato Kuroda (Fujitsu)
ons2() would be done only for the valid (=lastly specified) > connection options. Oh, this patch missed the straightforward case: pg_basebackup -D data_N2 -d "user=postgres dbname=replication" -R -> dbname would not be appeared in primary_conninfo. So I think it cannot be applied a

RE: Have pg_basebackup write "dbname" in "primary_conninfo"?

2024-02-27 Thread Hayato Kuroda (Fujitsu)
uot; -R` -> dbname would not be appeared in primary_conninfo. This is because `if (connection_string)` case in GetConnection() explicy override a dbname to "replication". I've tried to add a dummy entry {"dbname", NULL} pair before the overriding, but it is no-op. Because The

RE: Have pg_basebackup write "dbname" in "primary_conninfo"?

2024-02-27 Thread Hayato Kuroda (Fujitsu)
ave proposed the point because I thought pg_basebackup basically wanted to do a physical replication. But if the general libpq rule is stronger than it, we should not apply my add_NULL_check.txt. Let's forget it. Best Regards, Hayato Kuroda FUJITSU LIMITED https://www.fujitsu.com/

RE: speed up a logical replica setup

2024-02-26 Thread Hayato Kuroda (Fujitsu)
we should choose either of below items. Thought? a) enforce the standby must be *stopped*, and options like config_file can be specified via option. b) enforce the standby must be *running*, options like config_file would be read via SHOW command. Best Regards, Hayato Kuroda FUJITSU LIMITED https://www.fujitsu.com/global/

RE: speed up a logical replica setup

2024-02-25 Thread Hayato Kuroda (Fujitsu)
has been rejected because I was not sure the location of the declaration and the implementation. Function which could be called from clients must be declared in src/include/{common|fe_utils|utils} directory. I saw files located at there but I could not appropriate location for CheckDataVersion. Also, I did not think new file should be created only for this function. Best Regards, Hayato Kuroda FUJITSU LIMITED https://www.fujitsu.com/

RE: speed up a logical replica setup

2024-02-22 Thread Hayato Kuroda (Fujitsu)
$node_f->init(allows_streaming => 'logical'); > + $node_f->start; > Fixed. Also, recent commit [1] allows to run the initdb forcibly. So followed. New patch can be available in [2]. [1]: https://github.com/postgres/postgres/commit/ff9e1e764fcce9a34467d614611a34d4d2a91b50 [2]: https://www.postgresql.org/message-id/TYCPR01MB12077CD76B53F9CAE7AC0F5562%40TYCPR01MB12077.jpnprd01.prod.outlook.com Best Regards, Hayato Kuroda FUJITSU LIMITED https://www.fujitsu.com/

RE: speed up a logical replica setup

2024-02-22 Thread Hayato Kuroda (Fujitsu)
FROM pg_settings > WHERE name IN (" > +"'max_logical_replication_workers', " > +"'max_replication_slots', " > +"'max_worker_processes', " > +"'primary_slot_name') " > +"ORDER BY name"); Fixed. New version can be available in [2] [1]: https://www.postgresql.org/message-id/3ee79f2c-e8b3-4342-857c-a31b87e1afda%40eisentraut.org [2]: https://www.postgresql.org/message-id/TYCPR01MB12077CD76B53F9CAE7AC0F5562%40TYCPR01MB12077.jpnprd01.prod.outlook.com Best Regards, Hayato Kuroda FUJITSU LIMITED https://www.fujitsu.com/

RE: speed up a logical replica setup

2024-02-22 Thread Hayato Kuroda (Fujitsu)
t be possible > to rollback to the earlier state which had physical-standby > replication. I felt we should document this and also add it to the > console message like how we do in case of pg_upgrade. Added. New version can be available in [1] [1]: https://www.postgresql.org/message-id/TYCPR01MB12077CD76B53F9CAE7AC0F5562%40TYCPR01MB12077.jpnprd01.prod.outlook.com Best Regards, Hayato Kuroda FUJITSU LIMITED https://www.fujitsu.com/

RE: speed up a logical replica setup

2024-02-22 Thread Hayato Kuroda (Fujitsu)
d the function call again. Note that PQclear() was not added because it is only related with the application. Best Regards, Hayato Kuroda FUJITSU LIMITED https://www.fujitsu.com/

RE: speed up a logical replica setup

2024-02-22 Thread Hayato Kuroda (Fujitsu)
ped at that time. I felt it is better that users can run the command immediately later the copying. Thought? [1]: https://www.postgresql.org/docs/current/storage-file-layout.html Best Regards, Hayato Kuroda FUJITSU LIMITED https://www.fujitsu.com/

RE: Have pg_basebackup write "dbname" in "primary_conninfo"?

2024-02-20 Thread Hayato Kuroda (Fujitsu)
can avoid writing when the dbname is same as the username. [1]: https://www.postgresql.org/message-id/CAA4eK1KH1d1J5giPMZVOtMe0iqncf1CpNwkBKoYAmXdC-kEGZg%40mail.gmail.com Best Regards, Hayato Kuroda FUJITSU LIMITED https://www.fujitsu.com/

RE: Have pg_basebackup write "dbname" in "primary_conninfo"?

2024-02-20 Thread Hayato Kuroda (Fujitsu)
== NULL || conn->dbName[0] == '\0') { free(conn->dbName); conn->dbName = strdup(conn->pguser); if (!conn->dbName) goto oom_error; } ``` Best Regards, Hayato Kuroda FUJITSU LIMITED https://www.fujitsu.com/ d

RE: Have pg_basebackup write "dbname" in "primary_conninfo"?

2024-02-20 Thread Hayato Kuroda (Fujitsu)
ied proposed patch. When `pg_basebackup -D data_N2 -R` is used: ``` primary_conninfo = 'user=hayato ... dbname=hayato ... ``` But when `pg_basebackup -d "" -D data_N2 -R` is used: ``` primary_conninfo = 'user=hayato ... dbname=replication ``` Best Regards, Hayato Kuroda FUJITSU LIMITED https://www.fujitsu.com/

RE: Have pg_basebackup write "dbname" in "primary_conninfo"?

2024-02-20 Thread Hayato Kuroda (Fujitsu)
GenerateRecoveryConfig() is called is pg_rewind; > I can't see any adverse affects from the proposed change. But it's perfectly > possible there's something blindingly obvious I'm overlooking. On-going feature pg_createsubscriber[1] also uses GenerateRecoveryConfig(), but I can't see any b

RE: speed up a logical replica setup

2024-02-20 Thread Hayato Kuroda (Fujitsu)
n recovery progress > pg_createsubscriber: error: could not obtain recovery progress > pg_createsubscriber: error: could not obtain recovery progress Yeah, v22-0001 cannot detect the disconnection from primary and standby. V22-0007 can detect the standby crash, but v22 set could not detect the primary crash. Euler came up with an approach [2] for it but not implemented yet. [1]: https://www.postgresql.org/message-id/TYCPR01MB12077756323B79042F29DDAEDF54C2%40TYCPR01MB12077.jpnprd01.prod.outlook.com [2]: https://www.postgresql.org/message-id/2231a04b-f2d4-4a4e-b5cd-56be8b002427%40app.fastmail.com Best Regards, Hayato Kuroda FUJITSU LIMITED https://www.fujitsu.com/

RE: pg_upgrade and logical replication

2024-02-18 Thread Hayato Kuroda (Fujitsu)
; $new_sub->wait_for_subscription_sync($publisher, 'regress_sub5'); > > Like: > # Enable the subscription > $new_sub->safe_psql('postgres', "ALTER SUBSCRIPTION regress_sub5 > ENABLE"); > > # Wait until all tables of subscription 'regress_sub5' are synchronized > $new_sub->wait_for_subscription_sync($publisher, 'regress_sub5'); Per comments from Amit [1], I did not change. [1]: https://www.postgresql.org/message-id/CAA4eK1Ls%2BRmJtTvOgaRXd%2BeHSY3x-KUE%3DsfEGQoU-JF_UzA62A%40mail.gmail.com Best Regards, Hayato Kuroda FUJITSU LIMITED https://www.fujitsu.com/ v5-0001-Fix-testcase.patch Description: v5-0001-Fix-testcase.patch

RE: speed up a logical replica setup

2024-02-16 Thread Hayato Kuroda (Fujitsu)
es the number of them is more than two. Since it may be useful, I will post top-up patch on Monday, if there are no updating. [1]: https://www.postgresql.org/message-id/89ccf72b-59f9-4317-b9fd-1e6d20a0c3b1%40app.fastmail.com [2]: https://www.postgresql.org/message-id/TYCPR01MB1207713BEC5C379A05D65E342F54B2%40TYCPR01MB12077.jpnprd01.prod.outlook.com Best Regards, Hayato Kuroda FUJITSU LIMITED https://www.fujitsu.com/global/

RE: speed up a logical replica setup

2024-02-16 Thread Hayato Kuroda (Fujitsu)
gt; > This is failing because slot name slot2 is used between node2->node3 > but pg_createsubscriber is checked for slot1, the slot which is used > for replication between node1->node2. > Thoughts? Right. The inconsistency is quite strange. Overall, I felt such a case must be rejected

RE: speed up a logical replica setup

2024-02-15 Thread Hayato Kuroda (Fujitsu)
es before give up using the pg_stat_wal_receiver query. Do you have a better plan? > It's good to determine the threshold. It can define the number of acceptable loss of walreceiver during the loop. I think we should retry at least the postmaster revives the walreceiver. The checking would work once per seconds, so more than 5 (or 10) may be better. Thought? Best Regards, Hayato Kuroda FUJITSU LIMITED https://www.fujitsu.com/global/

RE: pg_upgrade and logical replication

2024-02-15 Thread Hayato Kuroda (Fujitsu)
->safe_psql( > 'postgres', qq[ > CREATE TABLE tab_upgraded1(id int); > CREATE TABLE tab_upgraded2(id int); > ]); > $old_sub->safe_psql( > 'postgres', qq[ > CREATE TABLE tab_upgraded1(id int); > CREATE TABLE tab_upgraded2(id int); > ]); Yes, earlier definitions were removed instead. Also, some comments were adjusted based on these fixes. Best Regards, Hayato Kuroda FUJITSU LIMITED https://www.fujitsu.com/ v4-0001-Fix-testcase.patch Description: v4-0001-Fix-testcase.patch

RE: pg_upgrade and logical replication

2024-02-15 Thread Hayato Kuroda (Fujitsu)
essage-id/TYCPR01MB12077B16EEDA360BA645B96F8F54C2%40TYCPR01MB12077.jpnprd01.prod.outlook.com Best Regards, Hayato Kuroda FUJITSU LIMITED https://www.fujitsu.com/

RE: pg_upgrade and logical replication

2024-02-15 Thread Hayato Kuroda (Fujitsu)
ay lead some confusion. I recreated a patch for creating pub/sub and dropping them at cleanup for every test cases. PSA a new version. Best Regards, Hayato Kuroda FUJITSU LIMITED https://www.fujitsu.com/ v3-0001-Fix-testcase.patch Description: v3-0001-Fix-testcase.patch

RE: speed up a logical replica setup

2024-02-14 Thread Hayato Kuroda (Fujitsu)
tandby in case of failure? Shouldn't we suggest to remove the target once? * Can we move outputs to stdout? [1]: https://www.postgresql.org/message-id/TYCPR01MB1207713BEC5C379A05D65E342F54B2%40TYCPR01MB12077.jpnprd01.prod.outlook.com Best Regards, Hayato Kuroda FUJITSU LIMITED https://www.fujitsu.com/global/

RE: pg_upgrade and logical replication

2024-02-13 Thread Hayato Kuroda (Fujitsu)
139 +310,5 @@ is($result, qq(1), > "check the data is synced after enabling the subscription for > the table that was in init state" > ); > > -# cleanup > Removed. PSA a new version patch. Best Regards, Hayato Kuroda FUJITSU LIMITED https://www.fujitsu.co

RE: pg_upgrade and logical replication

2024-02-13 Thread Hayato Kuroda (Fujitsu)
successful. Files=1, Tests=14, 9 wallclock secs ( 0.03 usr 0.00 sys + 0.55 cusr 1.08 csys = 1.66 CPU) Result: PASS ``` How do you think? [1]: https://www.postgresql.org/docs/devel/pgupgrade.html Best Regards, Hayato Kuroda FUJITSU LIMITED https://www.fujitsu.com/ 0001-Fix-testcase.patch Description: 0001-Fix-testcase.patch

RE: speed up a logical replica setup

2024-02-13 Thread Hayato Kuroda (Fujitsu)
ns. I felt current code followed the style. Thought? New patch is available in [2]. [1]: https://www.postgresql.org/docs/devel/error-style-guide.html [2]: https://www.postgresql.org/message-id/TYCPR01MB12077A6BB424A025F04A8243DF54F2%40TYCPR01MB12077.jpnprd01.prod.outlook.com Best Regards, Hayato Kuroda FUJITSU LIMITED https://www.fujitsu.com/

RE: speed up a logical replica setup

2024-02-13 Thread Hayato Kuroda (Fujitsu)
y has been promoted once), we cannot resume the physical replication > as-is. IIUC the easiest method to retry is removing a cluster once and > restarting > from pg_basebackup. If so, no need to cleanup the standby because it is > corrupted. > We just say "Please remove the clus

RE: speed up a logical replica setup

2024-02-13 Thread Hayato Kuroda (Fujitsu)
ta": > + printf(_(" -d, --database=DBNAME database to > create a subscription\n")); > + printf(_(" -n, --dry-run stop before > modifying anything\n")); > + printf(_(" -t, --recovery-timeout=SECS seconds to wait > for recovery to end\n")); > + printf(_(" -r, --retainretain log file > after success\n")); > + printf(_(" -v, --verbose output verbose > messages\n")); > + printf(_(" -V, --version output version > information, then exit\n")); Changed. New patch is available in [2]. [1]: https://www.postgresql.org/message-id/TYCPR01MB1207713BEC5C379A05D65E342F54B2%40TYCPR01MB12077.jpnprd01.prod.outlook.com [2]: https://www.postgresql.org/message-id/TYCPR01MB12077A6BB424A025F04A8243DF54F2%40TYCPR01MB12077.jpnprd01.prod.outlook.com Best Regards, Hayato Kuroda FUJITSU LIMITED https://www.fujitsu.com/

RE: speed up a logical replica setup

2024-02-09 Thread Hayato Kuroda (Fujitsu)
atesubscriber_16389_3884" on database "testdb" pg_createsubscriber: XXX: sleep 20s ``` Best Regards, Hayato Kuroda FUJITSU LIMITED https://www.fujitsu.com/global/ N1.log Description: N1.log result.dat Description: result.dat server_start_20240209T115112.963.log Description: s

RE: Improve eviction algorithm in ReorderBuffer

2024-02-08 Thread Hayato Kuroda (Fujitsu)
/CAD21AoB-7mPpKnLmBNfzfavG8AiTwEgAdVMuv%3DjzmAp9ex7eyQ%40mail.gmail.com Best Regards, Hayato Kuroda FUJITSU LIMITED https://www.fujitsu.com/

RE: speed up a logical replica setup

2024-02-07 Thread Hayato Kuroda (Fujitsu)
er does nothing [2][3]. > Oh, thanks. Just to confirm - pglogical set shared_preload_libraries to '', should we follow or not? Best Regards, Hayato Kuroda FUJITSU LIMITED https://www.fujitsu.com/global/

RE: speed up a logical replica setup

2024-02-07 Thread Hayato Kuroda (Fujitsu)
connections and use SQL functions (instead of replication commands). Is it a requirement for v16-0003? > No, it is not required by 0003. I forgot the decision that we force DBAs to open normal connection establishments for pg_createsubscriber. Please ignore... [1]: https://www.open-std.org/jtc1/sc22/wg14/

RE: speed up a logical replica setup

2024-02-06 Thread Hayato Kuroda (Fujitsu)
we can partially protect the database. But there is still a room. d) Overwrite both port and listen_addresses. This can protect databases perfectly but no one can monitor. Hmm, which one should be chosen? I prefer c) or d). Do you know how pglogical_create_subscriber does? Best Regards, Hayato

RE: speed up a logical replica setup

2024-02-06 Thread Hayato Kuroda (Fujitsu)
8902B992A4F2E99E1385EDF56F2%40TY3PR01MB9889.jpnprd01.prod.outlook.com Best Regards, Hayato Kuroda FUJITSU LIMITED https://www.fujitsu.com/

RE: speed up a logical replica setup

2024-02-06 Thread Hayato Kuroda (Fujitsu)
still can set an arbitrary connection string as primary_conninfo. You just use longer string unintentionally. Best Regards, Hayato Kuroda FUJITSU LIMITED https://www.fujitsu.com/ shorter_subconninfo.sh Description: shorter_subconninfo.sh

RE: speed up a logical replica setup

2024-02-06 Thread Hayato Kuroda (Fujitsu)
e server log during pg_createsubscriber, and we can see that walreceiver exits before receiving all the required changes. I cannot find a path yet, but the inconsistency lead the situation which walreceiver exists but startup remains. This also said that recovery status must be checked in

RE: Improve eviction algorithm in ReorderBuffer

2024-02-05 Thread Hayato Kuroda (Fujitsu)
> > HEAD w/ patch: > 2001.094 ms > > I set a large enough value to logical_decoding_work_mem not to evict > any transactions. I can see about about 10% performance regression in > this case. Thanks for running. I think this workload is the worst and an extreme case which would not be occurred on the real system (Such a system should be fixed), so we can say that the regression is up to -10%. I felt it could be negligible but how do other think? Best Regards, Hayato Kuroda FUJITSU LIMITED https://www.fujitsu.com/

RE: Is this a problem in GenericXLogFinish()?

2024-02-04 Thread Hayato Kuroda (Fujitsu)
buffers must not be PageSetLSN()'d. Other pages, e.g., metabuf, has already been followed the rule. I updated the patch based on the requirement. Best Regards, Hayato Kuroda FUJITSU LIMITED https://www.fujitsu.com/ v2_avoid_registration.patch Description: v2_avoid_registration.patch

RE: Is this a problem in GenericXLogFinish()?

2024-02-04 Thread Hayato Kuroda (Fujitsu)
.is_prev_bucket_same_wrt is false) So, I think my patch (after removing elog(...) part) can fix the issue. Thought? [1]: ``` LOG: XXX: is_wbuf_registered: false CONTEXT: while vacuuming index "hash_cleanup_index" of relation "public.hash_cleanup_heap" STATEMENT: VACUUM

RE: speed up a logical replica setup

2024-01-31 Thread Hayato Kuroda (Fujitsu)
xist. Also, the physical slot is still remained on the primary. In short, "temp_replslot" should be "primary_slot_name". PSA a script file for reproducing. Best Regards, Hayato Kuroda FUJITSU LIMITED https://www.fujitsu.com/ test_0201.sh Description: test_0201.sh

RE: speed up a logical replica setup

2024-01-31 Thread Hayato Kuroda (Fujitsu)
abase. > Not sure, but can we do the replication origin functions by these privilege? According to the doc[1], these ones seem not to be related. [1]: https://www.postgresql.org/docs/devel/functions-admin.html#FUNCTIONS-REPLICATION Best Regards, Hayato Kuroda FUJITSU LIMITED https://www.fujitsu.com/global/

RE: speed up a logical replica setup

2024-01-31 Thread Hayato Kuroda (Fujitsu)
Dear Fabrízio, Thanks for reporting. I understood that the issue occurred on v11 and v12. I will try to reproduce and check the reason. Best Regards, Hayato Kuroda FUJITSU LIMITED https://www.fujitsu.com/global/

RE: Documentation to upgrade logical replication cluster

2024-01-30 Thread Hayato Kuroda (Fujitsu)
or later, then only logical slots on the primary are copied to the new standby. ``` Best Regards, Hayato Kuroda FUJITSU LIMITED https://www.fujitsu.com/

RE: Improve eviction algorithm in ReorderBuffer

2024-01-30 Thread Hayato Kuroda (Fujitsu)
strategy minimizes the overheads of updating the transaction's memory counter. ``` s/pudate/update/ 08. IIUC, if more than 1024 transactions are running but they have small amount of changes, the performance may be degraded, right? Do you have a result in sucha a case? Best Regards, Hayato Kuroda FUJITSU LIMITED https://www.fujitsu.com/

RE: speed up a logical replica setup

2024-01-30 Thread Hayato Kuroda (Fujitsu)
6102C88FA1C29F56F2%40TY3PR01MB9889.jpnprd01.prod.outlook.com [3]: https://www.postgresql.org/message-id/CAA4eK1JRgnhv_ySzuFjN7UaX9qxz5Hqcwew7Fk%3D%2BAbJbu0Kd9w%40mail.gmail.com Best Regards, Hayato Kuroda FUJITSU LIMITED https://www.fujitsu.com/global/

RE: Documentation to upgrade logical replication cluster

2024-01-28 Thread Hayato Kuroda (Fujitsu)
Dear Vignesh, Thanks for updating the patch! For now, v4 patch LGTM. Best Regards, Hayato Kuroda FUJITSU LIMITED https://www.fujitsu.com/

RE: speed up a logical replica setup

2024-01-25 Thread Hayato Kuroda (Fujitsu)
R8n12BmRz7yBP3EBNdHDhmdgxQFA9vS%2BzPR%2B3Kw%40mail.gmail.com [3]: https://www.postgresql.org/message-id/TY3PR01MB9889678E47B918F4D83A6FD8F57B2%40TY3PR01MB9889.jpnprd01.prod.outlook.com [4]: https://www.postgresql.org/message-id/TY3PR01MB9889C362FF76102C88FA1C29F56F2%40TY3PR01MB9889.jpnprd01.prod

RE: speed up a logical replica setup

2024-01-25 Thread Hayato Kuroda (Fujitsu)
nfo so --publisher-conninfo may not be needed. The parameter does not contain database name, so --databases is still needed. I imagine like: 1. Parse options 2. Turn on standby 3. Verify the standby 4. Turn off standby 5. Get primary_conninfo from standby 6. Connect to primary (concat of primary_conninfo and an option is used) 7. Verify the primary ... How do you think? Best Regards, Hayato Kuroda FUJITSU LIMITED https://www.fujitsu.com/global/

RE: speed up a logical replica setup

2024-01-25 Thread Hayato Kuroda (Fujitsu)
ink "convert" and "transform" fit for this case. However, "create", > > "convert" and "transform" have 6, 7 and 9 characters, respectively. I > > suggest > > that we avoid long names (subscriber already has 10 characters). My > > preference > > is pg_createsubscriber. > > That seems best to me. Just FYI - I'm ok to change the name to pg_createsubscriber. Best Regards, Hayato Kuroda FUJITSU LIMITED

RE: speed up a logical replica setup

2024-01-25 Thread Hayato Kuroda (Fujitsu)
for-statement, like ``` for (int i = 0; i < MAX; i++) ``` 20. Some comments, docs, and outputs must be fixed when the name is changed. Best Regards, Hayato Kuroda FUJITSU LIMITED

RE: speed up a logical replica setup

2024-01-24 Thread Hayato Kuroda (Fujitsu)
cannot omit these, but setting smaller shared_buffers will reduce the start time. One approach is to overwrite the GUC to smaller value, but I think we cannot determine the appropriate value. Best Regards, Hayato Kuroda FUJITSU LIMITED run.sh Description: run.sh perf_result.xlsx Description

RE: Documentation to upgrade logical replication cluster

2024-01-24 Thread Hayato Kuroda (Fujitsu)
be allocated to step, not para. That's why the rendering is bit a strange. Best Regards, Hayato Kuroda FUJITSU LIMITED

RE: speed up a logical replica setup

2024-01-22 Thread Hayato Kuroda (Fujitsu)
tch". So, how about using "pg_switchsubscriber"? Best Regards, Hayato Kuroda FUJITSU LIMITED

  1   2   3   4   5   6   >