Re: pg_dump out of shared memory - Mailing list pgsql-general

From Tom Lane
Subject Re: pg_dump out of shared memory
Date
Msg-id 14513.1088376044@sss.pgh.pa.us
Whole thread Raw
In response to Re: pg_dump out of shared memory  (tfo@alumni.brown.edu (Thomas F. O'Connell))
List pgsql-general
tfo@alumni.brown.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

pgsql-general by date:

Previous
From: "Jonathan Raemdonck"
Date:
Subject: indexing lat lon
Next
From: Tom Lane
Date:
Subject: Re: ERROR: tables can have at most 1600 columns