Re: Adding REPACK [concurrently] - Mailing list pgsql-hackers

From Mihail Nikalayeu
Subject Re: Adding REPACK [concurrently]
Date
Msg-id CADzfLwWQRAqi1EQrKFiTgXJsdz_3ZFAWkto97hsYb-bMcpwuwg@mail.gmail.com
Whole thread Raw
In response to Re: Adding REPACK [concurrently]  (Antonin Houska <ah@cybertec.at>)
List pgsql-hackers
Hello!

Antonin Houska <ah@cybertec.at>:
As the test runs pgbench with --client=30 and the default value of
max_worker_processes is 8, I'm not sure this is a leak. I've increased this
parameter I couldn't see the error anymore.

Hm, as far as I remember only single repack may be executed in test (because of locking on test itself and also REPACK).

At least still feel suspicious.


I agree that this is due to the missing MVCC safety feature. I commented that
check in the script for now.

I don't think so. In case of non-MVCC safety we should see 0 or correct sum. But script failed with 490588...

But should see 500500 (if I correctly calculated sum of numbers from 1 to 1000)...

Besides that, I saw some deadlocks. I think this was due to the fact that
multiple rows are updated per transaction, and that the keys are random, so it
can happen that two transactions try to update the same rows in different
order. I increased the number of rows in the test table to 10000 and don't see
the deadlocks anymore.

I think better to use min/max in updates to be sure (update lower id first).

This is tricky. I could reproduce the problem on my FreeBSD box a few times,
never on Linux (no idea if the OS makes the difference since HW is also quite
different, but CI also seemed to fail more often on FreeBSD.)

You may try to play with no_hot parameter in test - maybe it will provide some clue.

Best regards,
Mikhail.

pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Buffer locking is special (hints, checksums, AIO writes)
Next
From: Andrew Dunstan
Date:
Subject: Re: how to gate experimental features (SQL/PGQ)