is pg_advisory_lock() suitable for long runs

From: Radoslav Nedyalkov <rnedyalkov(at)gmail(dot)com>
To: pgsql-general(at)postgresql(dot)org
Subject: is pg_advisory_lock() suitable for long runs
Date: 2018-03-31 18:49:32
Message-ID: CANhtRiYa7ooqvqg9Ogqad=RWn3n-+U7wLjEEKWwQwMSV4W9_VA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

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

Responses

Browse pgsql-general by date

  From Date Subject
Next Message pinker 2018-03-31 23:40:43 unreliable behaviour of track_functions
Previous Message Melvin Davidson 2018-03-31 16:00:37 Re: Problem with connection to host (wrong host)