On 5 January 2017 at 20:43, Stas Kelvich <s.kelv...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
