Hi all,
I create POC patch for my proposal of new feature for high availability.
I want to discuss about this feature. But this feature might be PG11
because discussion is not enough.
This patch enables walsender for async to wait until walsender for sync confirm
WAL is flashed to Disk. This
From: Robert Haas [mailto:robertmh...@gmail.com]
>> This patch enables walsender for async to wait until walsender for sync
>> confirm
>> WAL is flashed to Disk. This feature is activated when GUC parameter
>> "async_walsender_delay" is set on.
> So this new option makes asynchronous replication s
Hello,
I found a problem with libpq connection failover.
If primary_conninfo in recovery.conf has 'target_session_attrs=read-write', the
standby fails to start.
How to reproduce the bug:
1. Prepare two standby (standby_1, standby_2) for one master.
On standby_1, primary_conninfo in recove
From: Michael Paquier [mailto:michael.paqu...@gmail.com]
> if (!PQsendQuery(conn,
>- "show transaction_read_only"))
>+ "SHOW transaction_read_only"))
>Or perhaps the replication command parser could be made
Hello,
This this is my first posting to the mailing list.
I am interested in multiple hosts of libpq [1], then I found the bug in this
feature.
When I set "target_session_attrs" to "any" and call PQsendQuery, my application
is succeeded.
However, when I set "target_session_attrs" to "read-writ
From: Ashutosh Bapat [mailto:ashutosh.ba...@enterprisedb.com]
> Per the documentation [1], "PQgetResult must be called repeatedly
> until it returns a null pointer, indicating that the command is
> done.". The code in PQgetResult() under CONNECTION_CHECK_WRITABLE
> case, violates that. The patch f
From: Ashutosh Bapat [mailto:ashutosh.ba...@enterprisedb.com]
>Sorry, attached wrong patch. Here's the right one.
> The code expects that there will be two PQgetResult() calls required.
> One to fetch the result of SHOW command and the other to extract NULL.
> If we require more calls or unexpecte
From: Michael Paquier [mailto:michael.paqu...@gmail.com]
>This has not been added yet to the next CF. As Ashutosh mentioned
>things tend to be easily forgotten. So I have added it here:
>https://commitfest.postgresql.org/13/982/
Thank you for adding this problem to CF.
> I have noticed this typo
Hi all,
I propose a new feature for high availability.
This configuration is effective for following configuration:
1. Primary and synchronous standby are in the same center; called main center.
2. Asynchronous standby is in the another center; called backup center.
(The backup center is l