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-21T18:18:59Z
Lists: pgsql-hackers
On 3/21/21 12:56 PM, Jan Wieck wrote: > On 3/21/21 7:47 AM, Andrew Dunstan wrote: >> 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> > > You mean the user is using OID columns pointing to large objects and > the JDBC driver is mapping those for streaming operations? > > Yeah, that would explain a lot. > > > Probably in most cases the database is designed by Hibernate, and the front end programmers know nothing at all of Oids or LOs, they just ask for and get a Blob. 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