For many things “0” is “disabled”
So there is no timeout, it will wait forever.
From: pgsql-admin-owner@postgresql.org [mailto:pgsql-admin-owner@postgresql.org] On Behalf Of Porwal, Utkarsh
Sent: September 24, 2015 12:37 PM
To: Wei Shan
Cc: pgsql-admin@postgresql.org
Subject: Re: [ADMIN] Query on Postgres locks
Hi Wei shan,
For me the statement_timeout is defaulted to zero
statement_timeout | 0 | ms
Thanks and Regards,
Utkarsh Porwal
From: Wei Shan [mailto:weishan.ang@gmail.com]
Sent: Thursday, September 24, 2015 3:49 PM
To: Porwal, Utkarsh
Cc: pgsql-admin@postgresql.org
Subject: Re: [ADMIN] Query on Postgres locks
Hi,
If you look at pg_settings table, you can see the default value for statement_timeout. Only from 9.3, there's a parameter called lock_timeout.
On 24 September 2015 at 17:37, Porwal, Utkarsh <utkarsh.porwal@emc.com> wrote:
The postgres version is –
psql (9.0.7)
Dear All,
I have a perl script which will attempt to drop/recreate some intermediate tables. This works by trying to acquire an access exclusive lock on the intermediate tables.
When there is a backup running through pg_dump, I see an entry in pg_locks/pg_stat_activity table for the above which is waiting for pg_dump to finish, which is expected.
Since backup on huge environment takes around 8 hrs to complete, I noticed that the entries waiting for locks are removed after certain amount of time which I couldn’t record even though the perl script is still running.
Do you guys know if the lock waiting will ultimately timeout and when? I don’t have any statement_timeout specified.
Any pointers on this behavior?
Regards,
Utkarsh
--