On 23/08/16 15:59, Robert Haas wrote:
> 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.
>
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
