Re: Lazy xid assignment V3

Tom Lane wrote:
> "Florian G. Pflug" <fgp@phlo.org> writes:
>> Tom Lane wrote:
>>> "Heikki Linnakangas" <heikki@enterprisedb.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.
Someone might match the xid with xids found on disk. If we replace the
xid with the vid, than this is impossible unless you also periodically
snapshot pg_locks.

> I suppose there's no great harm in providing %v as an additional
> prefix format code ...
Ok, I'll do this. Shouldn't be too hard, it seems...

>> BTW, my current patch doesn't show the vid in pg_stat_activity.
>
> Hmm, actually it looks like the join key for that is supposed to be PID,
> so maybe we needn't do anything to it.
Yes, that was my reasoning too. Maybe we want to add both xid and vid
to pg_stat_activity one day, but since this patch might hit 8.3, lets
keep it as minimal as possible...

>> Even in the case of a conflict, two transactions still wouldn't be
>> running with the same vid. Rather, the second one would block until
>> the first exits, because we hold an ExclusiveLock on the vid.
>
> It's definitely sufficient then ...
This implies that connecting and the immediately starting a transaction
(which will then get "1" as it's localTransactionId) which you keep
open *will* block some other transaction after 4 billion other connects.

I'm not saying that this is unacceptable, I just wanted to clearly state
the consequences.

greetings, Florian Pflug