From: | Kasahara Tatsuhito <kasahara(dot)tatsuhito(at)gmail(dot)com> |
---|---|
To: | Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Tid scan increments value of pg_stat_all_tables.seq_scan. (but not seq_tup_read) |
Date: | 2020-02-06 10:11:46 |
Message-ID: | CAP0=ZVL5Ddc4TVa2sTXHmsO9cFp62FFCEC00ESt4G6bT+bvTpA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
HI,
On Thu, Feb 6, 2020 at 3:24 PM Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com> wrote:
> > 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
Thanks for your reply.
Hmm, it's an simple and might be the better way than adding isolation test.
I added above test case to regress/sql/tidscan.sql.
Attach the patch.
Best regards,
--
Tatsuhito Kasahara
kasahara.tatsuhito _at_ gmail.com
Attachment | Content-Type | Size |
---|---|---|
fix_tidscan_issues_v3.patch | application/octet-stream | 2.9 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Dmitry Dolgov | 2020-02-06 10:57:07 | Re: Index Skip Scan |
Previous Message | Amit Kapila | 2020-02-06 09:21:17 | Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions |