Horton
Menu

Re: pg_upgrade failing for 200+ million Large Objects

Jan Wieck <jan@wi3ck.info>

View thread
From: Jan Wieck <jan@wi3ck.info>
To: Bruce Momjian <bruce@momjian.us>
Cc: Zhihong Yu <zyu@yugabyte.com>, Andrew Dunstan <andrew@dunslane.net>, Tom Lane <tgl@sss.pgh.pa.us>, Magnus Hagander <magnus@hagander.net>, Robins Tharakan <tharakan@gmail.com>, Peter Eisentraut <peter.eisentraut@enterprisedb.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2021-03-23T18:23:03Z
Lists: pgsql-hackers 
On 3/23/21 2:06 PM, Bruce Momjian wrote:
> We have the postmaster which can pass arbitrary arguments to postgres
> processes using -o.

Right, and -o is already taken in pg_upgrade for sending options to the 
old postmaster.

What we are looking for are options for sending options to pg_dump and 
pg_restore, which are not postmasters or children of postmaster, but 
rather clients. There is no option to send options to clients of 
postmasters.

So the question remains, how do we name this?

     --pg-dump-options "<string>"
     --pg-restore-options "<string>"

where "<string>" could be something like "--whatever[=NUM] [...]" would 
be something unambiguous.


Regards, Jan

-- 
Jan Wieck
Principle Database Engineer
Amazon Web Services

Commits

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

  1. Count individual SQL commands in pg_restore's --transaction-size mode.

  2. Reduce number of commands dumpTableSchema emits for binary upgrade.

  3. Invent --transaction-size option for pg_restore.

  4. Rearrange pg_dump's handling of large objects for better efficiency.

  5. Add temporal PRIMARY KEY and UNIQUE constraints

  6. Fix typo and case in messages