session IDs - Mailing list pgsql-hackers

From Andrew Dunstan
Subject session IDs
Date
Msg-id 401FA98B.7020703@dunslane.net
Whole thread Raw
In response to Re: [PATCHES] log session end - again  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: session IDs
Re: session IDs
List pgsql-hackers
[note change of subject]

I wrote:

>
>
> Tom Lane wrote:
>
>> Andrew Dunstan <andrew@dunslane.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




pgsql-hackers by date:

Previous
From: Kevin Brown
Date:
Subject: Re: COPY from question
Next
From: Fabien COELHO
Date:
Subject: Re: pg_restore bug in 7.4.1 ?