On 2014-10-30 19:05:06 +0530, Amit Kapila wrote:
> On Thu, Oct 30, 2014 at 6:58 PM, Andres Freund <andres@2ndquadrant.com>
> wrote:
> > On 2014-10-30 18:54:57 +0530, Amit Kapila wrote:
> > > On Thu, Oct 30, 2014 at 5:52 PM, Andres Freund <andres@2ndquadrant.com>
> > > wrote:
> > > > Hm. What commit did you apply the series ontop? I managed to
> reproduce a
> > > > hang, but it was just something that heikki had already fixed...
> > > >
> > >
> > > commit 494affbd900d1c90de17414a575af1a085c3e37a
> > > Author: Noah Misch <noah@leadboat.com>
> > > Date: Sun Oct 12 23:33:37 2014 -0400
> > >
> > > And, I think you are saying that heikki's commit e0d97d has fixed
> > > this issue, in that case I will check once by including that fix?
> >
> > Well, the hang I was able to reproduce was originally hanging because of
> > that. I saw lot of content locks waiting as well, but the "origin" seems
> > to have a backend waiting for a xloginsert.
> >
> > The way I could trigger it quite fast was by first running a read/write
> > pgbench and then switch to a readonly one.
> >
>
> So what exactly you mean by 'switch to'?
> Is it that both read-write and readonly pgbench were running together
> or after read-write got finished and then by running read-only pgbench,
> you are able to reproduce it?
I don't think that matters all that much. In this case I first had a
read-write one (accidentally, by leaving of -S), and then aborted and
ran a readonly pgbench. That turned out to trigger it relatively fast.
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services
