From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Pg Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: coverage increase for worker_spi |
Date: | 2019-05-30 17:00:52 |
Message-ID: | 20190530170052.GA20298@alvherre.pgsql |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2019-May-30, Tom Lane wrote:
> Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> writes:
> > On 2019-May-29, Tom Lane wrote:
> >> I'm not opposed to adding a new test case at this point in the cycle,
> >> but as written this one seems more or less guaranteed to fail under
> >> load.
>
> > True. Here's a version that should be more resilient.
>
> Hm, I don't understand how this works at all:
>
> + PERFORM pg_sleep(CASE WHEN count(*) = 0 THEN 0 ELSE 0.1 END)
> + FROM schema1.counted WHERE type = 'delta';
> + GET DIAGNOSTICS count = ROW_COUNT;
>
> Given that it uses an aggregate, the ROW_COUNT must always be 1, no?
Well, I was surprised to see the count(*) work there as an argument for
pg_sleep there at all frankly (maybe we are sleeping 0.1s more than we
really need, per your observation), but the row_count is concerned with
rows that have type = 'delta', which are deleted by the bgworker. So
the test script job is done when the bgworker has run once through its
loop.
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | David Fetter | 2019-05-30 17:24:31 | Re: New committer: David Rowley |
Previous Message | Tom Lane | 2019-05-30 16:51:27 | Re: coverage increase for worker_spi |