Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
The closest thing I can think of to an automated test is to run repeated
sets of the parallel regression tests, and each time SIGTERM a randomly
chosen backend at a randomly chosen time. Then see if anything funny
Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
I think if we want pg_terminate_backend, we have to do it the
way that was originally discussed: have it issue SIGTERM and fix
whatever needs to be fixed in the SIGTERM code path.
Well, with no movement
Tom Lane wrote:
I'm willing to enable a SIGTERM-based pg_terminate_backend for 8.4
if there is some reasonable amount of testing done during this
development cycle to try to expose any problems. If no one is willing
to do any such testing, then as far as I'm concerned there is no
market for
Tom Lane [EMAIL PROTECTED] writes:
ISTM that there will be more cases like this in future, so we need a
general solution anyway. I propose the following sort of code structure
for these situations:
on_shmem_exit(cleanup_routine, arg);
PG_TRY();
{
... do
Gregory Stark [EMAIL PROTECTED] writes:
Or weakly -- an assert in CHECK_FOR_INTERRUPTS
oops, that's irrelevant of course.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's 24x7 Postgres support!
--
Sent via pgsql-hackers mailing list
Gregory Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
ISTM that there will be more cases like this in future, so we need a
general solution anyway. I propose the following sort of code structure
for these situations:
[We would also have to block SIGTERM around the
Tom Lane [EMAIL PROTECTED] writes:
[We would also have to block SIGTERM around the second cancel_shmem_exit and
cleanup_routine, no? Or if it's idempotent (actually, wouldn't it have to
be?)
run them in the reverse order.]
No, we wouldn't, because a SIGTERM can only actually fire at a
Tom Lane [EMAIL PROTECTED] writes:
Gregory Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
No, we wouldn't, because a SIGTERM can only actually fire at a
CHECK_FOR_INTERRUPTS() call. You'd just need to be sure there wasn't
one in the cleanup code.
Wait, huh? In that
Gregory Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
No, we wouldn't, because a SIGTERM can only actually fire at a
CHECK_FOR_INTERRUPTS() call. You'd just need to be sure there wasn't
one in the cleanup code.
Wait, huh? In that case I don't see what advantage any of
Gregory Stark [EMAIL PROTECTED] writes:
No, I meant the earlier patch which you rejected with the flag in MyProc. I
realize there were other issues but the initial concern was that it wouldn't
respond promptly because it would wait for CHECK_FOR_INTERRUPTS.
No, that's not the concern in the
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
I am starting to think we need to analyze the source code rather than
testing, because of what we are testing for.
I was thinking about that a bit more, in connection with trying to
verbalize why I don't like your patch ;-)
The
Magnus Hagander [EMAIL PROTECTED] writes:
Tom Lane wrote:
I'm willing to enable a SIGTERM-based pg_terminate_backend for 8.4
if there is some reasonable amount of testing done during this
development cycle to try to expose any problems.
If someone can come up with an automated script to do
Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
Tom Lane wrote:
I'm willing to enable a SIGTERM-based pg_terminate_backend for 8.4
if there is some reasonable amount of testing done during this
development cycle to try to expose any problems.
If someone can come up with an
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
The closest thing I can think of to an automated test is to run repeated
sets of the parallel regression tests, and each time SIGTERM a randomly
chosen backend at a randomly chosen time. Then see if anything funny
Yep, that was my
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
The closest thing I can think of to an automated test is to run repeated
sets of the parallel regression tests, and each time SIGTERM a randomly
chosen backend at a randomly chosen time. Then see if anything funny
Tom Lane wrote:
I wrote:
All in all, this patch wasn't ready to apply without review. I'm
currently looking to see whether it's salvageable or not.
After further study, I've concluded that it is in fact not salvageable,
and I respectfully request that it be reverted.
OK, reverted.
I
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
I was able to get things to more or less work most of the time with
three or four additional ugly hacks in postgres.c, but I still don't
have any great confidence that there aren't windows where a terminate
request wouldn't be ignored
I did a quick grep for PG_CATCH uses to see what we have along the lines
of this bug:
http://archives.postgresql.org/pgsql-hackers/2007-04/msg00218.php
In current sources there are three places at risk:
btbulkdelete, as noted in the above message
pg_start_backup needs to reset forcePageWrites =
Tom Lane wrote:
I did a quick grep for PG_CATCH uses to see what we have along the lines
of this bug:
http://archives.postgresql.org/pgsql-hackers/2007-04/msg00218.php
In current sources there are three places at risk:
btbulkdelete, as noted in the above message
pg_start_backup
Bruce Momjian [EMAIL PROTECTED] writes:
Here is a little different idea. Seems we want something more like:
Yeah, I thought about building a set of macros that would have this
ability folded in, but it didn't seem like much notational advantage
given that you have to write the cleanup routine
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Here is a little different idea. Seems we want something more like:
Yeah, I thought about building a set of macros that would have this
ability folded in, but it didn't seem like much notational advantage
given that you have to write
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
I think if we want pg_terminate_backend, we have to do it the way that
was originally discussed: have it issue SIGTERM and fix whatever needs
to be fixed in the SIGTERM code path.
Well, with no movement on this TODO item since it
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
I was able to get things to more or less work most of the time with
three or four additional ugly hacks in postgres.c, but I still don't
have any great confidence that there aren't windows where a terminate
request
Bruce Momjian [EMAIL PROTECTED] writes:
I am starting to think we need to analyze the source code rather than
testing, because of what we are testing for.
I was thinking about that a bit more, in connection with trying to
verbalize why I don't like your patch ;-)
The fundamental assumption
24 matches
Mail list logo
