Re: Assertion failure in syncrep.c

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Assertion failure in syncrep.c
Date: 2014-09-23 05:53:55
Message-ID: 20140923055355.GQ16422@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Pavan,

* Pavan Deolasee (pavan(dot)deolasee(at)gmail(dot)com) wrote:
> On Mon, Sep 22, 2014 at 6:50 PM, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> > I agree that it looks like there may be a race condition there- but
> > could you provide the test cases you're working with? What kind of
> > behavior is it that's making it show up easily for you?
> >
> Nothing special really. Set up a 2-node sync replication on my Mac laptop
> and running pgbench with 10 clients triggers it. As I said, after looking
> at the code and realising that there is a race condition, I tried with with
> gdb to reproduce the race I suspect.

Well, that's a bit concerning.

> Anyways, the attached patch should trigger the race condition for a simple
> query. I'm deliberately making backend to wait to give walsender a chance
> to send outstanding WALs and then making walsender to wait so that
> assertion is triggered in the backend.

Great, thanks, I'll try and look into this tomorrow.

Stephen

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomonari Katsumata 2014-09-23 05:56:59 Re: proposal: rounding up time value less than its unit.
Previous Message Stephen Frost 2014-09-23 05:45:06 tick buildfarm failure