Re: coverage increase for worker_spi
Alvaro Herrera <alvherre@2ndquadrant.com>
From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Pg Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2019-05-30T17:00:52Z
Lists: pgsql-hackers
On 2019-May-30, Tom Lane wrote: > Alvaro Herrera <alvherre@2ndquadrant.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
Commits
-
Increase test coverage for worker_spi by ∞%
- 4b3f1dd71b74 12.0 landed