Re: Really unique session ID - PID + connection timestamp? - Mailing list pgsql-general

From Tom Lane
Subject Re: Really unique session ID - PID + connection timestamp?
Date
Msg-id 31093.1460214848@sss.pgh.pa.us
Whole thread Raw
In response to Re: Really unique session ID - PID + connection timestamp?  (Christoph Berg <cb@df7cb.de>)
List pgsql-general
Christoph Berg <cb@df7cb.de> writes:
> I don't see how log_line_prefix() would make sense, but
> pg_session_identifier() (= %c) would make sense to have, in the same
> way that we have pg_backend_pid(), so the current session could be
> located in the logs. (Not sure if pg_session_identifier shouldn't also
> be a pg_stat_activity column, but that might be overkill. Maybe
> SELECT pg_session_identifier(pid) from pg_stat_activity; ?)

I do not think we should get into the business of providing something
called a "unique session identifier" when in fact there is no uniqueness
guarantee.  timestamp + PID might be close enough for some uses, but it
won't be unique across multiple servers.  It has hazards if the server's
clock goes backwards.  It has hazards due to limited precision of the
timestamp (who's to say the OS wouldn't reissue the same PID within one
second?).

You can get your PID and session start time already from pg_stat_activity,
as Stephen pointed out; and what's more that technique works today on
all supported branches.  If you want something a bit notationally cleaner
you can wrap it up in a user-defined function to produce a session ID.

I think we should just leave things as they are; people for whom
timestamp + PID is good enough as a session ID already have a solution,
and we should not mislead those for whom it isn't.

            regards, tom lane


pgsql-general by date:

Previous
From: Michael Nolan
Date:
Subject: Re: Bypassing NULL elements in row_to_json function
Next
From: Tom Lane
Date:
Subject: Re: max_stack_depth problem though query is substantially smaller