|
For many things “0” is “disabled” So there is no timeout, it will wait forever. From: pgsql-admin-owner@xxxxxxxxxxxxxx [mailto:pgsql-admin-owner@xxxxxxxxxxxxxx]
On Behalf Of Porwal, Utkarsh 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@xxxxxxxxx]
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. Cheers. On 24 September 2015 at 17:37, Porwal, Utkarsh <utkarsh.porwal@xxxxxxx> wrote: The postgres version is –
psql (9.0.7) From:
pgsql-admin-owner@xxxxxxxxxxxxxx [mailto:pgsql-admin-owner@xxxxxxxxxxxxxx]
On Behalf Of Porwal, Utkarsh 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
-- Regards, |
