I've committed Florian's patch, but there remain a couple of things
that need work:
* Should CSV-mode logging include the virtual transaction ID (VXID) in
addition to, or instead of, XID? There will be many situations where
there is no XID.
* As things stand, when a two-phase transaction is
Tom Lane wrote:
* Should CSV-mode logging include the virtual transaction ID (VXID) in
addition to, or instead of, XID? There will be many situations where
there is no XID.
But will there be any where we care? Isn't the point of this to restrict
allocation of a real XID to situations
Tom Lane wrote:
I've committed Florian's patch, but there remain a couple of things
that need work:
* Should CSV-mode logging include the virtual transaction ID (VXID) in
addition to, or instead of, XID? There will be many situations where
there is no XID.
Maybe make %x show both, or only the
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
* Should CSV-mode logging include the virtual transaction ID (VXID) in
addition to, or instead of, XID? There will be many situations where
there is no XID.
But will there be any where we care? Isn't the point of this to restrict
Florian G. Pflug [EMAIL PROTECTED] writes:
Tom Lane wrote:
This seems fairly undesirable :-( not least because you can't tell one
prepared xact from another and thus can't see which locks belong to
each. But I'm unsure what to do about it.
We could make the VXID in the gxact struct be
