Re: Data loss on logical replication, 12.12 to 14.5, ALTER SUBSCRIPTION - Mailing list pgsql-hackers

From Michail Nikolaev
Subject Re: Data loss on logical replication, 12.12 to 14.5, ALTER SUBSCRIPTION
Date
Msg-id CANtu0oh0_e76NO7XqWkrCPXT7zWaXGM-t_cQwbygxZzZftFMig@mail.gmail.com
Whole thread Raw
In response to Re: Data loss on logical replication, 12.12 to 14.5, ALTER SUBSCRIPTION  (Amit Kapila <amit.kapila16@gmail.com>)
Responses Re: Data loss on logical replication, 12.12 to 14.5, ALTER SUBSCRIPTION
List pgsql-hackers
> Does that by any chance mean you are using a non-community version of
> Postgres which has some other changes?

It is a managed Postgres service in the general cloud. Usually, such
providers apply some custom minor patches.
The only one I know about - about forbidding of canceling queries
while waiting for synchronous replication acknowledgement.

> It is possible but ideally, in that case, the client should request
> such a transaction again.

I am not sure I get you here.

I'll try to explain what I mean:

The patch I'm referring to does not allow canceling a query while it
waiting acknowledge for ACK for COMMIT message in case of synchronous
replication.
If synchronous standby is down - query and connection just stuck until
server restart (or until standby become available to process ACK).
Tuples changed by such a hanging transaction are not visible by other
transactions. It is all done to prevent seeing spurious tuples in case
of network split.

So, it seems like we had such a situation during that story because of
our synchronous standby downtime (before server restart).
My thoughts just about the possibility of fact that such transactions
(waiting for ACK for COMMIT) are handled somehow incorrectly by
logical replication engine.

Michail.



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: 128-bit integers can range only up to (2 ^ 63 -1)
Next
From: Егор Чиндяскин
Date:
Subject: Re: Stack overflow issue