| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Viral Shah <viralshah009(at)gmail(dot)com> |
| Cc: | Rene Romero Benavides <rene(dot)romero(dot)b(at)gmail(dot)com>, pgsql-sql(at)postgresql(dot)org |
| Subject: | Re: pg_dump fails when a table is in ACCESS SHARE MODE |
| Date: | 2020-05-01 14:18:08 |
| Message-ID: | 17875.1588342688@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-sql |
Viral Shah <viralshah009(at)gmail(dot)com> writes:
> Per the postgres documentation,
> *max_locks_per_transaction * (max_connections + max_prepared_transactions)*
> this formula determines the max no of allowed objects that can be locked on
> the database. Currently my database has the following values:
> *max_locks_per_transaction = 64 (default)*
> *max_connections = 100*
> *max_prepared_transactions = 0*
> Using this value in the above formula tells that our database or rather
> postgres server can/should handle *6400* locked objects at a time.
Right.
> What is surprising is why Postgres complains of insufficient locks per
> transaction if only 10 processes (parallel jobs in pg_dump) are running on
> the database while taking the dump.
They're taking more than 6400 locks, evidently. How many tables are
in your database? Have you tried looking into pg_locks while the dump
is running?
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Viral Shah | 2020-05-02 01:06:23 | Re: pg_dump fails when a table is in ACCESS SHARE MODE |
| Previous Message | Viral Shah | 2020-05-01 13:53:58 | Re: pg_dump fails when a table is in ACCESS SHARE MODE |