On 2020/02/06 15:04, Kasahara Tatsuhito wrote:
Hi,
On Thu, Feb 6, 2020 at 11:48 AM Andres Freund <and...@anarazel.de> wrote:
I think it'd be good if we could guard against b) via an isolation
test. It's more painful to do that for a), due to the unreliability of
stats at the moment (we have some tests, but they take a long time).
Thanks for your advise, and agreed.
I added a new (but minimal) isolation test for the case of tid scan.
(v12 and HEAD will be failed this test. v11 and HEAD with my patch
will be passed)
Isn't this test scenario a bit overkill? We can simply test that
as follows, instead.
CREATE TABLE test_tidscan AS SELECT 1 AS id;
BEGIN ISOLATION LEVEL SERIALIZABLE;
SELECT * FROM test_tidscan WHERE ctid = '(0,1)';
SELECT locktype, mode FROM pg_locks WHERE pid = pg_backend_pid() AND mode =
'SIReadLock';
COMMIT;
In the expected file, the result of query looking at pg_locks
should be matched with the following.
locktype | mode
----------+------------
tuple | SIReadLock
BTW, in master branch, locktype in that query result is "relation"
because of the issue.
Regards,
--
Fujii Masao
NTT DATA CORPORATION
Advanced Platform Technology Group
Research and Development Headquarters
