Horton

Re: pg_dump and thousands of schemas

Jeff Janes <jeff.janes@gmail.com>

View thread
From: Jeff Janes <jeff.janes@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Bruce Momjian <bruce@momjian.us>, Craig James <cjames@emolecules.com>, Hugo <hugo.tech@gmail.com>, pgsql-performance@postgresql.org
Date: 2012-05-25T17:41:19Z
Lists: pgsql-hackers, pgsql-performance

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Teach AbortOutOfAnyTransaction to clean up partially-started transactions.

On Fri, May 25, 2012 at 9:56 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Jeff Janes <jeff.janes@gmail.com> writes:
>
>> For dumping entire databases, It looks like the biggest problem is
>> going to be LockReassignCurrentOwner in the server.  And that doesn't
>> seem to be easy to fix, as any change to it to improve pg_dump will
>> risk degrading normal use cases.
>
> I didn't try profiling the server side, but pg_dump doesn't use
> subtransactions so it's not clear to me why LockReassignCurrentOwner
> would get called at all ...

I thought that every select statement in a repeatable read transaction
ran in a separate "portal", and that a portal is a flavor of
subtransaction.  Anyway, it does show up at the top of a profile of
the server, so it is getting called somehow.

Cheers,

Jeff