Re: Logical decoding of sequence advances, part II

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