Hi,
One of our customers had a very bad issue while trying to reassign objects from user A to user B. He had a lot of them, and the backend got very hungry for memory. It finally all went down when the linux kernel decided to kill the backend (-9 of course).
I attach three shell scripts showing the issue. create.sh creates a database and two users. Then it imports a million Large Objects in this new database. There's no drop.sh as it is a simple "dropdb foodb".
session1_monitor.sh will start logging memory usage in the server log file every second. So it needs v14, but our customer is in v11. While this script runs, you can start session2_reindex.sh. This script will only run a reassign from one user to another.
Here is what I get in the server log file:
$ grep "Grand total" 14.log
LOG: Grand total: 15560832 bytes...
LOG: Grand total: 68710528 bytes...
LOG: Grand total: 119976064 bytes..
LOG: Grand total: 171626624 bytes...
LOG: Grand total: 224211072 bytes...
LOG: Grand total: 276615296 bytes...
LOG: Grand total: 325611648 bytes...
LOG: Grand total: 378196096 bytes...
LOG: Grand total: 429838464 bytes...
LOG: Grand total: 481104000 bytes...
IOW, it's asking for at least 481MB to reassign 1 million empty LO. It strikes me as odd.
FWIW, the biggest memory context is this one:
LOG: level: 2; PortalContext: 479963904 total in 58590 blocks; 2662328 free (32567 chunks); 477301576 used: <unnamed>
Memory is released at the end of the reassignment. So it's definitely not leaked forever, but only during the operation, which looks like a missing pfree (or something related). I've tried to find something like that in the code somewhere, but to no avail. I'm pretty sure I missed something, which is the reason for this email :)
Thanks.
Regards.
PS : we've found a workaround to make it work for our customer (executing all the required ALTER LARGE OBJECT ... OWNER TO ...), but I'm still amazed by this weird behaviour.