| From: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
|---|---|
| To: | n(dot)kobzarev(at)aeronavigator(dot)ru, pgsql-general(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Unnecessary locks for partitioned tables |
| Date: | 2022-11-09 13:14:06 |
| Message-ID: | b6a944c1a7f58d2189b008ac4a523b00c1e124ab.camel@cybertec.at |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On Wed, 2022-11-09 at 14:11 +0300, n(dot)kobzarev(at)aeronavigator(dot)ru wrote:
> Recently I`ve been pushing into life a new project and immediately experienced an
> Out of shared memory error while querying partitioned tables.
>
> ERROR: out of shared memory
> Hint: You might need to increase max_locks_per_transaction.
>
> Ok, let`s increase max_locks_per_transaction, but why this type of query produces so much locks?
> Looks like DB issues locks for all the partitioned objects involved in query and ONLY AFTER THAT
> it does partition pruning.
Yes, of course. It needs an ACCESS SHARE lock when it looks at metadata
like the partition constraint, and locks are held until the end of the
transaction.
Yours,
Laurenz Albe
--
Cybertec | https://www.cybertec-postgresql.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | n.kobzarev | 2022-11-09 13:40:01 | RE: Unnecessary locks for partitioned tables |
| Previous Message | Karsten Hilbert | 2022-11-09 11:45:17 | Q: documentation improvement re collation version mismatch |