Re: Lazy xid assignment V3

Heikki Linnakangas wrote:
> Tom Lane wrote:
>> "Florian G. Pflug" <fgp(at)phlo(dot)org> writes:
>>> Tom Lane wrote:
>>>> "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com> writes:
>>>>> Should there be new a log_line_prefix percent code for virtual
>>>>> transaction ids? Or should we change the meaning of %x to be virtual
>>>>> transaction id instead of the real one.
>>>> I think the latter should be sufficient, especially if we also are showing
>>>> vxid in pg_locks and pg_stat_activity.
>>> Hm.. Wouldn't that kind of defeat the idea of a log, if you need the
>>> output of pg_locks to interpret it? Maybe we should just show both
>>> values for %x? Or just the xid if it's set, and the vid otherwise?
>> Well, how do you interpret xid in the log today, if not by reference
>> to those views? The last option seems quite unworkable, especially
>> for CSV-based logs.
>
> I don't think people usually interpret the xid in logs in any way. It's
> just a handy unique (unique enough, ignoring xid wraparound) identifier
> for the transaction that you can use to figure out what each separate
> transaction is doing. For that purpose, it doesn't matter if it doesn't
> match the normal on-disk xid, using vid instead of xid works just fine.
>
> Hmm. Or is it unique enough after all? Do we reuse session ids after a
> server restart?
Yes - the sessionIs is just a counter in shared memory, so we start "1"
after a restart again.

> For debugging PostgreSQL bugs, though, having the real xid in the logs
> is really nice. You can then compare the logs against the tuples on the
> disk.
I take this as a vote for having both "%x" and "%v" for xid and virtual xid
respectively.

greetings, Florian Pflug