Re: Potential G2-item cycles under serializable isolation
От | Kyle Kingsbury |
---|---|
Тема | Re: Potential G2-item cycles under serializable isolation |
Дата | |
Msg-id | 4e63a8e6-41c9-2a62-b780-2b56005d2253@jepsen.io обсуждение исходный текст |
Ответ на | Re: Potential G2-item cycles under serializable isolation (Peter Geoghegan <pg@bowt.ie>) |
Ответы |
Re: Potential G2-item cycles under serializable isolation
|
Список | 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 по дате отправления: