Re: Large objects and out-of-memory
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Konstantin Knizhnik <k.knizhnik@postgrespro.ru>
Cc: pgsql-bugs@lists.postgresql.org
Date: 2020-12-21T18:27:25Z
Lists: pgsql-bugs
Konstantin Knizhnik <k.knizhnik@postgrespro.ru> writes: > The following sequence of command cause backend's memory to exceed 10Gb: > INSERT INTO image1 SELECT lo_creat(-1) FROM generate_series(1,10000000); > REASSIGN OWNED BY alice TO testlo; [ shrug... ] You're asking to change the ownership of 10000000 objects. This is not going to be a cheap operation. AFAIK it's not going to be any more expensive than changing the ownership of 10000000 tables, or any other kind of object. The argument for allowing large objects to have per-object ownership and permissions in the first place was that useful scenarios wouldn't have a huge number of them (else you'd run out of disk space, if they're actually "large"), so we needn't worry too much about the overhead. We could possibly bound the amount of space used in the inval queue by switching to an "invalidate all" approach once we got to an unreasonable amount of space. But this will do nothing for the other costs involved, and I'm not really sure it's worth adding complexity for. regards, tom lane
Commits
-
Fix inconsistent code with shared invalidations of snapshots
- 8fcc2fb98064 9.5.25 landed
- 7bf20c1b8a14 9.6.21 landed
- 1c7ca6178963 10.16 landed
- 6819380dd265 11.11 landed
- 190f0af0d127 12.6 landed
- 30803bd1cd6c 13.2 landed
- 643428c54b95 14.0 landed