Re: [PATCH 08/14] Store the number of subtransactions in xl_running_xacts separately from toplevel xids

On 2012-11-15 09:07:23 -0300, Simon Riggs wrote:
> On 14 November 2012 22:17, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
>
> > To avoid complicating logic we store both, the toplevel and the subxids, in
> > ->xip, first ->xcnt toplevel ones, and then ->subxcnt subxids.
>
> That looks good, not much change. Will apply in next few days. Please
> add me as committer and mark ready.

Cool. Will do.

> > Also skip logging any subxids if the snapshot is suboverflowed, they aren't
> > useful in that case anyway.
>
> > This allows to make some operations cheaper and it allows faster startup for
> > the future logical decoding feature because that doesn't care about
> > subtransactions/suboverflow'edness.
>
> ...but please don't add extra touches of Andres magic along the way.
> Doing that will just slow down patch acceptance and its not important.
> I suggest to keep note of things like that and come back to them
> later.

Which magic are you talking about?

Only two parts changed in comparison to the previous situation. One is
that the following in ProcArrayApplyRecoveryInfo only applies to
toplevel transactions by virtue of ->xcnt now only containing the
toplevel transaction count:
> + /*
> + * Remove stale locks, if any.
> + *
> + * Locks are always assigned to the toplevel xid so we don't
> need to care
> + * about subxcnt/subxids (and by extension not about
> ->suboverflowed).
> + */
> StandbyReleaseOldLocks(running->xcnt, running->xids);

Note that there was no code change, just a change in meaning.

The other part is:
> + /*
> + * Spin over procArray collecting all subxids, but only if there hasn't
> + * been a suboverflow.
> + */
> + if (!suboverflowed)

Well, thats something that basically had to be decided either way when
writing the patch...

Greetings,

Andres

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