Re: hung backends stuck in spinlock heavy endless loop

From: Merlin Moncure <mmoncure(at)gmail(dot)com>
To: Andres Freund <andres(at)2ndquadrant(dot)com>
Cc: Peter Geoghegan <pg(at)heroku(dot)com>, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: hung backends stuck in spinlock heavy endless loop
Date: 2015-01-16 14:38:56
Message-ID: CAHyXU0zGd9ViLq85524ho8jOxO3oUYtF3ZKQZ6YT4SndMsa7hw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Jan 16, 2015 at 8:22 AM, Andres Freund <andres(at)2ndquadrant(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2015-01-16 14:56:37 Re: Safe memory allocation functions
Previous Message Andres Freund 2015-01-16 14:22:27 Re: hung backends stuck in spinlock heavy endless loop