Re: [HACKERS] logical decoding of two-phase transactions
От | Craig Ringer |
---|---|
Тема | Re: [HACKERS] logical decoding of two-phase transactions |
Дата | |
Msg-id | CAMsr+YG2DmNBVs1fnwcD_=sQDC=DAQq=0fqNwZ594_2Tv8-GqA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] logical decoding of two-phase transactions (Stas Kelvich <s.kelvich@postgrespro.ru>) |
Список | pgsql-hackers |
On 5 January 2017 at 20:43, Stas Kelvich <s.kelvich@postgrespro.ru> wrote: > Anyway, I can measure WAL space overhead introduced by the GID’s inside commit records > to know exactly what will be the cost of such approach. Sounds like a good idea, especially if you remove any attempt to work with GIDs for !2PC commits at the same time. I don't think I care about having access to the GID for the use case I have in mind, since we'd actually be wanting to hijack a normal COMMIT and internally transform it to PREPARE TRANSACTION, <do stuff>, COMMIT PREPARED. But for the more general case of logical decoding of 2PC I can see the utility of having the xact identifier. If we presume we're only interested in logically decoding 2PC xacts that are not yet COMMIT PREPAREd, can we not avoid the WAL overhead of writing the GID by looking it up in our shmem state at decoding-time for PREPARE TRANSACTION? If we can't find the prepared transaction in TwoPhaseState we know to expect a following ROLLBACK PREPARED or COMMIT PREPARED, so we shouldn't decode it at the PREPARE TRANSACTION stage. -- Craig Ringer http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: