Re: Really unique session ID - PID + connection timestamp?

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Really unique session ID - PID + connection timestamp?
Дата
Msg-id 31093.1460214848@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Really unique session ID - PID + connection timestamp?  (Christoph Berg <cb@df7cb.de>)
Список 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 по дате отправления:

Предыдущее
От: Michael Nolan
Дата:
Сообщение: Re: Bypassing NULL elements in row_to_json function
Следующее
От: Tom Lane
Дата:
Сообщение: Re: max_stack_depth problem though query is substantially smaller