Skip site navigation (1)
Skip section navigation (2)
Peripheral Links
Header And Logo
|
Site Navigation
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: Fri, 31 Aug 2007 10:42:38 -0400
- Message-id: <d849ad2a0708310742n43ab10a8p899f4a3c9e62fb7a@mail.gmail.com> <text/plain>
> 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?
- Follow-Ups:
- References:
- Prev by Date: Re: URGENT: Whole DB down ("no space left on device")
- Next by Date: Re: E_BAD_ACCESS with palloc/pfree in base type
- Previous by thread: Re: Out of shared memory (locks per process) using table-inheritance style partitioning
- Next by thread: Re: Out of shared memory (locks per process) using table-inheritance style partitioning
- Indexes: