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. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers