SEO

Since I have a stuck backend without client again, I'll have to kill -SIGTERM a backend. Fortunately, I do
have console access to that machine and it's not win32 but a decent OS. For other cases I'd really really really
appreciate if that function would make it into 8.2.

utils/adt/misc.c says:

#*ifdef* NOT_USED

//* Disabled in 8.0 due to reliability concerns; FIXME someday *//
Datum
*pg_terminate_backend*(PG_FUNCTION_ARGS)

Well, AFAIR there were no more issues raised about code paths that don't clean up correctly, so can we please
remove that comment and make the function live finally?

Regards,
Andreas



---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

Andreas Pflug wrote:

>Since I have a stuck backend without client again, I'll have to kill -SIGTERM a backend. Fortunately, I do
>have console access to that machine and it's not win32 but a decent OS.
>
>

You do know that on Windows you can use pg_ctl to send a pseudo SIGTERM
to a backend, don't you?

cheers

andrew

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

Andreas Pflug <pgadmin@pse-consulting.de> writes:
> utils/adt/misc.c says:
> //* Disabled in 8.0 due to reliability concerns; FIXME someday *//
> Datum
> *pg_terminate_backend*(PG_FUNCTION_ARGS)

> Well, AFAIR there were no more issues raised about code paths that don't clean up correctly, so can we please
> remove that comment and make the function live finally?

No, you have that backwards. The burden of proof is on those who want
it to show that it's now safe. The situation is not different than it
was before, except that we can now actually point to a specific bug that
did exist, whereas the original concern was just an unfocused one that
the code path hadn't been adequately exercised. That concern is now
even more pressing than it was.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

Andrew Dunstan wrote:
>
>
> Andreas Pflug wrote:
>
>> Since I have a stuck backend without client again, I'll have to kill
>> -SIGTERM a backend. Fortunately, I do have console access to that
>> machine and it's not win32 but a decent OS.
>>
>>
>
> You do know that on Windows you can use pg_ctl to send a pseudo
> SIGTERM to a backend, don't you?
The main issue still is that console access id required, on any OS.

Regards,
Andreas


---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

Tom Lane wrote:
> Andreas Pflug <pgadmin@pse-consulting.de> writes:
>
>> utils/adt/misc.c says:
>> //* Disabled in 8.0 due to reliability concerns; FIXME someday *//
>> Datum
>> *pg_terminate_backend*(PG_FUNCTION_ARGS)
>>
>
>
>> Well, AFAIR there were no more issues raised about code paths that don't clean up correctly, so can we please
>> remove that comment and make the function live finally?
>>
>
> No, you have that backwards. The burden of proof is on those who want
> it to show that it's now safe. The situation is not different than it
> was before, except that we can now actually point to a specific bug that
> did exist, whereas the original concern was just an unfocused one that
> the code path hadn't been adequately exercised. That concern is now
> even more pressing than it was.
>

If the backend's stuck, I'll have to SIGTERM it, whether there's
pg_terminate_backend or not. Ultimately, if resources should remain
locked, there's no chance except restarting the whole server anyway.
SIGTERM gives me a fair chance (>90%) that it will work without restart.

The persistent refusal of supporting the function makes it more painful
to execute, but not less necessary.

Regards,
Andreas


---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

Tom Lane wrote:
> Andreas Pflug <pgadmin@pse-consulting.de> writes:
> > utils/adt/misc.c says:
> > //* Disabled in 8.0 due to reliability concerns; FIXME someday *//
> > Datum
> > *pg_terminate_backend*(PG_FUNCTION_ARGS)
>
> > Well, AFAIR there were no more issues raised about code paths that don't clean up correctly, so can we please
> > remove that comment and make the function live finally?
>
> No, you have that backwards. The burden of proof is on those who want
> it to show that it's now safe. The situation is not different than it
> was before, except that we can now actually point to a specific bug that
> did exist, whereas the original concern was just an unfocused one that
> the code path hadn't been adequately exercised. That concern is now
> even more pressing than it was.

I am not sure how you prove the non-existance of a bug. Ideas?

--
Bruce Momjian bruce@momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

Bruce Momjian <bruce@momjian.us> writes:
> Tom Lane wrote:
>> No, you have that backwards. The burden of proof is on those who want
>> it to show that it's now safe. The situation is not different than it
>> was before, except that we can now actually point to a specific bug that
>> did exist, whereas the original concern was just an unfocused one that
>> the code path hadn't been adequately exercised. That concern is now
>> even more pressing than it was.

> I am not sure how you prove the non-existance of a bug. Ideas?

What I'm looking for is some concentrated testing. The fact that some
people once in a while SIGTERM a backend doesn't give me any confidence
in it.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

> What I'm looking for is some concentrated testing. The fact that some
> people once in a while SIGTERM a backend doesn't give me any confidence
> in it.

Now wait a minute, is there some risk of lockup if I kill a backend ?
Cause I do that relatively often (say 20 times a day, when some web
users time out but their query keeps running). Should I rather not do it
?

Thanks,
Csaba.



---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Csaba Nagy <nagy@ecircle-ag.com> writes:
> Now wait a minute, is there some risk of lockup if I kill a backend ?
> Cause I do that relatively often (say 20 times a day, when some web
> users time out but their query keeps running). Should I rather not do it
> ?

statement_timeout is your friend.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

You didn't answer the original question: is killing SIGTERM a backend
known/suspected to be dangerous ? And if yes, what's the risk (pointers
to discussions would be nice too).

> statement_timeout is your friend.

I know, but unfortunately I can't use it. I did try to use
statement_timeout and it worked out quite bad (due to our usage
scenario).

Some of the web requests which time out on the web should still go
through... and we have activities which should not observe statement
timeout at all, i.e. they must finish however long that takes.

I know it would be possible to use a different user with it's own
statement timeout for those requests, but that means we have to rewrite
a lot of code which is not possible immediately, and our admins would
resist to add even more configuration (additional users=additional
connection pool+caches and all to be configured). We also can fix the
queries so no timeout happens in the first place, but that will take us
even more time.

Cheers,
Csaba.



---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org