From: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
> Since we've fixed a couple of relatively nasty bugs recently, the core
> committee has determined that it'd be a good idea to push out PG update
> releases soon. The current plan is to wrap on Monday Feb 4 for public
> announcement Thursday Feb 7. If you're aware of any bug fixes you think
> ought to get included, now's the time to get them done ...
I've just encountered another serious bug, which I wish to be fixed in the
upcoming minor release.
I'm using streaming replication with PostgreSQL 9.1.6 on Linux (RHEL6.2,
kernel 2.6.32). But this problem should happen regardless of the use of
When I ran "pg_ctl stop -mi" against the primary, some applications
connected to the primary did not stop. The cause was that the backends was
deadlocked in quickdie() with some call stack like the following. I'm sorry
to have left the stack trace file on the testing machine, so I'll show you
the precise stack trace tomorrow.
some lock function
<signal handler called because of SIGQUIT>
The root cause is that gettext() is called in the signal handler quickdie()
via errhint(). As you know, malloc() cannot be called in a signal handler:
On most systems, malloc and free are not reentrant, because they use a
static data structure which records what memory blocks are free. As a
result, no library functions that allocate or free memory are reentrant.
This includes functions that allocate space to store a result.
And gettext() calls malloc(), as reported below:
I think the solution is the typical one. That is, to just remember the
receipt of SIGQUIT by setting a global variable and call siglongjmp() in
quickdie(), and perform tasks currently done in quickdie() when sigsetjmp()
returns in PostgresMain().
What do think about the solution? Could you include the fix? If it's okay
and you want, I'll submit the patch.
In response to
pgsql-hackers by date
|Next:||From: Zoltán Böszörményi||Date: 2013-01-30 14:29:04|
|Subject: Re: Strange Windows problem, lock_timeout test request|
|Previous:||From: Andres Freund||Date: 2013-01-30 13:58:24|
|Subject: Re: autovacuum not prioritising for-wraparound tables|