Re: pg_upgrade failing for 200+ million Large Objects
Andres Freund <andres@anarazel.de>
From: Andres Freund <andres@anarazel.de>
To: pgsql-hackers@lists.postgresql.org, Tom Lane <tgl@sss.pgh.pa.us>,
"Kumar, Sachin" <ssetiya@amazon.com>
Cc: Jacob Champion <champion.p@gmail.com>,
Nathan Bossart <nathandbossart@gmail.com>, Jan Wieck <jan@wi3ck.info>,
Bruce Momjian <bruce@momjian.us>, Zhihong Yu <zyu@yugabyte.com>,
Andrew Dunstan <andrew@dunslane.net>, 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: 2023-11-09T23:12:50Z
Lists: pgsql-hackers
Hi, On November 9, 2023 10:41:01 AM PST, Tom Lane <tgl@sss.pgh.pa.us> wrote: >Also, pg_upgrade is often invoked indirectly via scripts, so I do >not especially buy the idea that we're going to get useful control >input from some human somewhere. I think we'd be better off to >assume that pg_upgrade is on its own to manage the process, so that >if we need to switch strategies based on object count or whatever, >we should put in a heuristic to choose the strategy automatically. >It might not be perfect, but that will give better results for the >pretty large fraction of users who are not going to mess with >weird little switches. +1 - even leaving everything else aside, just about no user would know about the option. There are cases where we can't do better than giving the user control, but we are certainly adding options at a rate that doesn't seem sustainable. And here it doesn't seem that hard to do better. Andres -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Count individual SQL commands in pg_restore's --transaction-size mode.
- 81db073a2878 17.0 landed
- 0f1290521504 18.0 landed
-
Reduce number of commands dumpTableSchema emits for binary upgrade.
- b3f0e0503f33 18.0 landed
- 2fa989e6a340 17.0 landed
-
Invent --transaction-size option for pg_restore.
- 959b38d770ba 17.0 landed
-
Rearrange pg_dump's handling of large objects for better efficiency.
- a45c78e3284b 17.0 landed
-
Add temporal PRIMARY KEY and UNIQUE constraints
- 46a0cd4cefb4 17.0 cited
-
Fix typo and case in messages
- 7d7ef075d2b3 17.0 cited