Re: Potential G2-item cycles under serializable isolation - Mailing list pgsql-bugs

From Kyle Kingsbury
Subject Re: Potential G2-item cycles under serializable isolation
Date
Msg-id 4e63a8e6-41c9-2a62-b780-2b56005d2253@jepsen.io
Whole thread Raw
In response to Re: Potential G2-item cycles under serializable isolation  (Peter Geoghegan <pg@bowt.ie>)
Responses Re: Potential G2-item cycles under serializable isolation
List pgsql-bugs
On 6/2/20 7:17 PM, Peter Geoghegan wrote:
> On Tue, Jun 2, 2020 at 10:24 AM Peter Geoghegan <pg@bowt.ie> wrote:
>> I'd be surprised if your existing test cases needed any adjustment. My
>> guess is that this won't take long.
> You said it takes about a minute in your opening e-mail; how
> consistent is this? I note from the Postgres logs you provided that
> Postgres starts accepting connections at 2020-05-31 18:50:27.580, and
> shows its last log message at  2020-05-31 18:51:29.781 PDT. So it's
> suspiciously close to *exactly* one minute.
I set the test duration to 60 seconds for those runs, but it'll break in as 
little as 10. That's less of a sure thing though. :)
>   Note that
> autovacuum_naptime has as its default '1min'. Your workload probably
> generates a lot of index bloat, which may tend to cause autovacuum to
> want to delete whole B-Tree leaf pages, which impacts predicate
> locking.
With the default (debian) postgresql.conf, which has autovacuum_naptime 
commented out (default 1min), I see anomalies at (just picking a random recent 
test) 8.16 seconds, 9.76 seconds, and 19.6 seconds.  Another run: 28.0 seconds, 
32.3 seconds.
> Could you check what happens when you reduce autovacuum_naptime to
> (say) '5s' in postgresql.conf? Does that change make the G2-item cycle
> issue manifest itself earlier? And can you discern any pattern like
> that yourself?
It doesn't look like setting autovacuum_naptime makes a difference.
> It seems kind of inconvenient to run Jepsen -- I suppose I could use
> Docker or something like that, but I don't have experience with it.
> What do you think is the simplest workflow for somebody that just
> wants to recreate your result on a Debian system?

I am really sorry about that--I know it's not convenient. Jepsen's built for 
testing whole distributed systems, and is probably a bit overkill for testing a 
single Postgres process. I don't have any experience with Docker, but I think 
Docker Compose might be a good option for a single-node system? I apologize--I 
*just* started writing this test against Debian Buster a few days ago, and the 
existing AWS Marketplace and Docker Compose environments are still on Stretch, 
so on top of setting up a Jepsen environment you also gotta do a Debian upgrade. 
:'-O

I'll see about writing a version of the test that doesn't use any of the 
automation, so you can point it at a local postgres instance. Then all you'll 
need is lein and a jdk.

--Kyle




pgsql-bugs by date:

Previous
From: Kyle Kingsbury
Date:
Subject: Re: Potential G2-item cycles under serializable isolation
Next
From: Kyle Kingsbury
Date:
Subject: Re: Potential G2-item cycles under serializable isolation