Re: Out of shared memory (locks per process) using table-inheritance style partitioning - Mailing list pgsql-general

From Tom Lane
Subject Re: Out of shared memory (locks per process) using table-inheritance style partitioning
Date
Msg-id 24618.1188572840@sss.pgh.pa.us
Whole thread Raw
In response to Re: Out of shared memory (locks per process) using table-inheritance style partitioning  ("John Prevost" <j.prevost@gmail.com>)
List pgsql-general
"John Prevost" <j.prevost@gmail.com> writes:
>> So what's the problem?  Increase max_locks_per_transaction.  The reason
>> we have that as a tunable is mainly to support systems with very large
>> numbers of tables.

> So increasing this value into the thousands is a reasonable approach?
> If it is reasonable, that's fine.  I'll certainly be increasing it
> somewhat in any case.

> It just feels more than a little extreme to be tweaking a parameter
> which has the comment "32 has historically been enough" up by a factor
> of 300 or more=97extreme enough to make me wonder if there shouldn't be
> some other solution for partitioning.

Unless you expect all of your sessions to be touching all of the tables,
you probably don't need to be so extreme as that.  The parameter is a
bit misnamed, as it is not a hard limit per-session.  The total number
of locks allowed in the system is max_locks_per_transaction times
max_connections, but we don't limit any one process to any particular
fraction of that.

            regards, tom lane

pgsql-general by date:

Previous
From: Michael Glaesemann
Date:
Subject: Re: E_BAD_ACCESS with palloc/pfree in base type
Next
From: Erik Jones
Date:
Subject: Re: URGENT: Whole DB down ("no space left on device")