On Mon, Jun 21, 2004 at 10:28:59PM -0400, Tom Lane wrote:
> Alvaro Herrera <alvherre@dcc.uchile.cl> writes:
> > This is tricky because chunks are prepended to the queue, but it also
> > means we can stop processing as soon as a message belongs to another
> > transaction.
>
> AFAIR there isn't any essential semantics to the ordering of the queue
> entries, so you can probably get away with reordering if that makes life
> any easier.
>
> Also, rather than labeling each entry individually, it might be better
> to keep a separate list for each level of transaction. Then instead of
> relabeling, you'd just concat the subtrans list to its parent's. Seems
> like this should be faster and less storage.
Right, but it makes harder to detect when a duplicate relcache entry is
going to be inserted. Judging from the commentary in the file this is
an issue.
Another idea I had was:
1. at subtransaction start, add a special "boundary" message carrying
the new Xid.
2. at subtransaction abort, process the first chunk backwards until the
boundary message with the corresponding Xid is found; if it's not, jump
to the next and repeat.
At subtransaction commit nothing special needs to be done.
This avoids having to label each message and to change the message
appending scheme.
--
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"The eagle never lost so much time, as
when he submitted to learn of the crow." (William Blake)
