Hello all,
I would like to thank Tom, Ian and the other pgsql wizards for their prompt
response. This must surely be open source at it's best :)
I've worked around the situation by running a small script that continually
monitors postgres and takes appropriate action if postgres shuts down. I'm
Mathijs Brands <[EMAIL PROTECTED]> writes:
> I've worked around the situation by running a small script that continually
> monitors postgres and takes appropriate action if postgres shuts down. I'm
> assuming this problem won't lead to any data corruption.
Hm. The problem here is that when the p
Ian Lance Taylor <[EMAIL PROTECTED]> writes:
> What you really want, of course, is a version of select which lets you
> atomically control the signal blocking mask.
Yeah, that would be a much cleaner solution. Someday pselect() may even
be portable enough ...
regards, to
Date: Mon, 18 Dec 2000 13:18:26 -0500
From: Tom Lane <[EMAIL PROTECTED]>
Ian Lance Taylor <[EMAIL PROTECTED]> writes:
>Any thoughts on a cleaner solution?
> One way to avoid this race condition is to set a timeout on the
> select. What is the maximum acceptable time for a
Ian Lance Taylor <[EMAIL PROTECTED]> writes:
>Any thoughts on a cleaner solution?
> One way to avoid this race condition is to set a timeout on the
> select. What is the maximum acceptable time for a timely response?
I thought about that, but it doesn't seem like a cleaner solution.
Basical
Date: Mon, 18 Dec 2000 10:41:47 -0500
From: Tom Lane <[EMAIL PROTECTED]>
[EMAIL PROTECTED] (Nathan Myers) writes:
> Sounds like a TODO list item: eliminate syscalls from signal handlers.
After looking at it some more, I think that's a lot easier said than
done. We could try wr
Ian Lance Taylor <[EMAIL PROTECTED]> writes:
> Therefore, the scenario you describe is possible, but only if there
> happens to be both a timer interrupt and a SIGCHLD signal within a
> couple of instructions after the select returns.
Right. A small failure window would explain the infrequency o
Date: Sun, 17 Dec 2000 22:47:55 -0500
From: Tom Lane <[EMAIL PROTECTED]>
BUT: I think there's a race
condition here, at least on systems where errno is not saved and
restored around a signal handler. Consider the following scenario:
Postmaster is waiting at the select(
[EMAIL PROTECTED] (Nathan Myers) writes:
> Sounds like a TODO list item: eliminate syscalls from signal handlers.
After looking at it some more, I think that's a lot easier said than
done. We could try writing the postmaster's SIGCHLD routine in the
same style currently used for SIGHUP --- ie,
On Sun, Dec 17, 2000 at 10:47:55PM -0500, Tom Lane wrote:
>
> A quick-and-dirty workaround would be to save and restore errno in
> reaper() and the other postmaster signal handlers. It might be
> a better idea in the long run to avoid doing system calls in the
> signal handlers --- but that woul
Mathijs Brands <[EMAIL PROTECTED]> writes:
> We recently installed a small server for an external party to develop
> websites on. This machine, a K6-233 with 256 MB, is running FreeBSD 3.3
> and PostgreSQL 7.0.2 (maybe I'll upgrade to 7.0.3 tonight). The database
> it's running is about 2 MB in si
11 matches
Mail list logo
