Re: Potential G2-item cycles under serializable isolation
Kyle Kingsbury <aphyr@jepsen.io>
From: Kyle Kingsbury <aphyr@jepsen.io>
To: Peter Geoghegan <pg@bowt.ie>
Cc: PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
Date: 2020-06-03T14:20:22Z
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@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
Commits
-
Doc: Add references for SI and SSI.
- 4c897197d793 9.5.23 landed
- 7295ac9c6c71 9.6.19 landed
- e2aca0d02d97 10.14 landed
- 648e56d3984d 11.9 landed
- eb1286413c0a 12.4 landed
- 4701efa9f741 13.0 landed
- 1575fbf1ac3c 14.0 landed
-
Improve comments for [Heap]CheckForSerializableConflictOut().
- 44eff2841059 13.0 landed
- 7aa4fb592530 14.0 landed
-
Avoid update conflict out serialization anomalies.
- 5940ffb22131 14.0 landed
- 6df7105e5d50 13.0 landed
- e620a38c23b9 12.4 landed
- dd616f2ec1c5 11.9 landed
- 19a6e1bc3083 10.14 landed
- e81dc2b7e2c4 9.6.19 landed
- c05f6b354ffe 9.5.23 landed
-
Implement genuine serializable isolation level.
- dafaa3efb75c 9.1.0 cited