| From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
|---|---|
| To: | Kyle Kingsbury <aphyr(at)jepsen(dot)io> |
| Cc: | PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Potential G2-item cycles under serializable isolation |
| Date: | 2020-06-02 23:17:42 |
| Message-ID: | CAH2-Wz=cYfUSXEUJkWf=xgXdmCTCgqNRKGg1LvbiKLmRvtQTNw@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
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. 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Brajendra Pratap Singh | 2020-06-02 23:31:12 | Re: BUG #16473: Marked as broken because of SQLSTATE(08006),ErrorCode(0) |
| Previous Message | Thomas Munro | 2020-06-02 23:13:02 | Re: Potential G2-item cycles under serializable isolation |