Re: [HACKERS] logical decoding of two-phase transactions
От | Ajin Cherian |
---|---|
Тема | Re: [HACKERS] logical decoding of two-phase transactions |
Дата | |
Msg-id | CAFPTHDa5A4CJv0Y_gZstYKyzsEyVcae1BeDEFaUYm5Daw7zPCw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] logical decoding of two-phase transactions (Amit Kapila <amit.kapila16@gmail.com>) |
Ответы |
Re: [HACKERS] logical decoding of two-phase transactions
|
Список | pgsql-hackers |
On Wed, Nov 25, 2020 at 11:54 PM Amit Kapila <amit.kapila16@gmail.com> wrote: > One problem with this patch is: What if we have assembled a consistent > snapshot after prepare and before commit prepared. In that case, it > will currently just send commit prepared record which would be a bad > idea. It should decode the entire transaction for such cases at commit > prepared time. This same problem is noticed by Arseny Sher, see > problem-2 in email [1]. I'm not sure I understand how you could assemble a consistent snapshot after prepare but before commit prepared? Doesn't a consistent snapshot require that all in-progress transactions commit? I've tried start a new subscription after a prepare on the publisher and I see that the create subscription just hangs till the transaction on the publisher is either committed or rolled back. Even if I try to create a replication slot using pg_create_logical_replication_slot when a transaction has been prepared but not yet committed , it just hangs till the transaction is committed/aborted. regards, Ajin Cherian Fujitsu Australia
В списке pgsql-hackers по дате отправления: