From: | Kyle Kingsbury <aphyr(at)jepsen(dot)io> |
---|---|
To: | Peter Geoghegan <pg(at)bowt(dot)ie> |
Cc: | PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Potential G2-item cycles under serializable isolation |
Date: | 2020-06-03 14:20:22 |
Message-ID: | 4e63a8e6-41c9-2a62-b780-2b56005d2253@jepsen.io |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On 6/2/20 7:17 PM, Peter Geoghegan wrote:
> On Tue, Jun 2, 2020 at 10:24 AM Peter Geoghegan <pg(at)bowt(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Kyle Kingsbury | 2020-06-03 14:22:30 | Re: Potential G2-item cycles under serializable isolation |
Previous Message | Kyle Kingsbury | 2020-06-03 12:48:56 | Re: Potential G2-item cycles under serializable isolation |