Lots of memory allocated when reassigning Large Objects

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.

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.

--