On 23/08/16 15:59, Robert Haas wrote:
On Mon, Aug 22, 2016 at 4:32 PM, Andres Freund <and...@anarazel.de> wrote:
On 2016-08-22 16:29:12 -0400, Robert Haas wrote:
So, I wish I could give you some better advice on this topic, but
sadly I am not an expert in this area. However, it seems to me that
this is just one facet of a much more general problem: given two
transactions T1 and T2, the order of replay must match the order of
commit unless you can prove that there are no dependencies between
them. I don't see why it matters whether the operations are sequence
operations or data operations; it's just a question of whether they're
modifying the same "stuff".
Of course, it's possible I'm missing something important here...
Maybe that normally logical decoding outputs stuff in commit order?
As slow as I sometimes am, I did know that. :-)
I think what I was missing is that nextval() operations are
non-transactional. Craig describes them as non-transactional except
when they are transactional, but I think that's not really the right
way of looking at it. Creating the sequence is transactional, and
updating the value is not. What seems to be causing trouble for Craig
is that if the nextval() operation is inserted into the replication
stream non-transactionally, it can happen before the sequence actually
gets created. I'm wondering if we can't find a way to make it so that
it's OK for those operations to happen out of order, rather than
trying to make the nextval() operation sometimes transactional and
other times non-transactional.
Well, that's what Craig is trying to do by tracking if the transactional
change has happend on a sequence in current transaction, no?
--
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
