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 anyt
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 anyt
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
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 c
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 scrip
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 ;-)
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 th
"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.
>
>
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 advan
"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 f
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 aro
"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 lis
"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();
> {
>
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
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.
> >
> > > We
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
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 termina
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 i
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
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:
> 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
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 = f
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
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
24 matches
Mail list logo
