On 02/03/16 08:05, Craig Ringer wrote:
On 1 March 2016 at 05:30, Petr Jelinek <p...@2ndquadrant.com
<mailto:p...@2ndquadrant.com>> wrote:
On 29/02/16 03:23, Craig Ringer wrote:
Sound reasonable?
I wonder if it would be acceptable to create new info flag for
RM_SEQ_ID that would behave just like XLOG_SEQ_LOG but would be used
only for the nontransactional updates (nextval) so that decoding
could easily differentiate between transactional and
non-transactional update of sequence and then just either call the
callback immediately or add the change to reorder buffer based on
that. The redo code could just have simple OR expression to behave
same with both of the info flags.
That's much cleaner than trying to keep track of sequence creations and
really pretty harmless. I'll give that a go and see how it looks.
Seems like simpler solution than building all the tracking code on
the decoding side to me.
+1
Except this won't work for sequences that have been created in same
transaction as the nextval()/setval() was called because in those cases
we don't want to decode the advancement of sequence until the end of
transaction and we can't map the relfilenode to sequence without going
through reorder buffer in those cases either
--
Petr Jelinek 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