be
wrote:
> On Wed, 2023-02-01 at 14:52 +0800, qihua wu wrote:
> > When run a cluster with sync replication, if DML is done on primary, but
> primary is
> > isolated from all slave, then the DML will hang, if cancel it DML, it
> will say:
> > WARNING: canceling wait
ote:
>
>> Hi,
>>
>> On Wed, Feb 01, 2023 at 02:52:49PM +0800, qihua wu wrote:
>> > When run a cluster with sync replication, if DML is done on primary, but
>> > primary is isolated from all slave, then the DML will hang, if cancel it
>> > DML, it will
When run a cluster with sync replication, if DML is done on primary, but
primary is isolated from all slave, then the DML will hang, if cancel it
DML, it will say:
WARNING: canceling wait for synchronous replication due to user request
DETAIL: The transaction has already committed locally, but mi
e';
-[ RECORD 1 ]+--
wait_event_type | IPC
wait_event | SyncRep
state| active
On Tue, Jan 31, 2023 at 3:35 PM qihua wu wrote:
> We are using sync replication, if a session runs an insert, and then
> commit, the client is actually waiting for commit to compl
We are using sync replication, if a session runs an insert, and then
commit, the client is actually waiting for commit to complete, but looks
like this wait doesn't show in pg_stat_activity.
In one session I inserted a row (auto commit), it hangs there.
example=# insert into test_timteout select
I tried to find out how timeout, such as statement_timeout, works in
source code, But there are so many places it appears in the code, anybody
could show me some clue about where is the entry point for timeout
implementation?
I have a patroni cluster running in sync mode and at least 2 nodes should
be synced for commit. Now I brought down one node, so only one slave is in
sync, and then write a java program to write the data to primary in
autocommit = false mode, I set statement_timeout to 10, hopping the jave
will thro
tioning happens, it commits on neither
primary or slave which is good, and if network partitioning doesn't happen,
it will more likely to commit on both primary and locally and local commit
is less likely to error out.
On Sat, Jan 14, 2023 at 1:31 PM Tom Lane wrote:
> qihua wu writes:
>
We are using patroni to set up 1 primary and 5 slaves, and using ANY 2 (*)
to commit a transaction if any 2 standbys receive the WAL. If there is a
network partitioning between the primary and the slave, then commit will
hang from user perspective, but the commit is actually done locally, just
wait
the 14*.4* package (because no
> one's crazy enough to start with 14.0 in December 2022). You'll have to
> explicitly specify the version number.
>
> On 12/26/22 03:29, qihua wu wrote:
>
> We are planning to use postgresq on production, but there is one question
> a
We are planning to use postgresq on production, but there is one question
about how to patch a db. We don't want to overwrite the old version
directly, so that we can rollback if the new version has issues. So we
want to install it a different location such as /home/postgres/14.1 for
version 14.1
Per the following link:
https://www.sobyte.net/post/2022-08/postgres-snapshot/
To get a snapshot we need to know xmin, xmax and xip. my question is why do
we need them? Since every tuple in a page has t_xmin and t_xmax based on
the page layout(
https://www.postgresql.org/docs/current/storage-page-l
12 matches
Mail list logo
