Re: pg_upgrade failing for 200+ million Large Objects
Andrew Dunstan <andrew@dunslane.net>
From: Andrew Dunstan <andrew@dunslane.net>
To: Jan Wieck <jan@wi3ck.info>, Tom Lane <tgl@sss.pgh.pa.us>
Cc: 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-21T11:47:12Z
Lists: pgsql-hackers
On 3/20/21 12:55 PM, Jan Wieck wrote: > On 3/20/21 11:23 AM, Tom Lane wrote: >> Jan Wieck <jan@wi3ck.info> writes: >>> All that aside, the entire approach doesn't scale. >> >> Yeah, agreed. When we gave large objects individual ownership and ACL >> info, it was argued that pg_dump could afford to treat each one as a >> separate TOC entry because "you wouldn't have that many of them, if >> they're large". The limits of that approach were obvious even at the >> time, and I think now we're starting to see people for whom it really >> doesn't work. > > It actually looks more like some users have millions of "small > objects". I am still wondering where that is coming from and why they > are abusing LOs in that way, but that is more out of curiosity. Fact > is that they are out there and that they cannot upgrade from their 9.5 > databases, which are now past EOL. > One possible (probable?) source is the JDBC driver, which currently treats all Blobs (and Clobs, for that matter) as LOs. I'm working on improving that some: <https://github.com/pgjdbc/pgjdbc/pull/2093> cheers andrew -- Andrew Dunstan EDB: https://www.enterprisedb.com
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