Thread: Unique Session ID in PGSQL?
Hi! Is there any function in PGSQL that returns an unique Session identifier of the actual session? For example a Bigint, or GUID, or etc? Can I get the living Session identifiers from PG? We have a little application that uses these infos which are basically came from another database system, and I will port this, but I don't know, how to do in PGSQL... In this app. we associated (stored) the session id to a special field in some tables. We can retreive the living session ids with a system functions. If a session died, these records have become irrelevant - we can delete them. If the session still alive, we don't touch them, only can read the content... I see adv_locks in pg, but because the quantity of locks are pre-determined by the server, I don't choose them. I better like a technic that cannot exhaust the number of persistent elements. Thanks: dd
Hello
2011/5/18 Durumdara <durumdara@gmail.com>:
> Hi!
>
> Is there any function in PGSQL that returns an unique Session
> identifier of the actual session?
> For example a Bigint, or GUID, or etc?
> Can I get the living Session identifiers from PG?
try
postgres=# select pg_backend_pid();
pg_backend_pid
----------------
17327
(1 row)
postgres=# \x
Expanded display is on.
postgres=# select * from pg_stat_activity where procpid = pg_backend_pid();
-[ RECORD 1 ]----+-----------------------------------------------------------------
datid | 12835
datname | postgres
procpid | 17327
usesysid | 16384
usename | pavel
application_name | psql
client_addr |
client_hostname |
client_port | -1
backend_start | 2011-05-18 14:46:08.099399+02
xact_start | 2011-05-18 15:08:21.5958+02
query_start | 2011-05-18 15:08:21.5958+02
waiting | f
current_query | select * from pg_stat_activity where procpid =
pg_backend_pid();
Regards
Pavel Stehule
>
> We have a little application that uses these infos which are basically
> came from another database system, and I will port this, but I don't
> know, how to do in PGSQL...
> In this app. we associated (stored) the session id to a special field
> in some tables.
> We can retreive the living session ids with a system functions.
>
> If a session died, these records have become irrelevant - we can
> delete them. If the session still alive, we don't touch them, only can
> read the content...
>
> I see adv_locks in pg, but because the quantity of locks are
> pre-determined by the server, I don't choose them.
> I better like a technic that cannot exhaust the number of persistent elements.
>
> Thanks:
> dd
>
> --
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
>
Pavel Stehule wrote: >> Is there any function in PGSQL that returns an unique Session >> identifier of the actual session? >> For example a Bigint, or GUID, or etc? >> Can I get the living Session identifiers from PG? > > try > > postgres=# select pg_backend_pid(); > pg_backend_pid > ---------------- > 17327 > (1 row) I don't totally understand the intended use, but process IDs have the problem that they will get reused eventually. So if that's not good enough, you can construct a session ID like %c in log_line_prefix with the query found in the documentation: http://www.postgresql.org/docs/current/static/runtime-config-logging.html#GUC-LOG-LINE-PREFIX Yours, Laurenz Albe
On Thu, May 19, 2011 at 4:21 AM, Albe Laurenz <laurenz.albe@wien.gv.at> wrote: > Pavel Stehule wrote: >>> Is there any function in PGSQL that returns an unique Session >>> identifier of the actual session? >>> For example a Bigint, or GUID, or etc? >>> Can I get the living Session identifiers from PG? >> >> try >> >> postgres=# select pg_backend_pid(); >> pg_backend_pid >> ---------------- >> 17327 >> (1 row) > > I don't totally understand the intended use, but process IDs have the > problem that they will get reused eventually. > > So if that's not good enough, you can construct a session ID like > %c in log_line_prefix with the query found in the documentation: no, but pid + backend_start_time *is* enough -- the backend session is generated directly from them. I personally wouldn't use the hex version -- pointless obfuscation -- I would just maintain pid+start time as the session if I wasn't worried about the session being guessed, and a salted digest of those two values if I was. merlin