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
Show quoted text
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