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.

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?

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.

>> 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 ...

Yeah. If we did want to do something more, we could acquire the lock on
vid conditionally, and use another vid if acquiring the lock fails. But
I don't think it's necessary.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate

Heikki Linnakangas wrote:
> 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.
>
> 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

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

"Heikki Linnakangas" <heikki@enterprisedb.com> writes:
> Yeah. If we did want to do something more, we could acquire the lock on
> vid conditionally, and use another vid if acquiring the lock fails. But
> I don't think it's necessary.

I was thinking more along the lines of looking through the ProcArray at
backend startup to ensure the sessionID we've chosen is unique, and
choosing another one if not. But this would expend cycles with the
ProcArray locked, for something that seems exceedingly unlikely to
happen,

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend