Re: pg_dump out of shared memory

tfo(at)alumni(dot)brown(dot)edu (Thomas F. O'Connell) writes:
> Now I'm curious: why does pg_dump require that
> max_connections * max_shared_locks_per_transaction be greater than the
> number of objects in the database?

Not objects, just tables. pg_dump takes AccessShareLock (the weakest
kind of lock) on each table it intends to dump. This is basically
just to prevent someone from dropping the table underneath it. (It
would actually have to take that lock anyway as a byproduct of reading
the table contents, but we grab the locks ASAP during pg_dump startup
to reduce the risks of problems from concurrent drops.)

On a database with thousands of tables, this could easily require more
locks than the default lock table size can hold. Most normal apps don't
need more than a few tables locked within any one transaction, which is
why the table size is calculated as a multiple of max_connections.
There's a great deal of slop involved, because we pad the shared memory
size by 100K or so which is room for quite a few more lock entries than
the nominal table size ... but eventually you'll run out of room.

regards, tom lane