Re: pg_upgrade failing for 200+ million Large Objects
Laurenz Albe <laurenz.albe@cybertec.at>
From: Laurenz Albe <laurenz.albe@cybertec.at>
To: Tom Lane <tgl@sss.pgh.pa.us>, Nathan Bossart <nathandbossart@gmail.com>
Cc: vignesh C <vignesh21@gmail.com>, "Kumar, Sachin" <ssetiya@amazon.com>,
Robins Tharakan <tharakan@gmail.com>, Jan Wieck <jan@wi3ck.info>, Bruce
Momjian <bruce@momjian.us>, Andrew Dunstan <andrew@dunslane.net>, Magnus
Hagander <magnus@hagander.net>, Peter Eisentraut
<peter.eisentraut@enterprisedb.com>, "pgsql-hackers@postgresql.org"
<pgsql-hackers@postgresql.org>
Date: 2024-03-16T21:59:45Z
Lists: pgsql-hackers
On Fri, 2024-03-15 at 19:18 -0400, Tom Lane wrote: > This patch seems to have stalled out again. In hopes of getting it > over the finish line, I've done a bit more work to address the two > loose ends I felt were probably essential to deal with: Applies and builds fine. I didn't scrutinize the code, but I gave it a spin on a database with 15 million (small) large objects. I tried pg_upgrade --link with and without the patch on a debug build with the default configuration. Without the patch: Runtime: 74.5 minutes Memory usage: ~7GB Disk usage: an extra 5GB dump file + log file during the dump With the patch: Runtime: 70 minutes Memory usage: ~1GB Disk usage: an extra 0.5GB during the dump Memory usage stayed stable once it reached its peak, so no noticeable memory leaks. The reduced memory usage is great. I was surprised by the difference in disk usage: the lion's share is the dump file, and that got substantially smaller. But also the log file shrank considerably, because not every individual large object gets logged. I had a look at "perf top", and the profile looked pretty similar in both cases. The patch is a clear improvement. Yours, Laurenz Albe
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