session IDs

[note change of subject]

I wrote:

>
>
> Tom Lane wrote:
>
>> Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
>>
>>> I did think about using a cluster-wide sequence, if we can make such
>>> a thing (might also be useful for system generated UIDs too).
>>>
>>
>>
>> Not a good idea IMHO. If you do that, then there will be no such thing
>> as a purely read-only transaction, because *every* transaction will
>> include a nextval() call. That means even read-only transactions cannot
>> commit till the disk spins.
>>
>> If we want a unique id for transient purposes like logging, then make
>> some kind of counter in shared memory. Don't use a sequence, it's much
>> too heavyweight.
>>
>
> I'm not sure I understand. I didn't suggest that a sequence should be
> used for txn ids. For the purpose I had in mind we would call
> nextval() once per connection, and, for the other purpose where I
> suggested it would be useful, once per "create user". That doesn't
> seem very heavyweight.
>

If we really want a loggable session id then ISTM it should be not
transient at all, but in fact unique even across server restart. One
moderately simple scheme that occurred to me is to have to postmaster
keep a 64 bit counter, initialised by a call to gettimeofday(), and
bumped on every connection. The postmaster would just put the new
counter value into the port structure for the backend (and in the exec
case it would be written out and then read back by the backend, along
with the other port stuff set by postmaster). No need for a persistent
sequence or for shared memory, and it would be unique unless time went
backwards by exactly the right amount between server starts (you do run
ntp on your machines, don't you?).

I am less sure of the utility of such an ID, though. After all, if you
see a disconnect log message for a given PID you must know that any
reuse of that PID indicates a new session, or even if you just see a
connection message you know it must be a new session. OTOH, having a
unique SessionID might simplify the logic required of log analysis tools.

cheers

andrew