Re: Deferring some AtStart* allocations?

On 2014-10-23 12:04:40 -0400, Robert Haas wrote:
> On Tue, Oct 21, 2014 at 12:00 PM, Andres Freund <andres(at)2ndquadrant(dot)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.

Exactly.

> 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.

Consider what happens if the innermost transaction commits and the
second innermost one rolls back. AtEOSubXact_Inval() won't do anything
because it doesn't have any entries itself. Even though there's still
valid cache inval entries containing the innermost xact's version of the
catalog, now not valid anymore.

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services