Re: hung backends stuck in spinlock heavy endless loop - Mailing list pgsql-hackers

From Merlin Moncure
Subject Re: hung backends stuck in spinlock heavy endless loop
Date
Msg-id CAHyXU0zGd9ViLq85524ho8jOxO3oUYtF3ZKQZ6YT4SndMsa7hw@mail.gmail.com
Whole thread Raw
In response to Re: hung backends stuck in spinlock heavy endless loop  (Andres Freund <andres@2ndquadrant.com>)
List pgsql-hackers
On Fri, Jan 16, 2015 at 8:22 AM, Andres Freund <andres@2ndquadrant.com> wrote:
> Is there any chance you can package this somehow so that others can run
> it locally? It looks hard to find the actual bug here without adding
> instrumentation to to postgres.

That's possible but involves a lot of complexity in the setup because
of the source database (SQL Server) dependency..

Thinking outside the box here I'm going to migrate the source to
postgres.   This will rule out pl/sh which is the only non-core
dependency but will take some setup work on my end first.  If I can
still reproduce the error at that point, maybe we can go in this
direction, and it it would make local reproduction easier anyways.

>> [cds2 21952 2015-01-15 22:54:51.833 CST 5502]WARNING:  page
>
> This was the first error? None of the 'could not find subXID' errors
> beforehand?

yep.  no caught exceptions or anything interesting in the log before that.

> Could you add a EmitErrorReport(); before the FlushErrorState() in
> pl_exec.c's exec_stmt_block()?

will do.

merlin



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: hung backends stuck in spinlock heavy endless loop
Next
From: Robert Haas
Date:
Subject: Re: Safe memory allocation functions