Tom Lane <tgl@sss.pgh.pa.us> wrote:
> That assumption is absolutely, totally not going to fly.
Understood; I'm already working on it based on Heikki's input.
>> This needs to work when the xid of a transaction is found in the
>> MVCC data of a tuple for any overlapping serializable transaction
>> -- even if that transaction has completed and its connection has
>> been closed. It didn't look to me like
>> SubTransGetTopmostTransaction() would work after the transaction
>> was gone.
>
> Yes, it should work. If it doesn't, you are failing to manage the
> TransactionXmin horizon correctly.
So far I haven't wanted to mess with the global xmin values for fear
of the possible impact on other transactions. It actually hasn't
been that hard to maintain a SerializableGlobalXmin value, which is
more efficient than the existing ones for predicate lock cleanup
purposes. That still isn't exactly what I need to modify cleanup of
the subtransaction information, though. Once I've got my head
around the subtrans.c code, I think I'll need to maintain a minimum
that includes the xids for serializable transactions which *overlap*
SerializableGlobalXmin. That doesn't seem very hard to do; I just
haven't needed it until now. Then I'll modify the subtransaction
cleanup to only remove entries before the earlier of the global xmin
of all transactions and the xmin of serializable transactions which
overlap active serializable transactions.
Does all that sound reasonable?
-Kevin