Home > mailing lists

is pg_advisory_lock() suitable for long runs - Mailing list pgsql-general

From	Radoslav Nedyalkov
Subject	is pg_advisory_lock() suitable for long runs
Date	April 1, 2018 00:49:32
Msg-id	CANhtRiYa7ooqvqg9Ogqad=RWn3n-+U7wLjEEKWwQwMSV4W9_VA@mail.gmail.com Whole thread Raw
Responses	Re: is pg_advisory_lock() suitable for long runs (Merlin Moncure <mmoncure@gmail.com>)
List	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

From: Melvin Davidson
Date: 31 March 2018, 22:00:37
Subject: Re: Problem with connection to host (wrong host)

From: pinker
Date: 01 April 2018, 05:40:43
Subject: unreliable behaviour of track_functions