Kevin Grittner writes:
> Tom Lane wrote:
>> 3. Establish a coding rule that if you catch an error with
>> PG_TRY() and don't re-throw it, you have to unblock signals in
>> your PG_CATCH block.
> Could that be done in the PG_END_TRY macro?
Interesting idea ... [ thinks for a bit ... ] but I'm no
Tom Lane wrote:
> 3. Establish a coding rule that if you catch an error with
> PG_TRY() and don't re-throw it, you have to unblock signals in
> your PG_CATCH block.
Could that be done in the PG_END_TRY macro?
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Hi,
On 2013-11-26 18:50:28 -0500, Tom Lane wrote:
> I don't know how many platforms block signals during handlers in this way,
> but I'm seeing it on Linux (RHEL6.5 to be exact) and we know that at least
> OpenBSD acts likewise, so that's a pretty darn large chunk of the world.
Just as a datapoin
On Tue, Nov 26, 2013 at 06:50:28PM -0500, Tom Lane wrote:
> I believe the reason for this is the mechanism that I speculated about in
> that previous thread. The platform is blocking SIGALRM while it executes
> handle_sig_alarm(), and that calls LockTimeoutHandler() which does
> "kill(MyProcPid, S
Dan Wood sent me off-list the test case mentioned in
http://www.postgresql.org/message-id/CAPweHKfExEsbACRXQTBdu_4QxhHk-Cic_iwmbh5XHo_0Z=q...@mail.gmail.com
I've been poking at it, and one of the failure modes I'm seeing is that
all the backends hang up without crashing. I thought at first it wa
