Re: Potential G2-item cycles under serializable isolation
От | Peter Geoghegan |
---|---|
Тема | Re: Potential G2-item cycles under serializable isolation |
Дата | |
Msg-id | CAH2-Wz=cYfUSXEUJkWf=xgXdmCTCgqNRKGg1LvbiKLmRvtQTNw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Potential G2-item cycles under serializable isolation (Peter Geoghegan <pg@bowt.ie>) |
Ответы |
Re: Potential G2-item cycles under serializable isolation
|
Список | pgsql-bugs |
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. 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. 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 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? -- Peter Geoghegan
В списке pgsql-bugs по дате отправления: