I was looking into a possible scalability problem with GIN indexes under concurrent insert, but instead I found an uncharacterized bug. One of the processes will occasionally throw an error "ERROR: buffer 10112 is not owned by resource owner Portal" where the buffer number changes from run to run.
I've verified this with both 14.9 and 16.1, on ubuntu 22.04. I use an AWS m5.4xlarge machine, and haven't tried to verify it on anything else. I don't currently have any real hardware with enough CPUs to do a meaningful test.
I've attached the "user data" file I feed to AWS to run the test, this one is for v14.9. The v16.1 is similar except I compile PostgreSQL myself (without JIT) rather than getting it from apt. I standup an ubuntu 22.04 m5.4xlarge machine with all the defaults, except changing the storage from 8GB to 80GB, and fed it the attached user data cloud init file.
If you don't want to parse the meat out of the file, the core of the test is to run this command with some escalating level of concurrency in a loop. Each call just inserts one JSONB object with highly redundant keys (the same 10 keys present in every row) but a more distinctive value for each key.
insert into j (j) select jsonb_object_agg(x::text, left(md5(random()::text),5)) from generate_series(1,10) f(x);
I've never seen the error occur until the concurrency reaches at least 4, but sample size is too low for that to be definitive.
Unless someone has some better idea, my next step will be to switch the column from jsonb to text[] and see if it exists there as well.
I assume the synchronous_commit=off is needed because without it you couldn't accumulate enough trials to spot the bug, even though it would exist in that setting. I guess I could run the test on a machine with very fast SSD and leave synchronous_commit=on, but I'm not looking forward to the cost of renting a machine that can do that or figuring out how to configure it. I also haven't tried it with fastupdate on. I assume the test would not work because the pending list would grow without bound at high concurrencies (it would grow faster than a single-threaded cleaner could clean it) and so not seeing the bug would not mean it wasn't present.
The test loops the insert for one minute, at each concurrency from 1 to 10, then starts over at -c 1 again. It seems like if you don't see the bug within the first 20 minutes (the first two 1-to-10 concurrency cycles) you are unlikely to see it at all. But that is more a hunch than a formal analysis.
Cheers,
Jeff
