On Mon, Aug 22, 2016 at 4:32 PM, Andres Freund <andres@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
