On Tue, Oct 21, 2014 at 12:00 PM, Andres Freund <andres@2ndquadrant.com> wrote:
> On 2014-10-09 15:01:19 -0400, Robert Haas wrote:
>> /*
>> @@ -960,18 +966,38 @@ AtEOXact_Inval(bool isCommit)
> ...
>> + /*
>> + * We create invalidation stack entries lazily, so the parent might
>> + * not have one. Instead of creating one, moving all the data over,
>> + * and then freeing our own, we can just adjust the level of our own
>> + * entry.
>> + */
>> + if (myInfo->parent == NULL || myInfo->parent->my_level < my_level - 1)
>> + {
>> + myInfo->my_level--;
>> + return;
>> + }
>> +
>
> I think this bit might not be correct. What if the subxact one level up
> aborts? Then it'll miss dealing with these invalidation entries. Or am I
> misunderstanding something?
One of us is. I think you're asking about a situation where we have a
transaction, and a subtransaction, and within that another
subtransaction. Only the innermost subtransaction has invalidation
messages. At the innermost level, we commit; the above code makes
those messages the responsibility of the outer subtransaction. If
that subtransaction abouts, AtEOSubXact_Inval() gets called again,
sees that it has messages (that it inherited from the innermost
subtransaction), and takes the exact same code-path that it would have
pre-patch.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company