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

From: "John Prevost" <j(dot)prevost(at)gmail(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Out of shared memory (locks per process) using table-inheritance style partitioning
Date: 2007-08-31 14:42:38
Message-ID: d849ad2a0708310742n43ab10a8p899f4a3c9e62fb7a@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

> 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—extreme enough to make me wonder if there shouldn't be
some other solution for partitioning.

Are there any drawbacks one should be aware of when increasing
max_locks_per_transaction to such a huge value, besides the obvious
increase in shared memory requirements?

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Michael Glaesemann 2007-08-31 14:52:56 Re: E_BAD_ACCESS with palloc/pfree in base type
Previous Message Phoenix Kiula 2007-08-31 14:34:57 Re: URGENT: Whole DB down ("no space left on device")