Search Postgresql Archives

is pg_advisory_lock() suitable for long runs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi all,
it's very simple and intuitive case but let me describe first.
1. session 1 calls pg_advisory_lock(1234) and succeeds.
2. session 2 calls pg_advisory_lock(1234) and stops on waiting.
All fine BUT pid for session2 appears already with backend_xmin in pg_stat_activity
which means vacuum won't be able to remove rows younger than session2 backend_xmin.

Well, we planned to use pg_advisory_lock() as a boot phase in a hot-standby appserver
and apparently this will be problematic as the session2 might wait for weeks.

Any thoughts ? Do we miss something ?

Thanks and Regards
Radoslav Nedyalkov


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]

  Powered by Linux