From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Craig Ringer <craig(at)2ndquadrant(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Petr Jelinek <petr(dot)jelinek(at)2ndquadrant(dot)com>, Andres Freund <andres(at)anarazel(dot)de> |
Subject: | Re: Logical decoding of sequence advances, part II |
Date: | 2016-08-22 20:29:12 |
Message-ID: | CA+TgmoYAL0BOCNoPQMDNpwbLe+t8qfuwBsqJOs8uVxQu8xywcA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sun, Aug 21, 2016 at 11:13 PM, Craig Ringer <craig(at)2ndquadrant(dot)com> wrote:
> If the sequence is created in the current xact (i.e. uncommitted) we have to
> add the sequence updates to that xact to be replayed only if it commits. The
> sequence is visible only to the toplevel xact that created the sequence so
> advances of it can only come from that xact and its children. The actual
> CREATE SEQUENCE is presumed to be handled separately by an event trigger or
> similar.
>
> If the new sequence is committed we must replay sequence advances
> immediately and non-transactionally to ensure they're not lost due to xact
> rollback or replayed in the wrong order due to xact commit order.
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...
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2016-08-22 20:32:29 | Re: Logical decoding of sequence advances, part II |
Previous Message | Tom Lane | 2016-08-22 20:27:06 | Re: New SQL counter statistics view (pg_stat_sql) |