On Fri, 23 Jun 2017 19:43:35 -0400
Stephen Frost wrote:
> Alvaro, all,
>
> * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> > Yugo Nagata wrote:
> >
> > > I tried to make it. Patch attached.
> > >
> > > It is easy and simple. Although I haven't tried for autovacuum worker,
> > > I confirm
On Sat, 24 Jun 2017 08:09:52 +0900
Michael Paquier wrote:
> On Sat, Jun 24, 2017 at 5:07 AM, Alvaro Herrera
> wrote:
> > Yugo Nagata wrote:
> >
> >> I tried to make it. Patch attached.
> >>
> >> It is easy and simple. Although I haven't tried for autovacuum worker,
> >> I confirmed I can change
Alvaro, all,
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> Yugo Nagata wrote:
>
> > I tried to make it. Patch attached.
> >
> > It is easy and simple. Although I haven't tried for autovacuum worker,
> > I confirmed I can change other process' parameters without affecting others.
> > Do y
On Sat, Jun 24, 2017 at 5:07 AM, Alvaro Herrera
wrote:
> Yugo Nagata wrote:
>
>> I tried to make it. Patch attached.
>>
>> It is easy and simple. Although I haven't tried for autovacuum worker,
>> I confirmed I can change other process' parameters without affecting others.
>> Do you want this in P
Yugo Nagata wrote:
> I tried to make it. Patch attached.
>
> It is easy and simple. Although I haven't tried for autovacuum worker,
> I confirmed I can change other process' parameters without affecting others.
> Do you want this in PG?
One advantage of this gadget is that you can signal backen
On Thu, 22 Jun 2017 14:08:30 +0900
Michael Paquier wrote:
> On Thu, Jun 22, 2017 at 1:52 PM, Yugo Nagata wrote:
> > On Thu, 22 Jun 2017 12:05:19 +0900
> > Michael Paquier wrote:
> >> signal-able). Different thought, but I'd love to see a SQL function
> >> that allows triggering SIGHUP on a spec
On Thu, Jun 22, 2017 at 1:52 PM, Yugo Nagata wrote:
> On Thu, 22 Jun 2017 12:05:19 +0900
> Michael Paquier wrote:
>> signal-able). Different thought, but I'd love to see a SQL function
>> that allows triggering SIGHUP on a specific process, like an
>> autovacuum worker to change its cost paramete
On Thu, 22 Jun 2017 12:05:19 +0900
Michael Paquier wrote:
> On Thu, Jun 22, 2017 at 11:52 AM, Andres Freund wrote:
> > On 2017-06-22 11:49:47 +0900, Yugo Nagata wrote:
> >> I agree that we can kill theses processes by the OS command. However,
> >> It seems to me that pg_{cancel,terminate}_backen
On Thu, Jun 22, 2017 at 11:52 AM, Andres Freund wrote:
> On 2017-06-22 11:49:47 +0900, Yugo Nagata wrote:
>> I agree that we can kill theses processes by the OS command. However,
>> It seems to me that pg_{cancel,terminate}_backend don't need to be able to
>> kill processes except for client backe
On 2017-06-22 11:49:47 +0900, Yugo Nagata wrote:
> On Wed, 21 Jun 2017 11:04:34 -0400
> Robert Haas wrote:
>
> > On Wed, Jun 21, 2017 at 7:56 AM, Yugo Nagata wrote:
> > > I have found that we can cancel/terminate autovacuum launchers and
> > > background worker processes by pg_cancel/terminate_b
On Wed, 21 Jun 2017 11:04:34 -0400
Robert Haas wrote:
> On Wed, Jun 21, 2017 at 7:56 AM, Yugo Nagata wrote:
> > I have found that we can cancel/terminate autovacuum launchers and
> > background worker processes by pg_cancel/terminate_backend function.
> > I'm wondering this behavior is not expec
Yugo Nagata wrote:
> However, we can terminate background workers by pg_terminate_backend.
> In the following example, I terminated the logical replication launcher,
> and this process did not appear again[1].
>
> postgres=# select pg_terminate_backend(30902);
> pg_terminate_backend
>
On Wed, Jun 21, 2017 at 7:56 AM, Yugo Nagata wrote:
> I have found that we can cancel/terminate autovacuum launchers and
> background worker processes by pg_cancel/terminate_backend function.
> I'm wondering this behavior is not expected and if not I want to fix it.
I think it is expected. Even
Hi,
I have found that we can cancel/terminate autovacuum launchers and
background worker processes by pg_cancel/terminate_backend function.
I'm wondering this behavior is not expected and if not I want to fix it.
The current pg_stat_activity shows background workers and autovacuum
lancher as bel
On Wed, Jun 27, 2012 at 8:13 AM, Magnus Hagander wrote:
>> I went ahead and committed this.
>>
>> I kinda think we should back-patch this into 9.2. It doesn't involve
>> a catalog change, and would make the behavior consistent between the
>> two releases, instead of changing in 9.1 and then chang
On Tue, Jun 26, 2012 at 10:58 PM, Robert Haas wrote:
> On Thu, Mar 29, 2012 at 3:04 AM, Daniel Farina wrote:
>> On Mon, Mar 26, 2012 at 12:14 AM, Jeff Davis wrote:
>>> On Tue, 2012-03-20 at 01:38 -0700, Daniel Farina wrote:
On Thu, Mar 15, 2012 at 9:39 PM, Fujii Masao wrote:
> On Fri,
On Tue, Jun 26, 2012 at 1:58 PM, Robert Haas wrote:
> On Thu, Mar 29, 2012 at 3:04 AM, Daniel Farina wrote:
>> On Mon, Mar 26, 2012 at 12:14 AM, Jeff Davis wrote:
>>> On Tue, 2012-03-20 at 01:38 -0700, Daniel Farina wrote:
On Thu, Mar 15, 2012 at 9:39 PM, Fujii Masao wrote:
> On Fri,
On Thu, Mar 29, 2012 at 3:04 AM, Daniel Farina wrote:
> On Mon, Mar 26, 2012 at 12:14 AM, Jeff Davis wrote:
>> On Tue, 2012-03-20 at 01:38 -0700, Daniel Farina wrote:
>>> On Thu, Mar 15, 2012 at 9:39 PM, Fujii Masao wrote:
>>> > On Fri, Mar 16, 2012 at 8:14 AM, Daniel Farina wrote:
>>> >> Paral
On Mon, Mar 26, 2012 at 12:14 AM, Jeff Davis wrote:
> On Tue, 2012-03-20 at 01:38 -0700, Daniel Farina wrote:
>> On Thu, Mar 15, 2012 at 9:39 PM, Fujii Masao wrote:
>> > On Fri, Mar 16, 2012 at 8:14 AM, Daniel Farina wrote:
>> >> Parallel to pg_cancel_backend, it'd be nice to allow the user to j
On Tue, 2012-03-20 at 01:38 -0700, Daniel Farina wrote:
> On Thu, Mar 15, 2012 at 9:39 PM, Fujii Masao wrote:
> > On Fri, Mar 16, 2012 at 8:14 AM, Daniel Farina wrote:
> >> Parallel to pg_cancel_backend, it'd be nice to allow the user to just
> >> outright kill a backend that they own (politely,
On Thu, Mar 15, 2012 at 9:39 PM, Fujii Masao wrote:
> On Fri, Mar 16, 2012 at 8:14 AM, Daniel Farina wrote:
>> Parallel to pg_cancel_backend, it'd be nice to allow the user to just
>> outright kill a backend that they own (politely, with a SIGTERM),
>> aborting any transactions in progress, inclu
On Fri, Mar 16, 2012 at 04:42:07PM -0700, Daniel Farina wrote:
> On Fri, Mar 16, 2012 at 3:42 PM, Noah Misch wrote:
> > On Thu, Mar 15, 2012 at 04:14:03PM -0700, Daniel Farina wrote:
> >> I imagine the problem is a race condition whereby a pid might be
> >> reused by another process owned by anoth
On Fri, Mar 16, 2012 at 4:42 PM, Daniel Farina wrote:
> Hmm. Well, here's a patch that implements exactly that, I think,
That version had some screws loose due to some editor snafus.
Hopefully all better.
--
fdr
Implement-race-free-sql-originated-backend-cancellation-v3.patch.gz
Description:
On Fri, Mar 16, 2012 at 3:42 PM, Noah Misch wrote:
> On Thu, Mar 15, 2012 at 04:14:03PM -0700, Daniel Farina wrote:
>> Parallel to pg_cancel_backend, it'd be nice to allow the user to just
>> outright kill a backend that they own (politely, with a SIGTERM),
>> aborting any transactions in progress
On Thu, Mar 15, 2012 at 04:14:03PM -0700, Daniel Farina wrote:
> Parallel to pg_cancel_backend, it'd be nice to allow the user to just
> outright kill a backend that they own (politely, with a SIGTERM),
> aborting any transactions in progress, including the idle transaction,
> and closing the socke
On Thu, Mar 15, 2012 at 11:01 PM, Daniel Farina wrote:
> Okay, well, I believe there is a race in handling common
> administrative signals that *might* possibly matter. In the past,
> pg_cancel_backend was superuser only, which is a lot like saying "only
> available to people who can be the postg
On Thu, Mar 15, 2012 at 10:45 PM, Tom Lane wrote:
> Daniel Farina writes:
>> On Thu, Mar 15, 2012 at 10:33 PM, Tom Lane wrote:
>>> But actually I don't see what you hope to gain from such a change,
>>> even if it can be made to work. Anyone who can do kill(SIGINT) can
>>> do kill(SIGKILL), say
Daniel Farina writes:
> On Thu, Mar 15, 2012 at 10:33 PM, Tom Lane wrote:
>> But actually I don't see what you hope to gain from such a change,
>> even if it can be made to work. Anyone who can do kill(SIGINT) can
>> do kill(SIGKILL), say --- so you have to be able to trust the signal
>> sender.
On Thu, Mar 15, 2012 at 10:33 PM, Tom Lane wrote:
> Daniel Farina writes:
>> The way MyCancelKey is checked now is backwards, in my mind. It seems
>> like it would be better checked by the receiving PID (one can use a
>> check/recheck also, if so inclined). Is there a large caveat to that?
>
>
Daniel Farina writes:
> The way MyCancelKey is checked now is backwards, in my mind. It seems
> like it would be better checked by the receiving PID (one can use a
> check/recheck also, if so inclined). Is there a large caveat to that?
You mean, other than the fact that kill(2) can't transmit s
On Thu, Mar 15, 2012 at 9:39 PM, Fujii Masao wrote:
>> Shall we just do everything using the
>> MyCancelKey (which I think could just be called "SessionKey",
>> "SessionSecret", or even just "Session") as to ensure we have no case
>> of mistaken identity? Or does that end up being problematic?
>
>
On Fri, Mar 16, 2012 at 8:14 AM, Daniel Farina wrote:
> Parallel to pg_cancel_backend, it'd be nice to allow the user to just
> outright kill a backend that they own (politely, with a SIGTERM),
> aborting any transactions in progress, including the idle transaction,
> and closing the socket.
+1
Parallel to pg_cancel_backend, it'd be nice to allow the user to just
outright kill a backend that they own (politely, with a SIGTERM),
aborting any transactions in progress, including the idle transaction,
and closing the socket.
I imagine the problem is a race condition whereby a pid might be
re
2011/6/2 Noah Misch :
> On Wed, Jun 01, 2011 at 10:26:34PM -0400, Josh Kupershmidt wrote:
>> On Wed, Jun 1, 2011 at 5:55 PM, Noah Misch wrote:
>> > On Sun, May 29, 2011 at 10:56:02AM -0400, Josh Kupershmidt wrote:
>> >> Looking around, I see there were real problems[1] with sending SIGTERM
>> >> t
On Wed, Jun 1, 2011 at 5:55 PM, Noah Misch wrote:
> On Sun, May 29, 2011 at 10:56:02AM -0400, Josh Kupershmidt wrote:
>> Looking around, I see there were real problems[1] with sending SIGTERM
>> to individual backends back in 2005 or so, and pg_terminate_backend()
>> was only deemed safe enough to
On Sun, May 29, 2011 at 5:04 AM, Noah Misch wrote:
> What risks arise from unconditionally allowing these calls for the same user's
> backends? `pg_cancel_backend' ought to be safe enough; the user always has
> access to the standard cancellation protocol, making the SQL interface a mere
> conven
On Fri, Mar 11, 2011 at 8:54 AM, Bruce Momjian wrote:
> I have added it to the next commit fest.
Hi Torello,
I have volunteered (more accurately, Greg Smith "volunteered" me :-)
to be a reviewer for this patch. I know you're a bit new here, so I
thought I'd outline where this patch stands and wh
Kevin Grittner wrote:
> Torello Querci wrote:
>
> > I attach a path for this
>
> It's too late in the release cycle to consider this for version 9.1.
> Please add it to the open CommitFest for consideration for 9.2:
>
> https://commitfest.postgresql.org/action/commitfest_view/open
I have ad
On Mon, Feb 14, 2011 at 8:58 AM, Anssi Kääriäinen
wrote:
> On 02/14/2011 02:10 PM, Torello Querci wrote:
>>
>> I suppose that give the right to the owner db user to terminate or
>> cancel other session connected to the database which it is owner is a
>> good thing.
>> I not see any security proble
Torello Querci wrote:
> I attach a path for this
It's too late in the release cycle to consider this for version 9.1.
Please add it to the open CommitFest for consideration for 9.2:
https://commitfest.postgresql.org/action/commitfest_view/open
-Kevin
--
Sent via pgsql-hackers mailing lis
On 02/14/2011 02:10 PM, Torello Querci wrote:
I suppose that give the right to the owner db user to terminate or
cancel other session connected to the database which it is owner is a
good thing.
I not see any security problem because this user can cancel or
terminate only the session related with
Hi,
this is the first time that I post here, so if I wrong please don't kill me ...
I see that pg_terminate_backend and pg_cancel_backend can be execute
only by admin users.
This approach seems to be too restrictive in a lots of real situation.
In dept, I have a situation where it is created one
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
"Bruce Momjian" <[EMAIL PROTECTED]> writes:
> Gregory Stark wrote:
>
>> It seems to me we could replace all of the above with either SIGINT or USR1
>> and have a bunch of boolean flags in MyProc. I'm not sure of the implication
>> for sinval processing of having to get a whole bunch of LWLocks tho
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
Gregory Stark wrote:
> >> > Add pg_terminate_backend() to allow terminating only a single session.
>
> I'm interested in this because I was already looking for a solution to the
> "out of signals" problem we have.
>
> I think we could expand this by having a bunch of boolean flags, one each for
>
> > Though for the Windows case only, we could easily enough make it
> > possible to run pg_ctl kill remotely, since we use a named pipe.
> Does
> > this seem like a good or bad idea?
>
> Seems like we'd be opening a can of security worms :-(
Not really, standard windows ACL already applies to ev
"Magnus Hagander" <[EMAIL PROTECTED]> writes:
> Though for the Windows case only, we could easily enough make it
> possible to run pg_ctl kill remotely, since we use a named pipe. Does
> this seem like a good or bad idea?
Seems like we'd be opening a can of security worms :-(
Magnus Hagander 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
> >> 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 ba
Thanks. Good plan.
---
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> What I'm looking for is some concentrated testing. The fact that some
> >> people once in a while SIGTERM a backen
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> 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.
> OK, here is an opportunity for someone to run tests to get this into
> 8.2.
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> 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 specifi
I am not sure how you prove the non-existance of a bug. Ideas?
I do that by deleting all of my code (usually by accident :-)
No code, no bugs!
-- Korry
Csaba Nagy wrote:
>> "man kill" says the default is SIGTERM.
>>
>
> OK, so that means I do use it... is it known to be dangerous ? I thought
> till now that it is safe to use.
Apparently you never suffered any problems from that; neither did I.
> What about "select pg_cancel_backend()"
>
> "man kill" says the default is SIGTERM.
OK, so that means I do use it... is it known to be dangerous ? I thought
till now that it is safe to use. What about "select pg_cancel_backend()"
?
Thanks,
Csaba.
---(end of broadcast)---
TIP 9: In version
Bruce Momjian wrote:
>
>
> I am not sure how you prove the non-existance of a bug. Ideas?
>
Would be worth at least the Nobel prize :-)
Regards,
Andreas
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http:/
Csaba Nagy <[EMAIL PROTECTED]> writes:
> On Thu, 2006-08-03 at 18:10, Csaba Nagy wrote:
>> You didn't answer the original question: is killing SIGTERM a backend
> ^^^
> Nevermind, I don't do that. I do 'kill backend_pid' without specifying
>
Csaba Nagy wrote:
> On Thu, 2006-08-03 at 18:10, Csaba Nagy wrote:
>
>> You didn't answer the original question: is killing SIGTERM a backend
>>
> ^^^
> Nevermind, I don't do that. I do 'kill backend_pid' without specifying
> the sig
Tom Lane wrote:
> Andreas Pflug <[EMAIL PROTECTED]> 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.
>>>
>
>
>> If the backend's stuck, I'll have to SIGTERM it, whether there's
>> pg_termi
Csaba Nagy <[EMAIL PROTECTED]> writes:
> I do know a case where a plain kill will seem to be stucked: on vacuum
> of a big table. I guess when it starts an index's cleanup scan it will
> insist to finish it before stopping.
We've fixed a few cases of missing CHECK_FOR_INTERRUPTS lately, and will
f
> "Stuck?" You have not shown us a case where SIGTERM rather than SIGINT
> is necessary or appropriate. It seems to me the above is assuming the
> existence of unknown backend bugs, exactly the same thing you think
> I shouldn't be assuming ...
I do know a case where a plain kill will seem to be
On Thu, 2006-08-03 at 18:10, Csaba Nagy wrote:
> You didn't answer the original question: is killing SIGTERM a backend
^^^
Nevermind, I don't do that. I do 'kill backend_pid' without specifying
the signal, and I'm sufficiently unfamiliar wit
Andreas Pflug <[EMAIL PROTECTED]> 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.
> If the backend's stuck, I'll have to SIGTERM it, whether there's
> pg_terminate_backend or not.
"Stuck?" You have not shown us
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
Csaba Nagy <[EMAIL PROTECTED]> 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.
> 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
user
Bruce Momjian <[EMAIL PROTECTED]> 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, w
Tom Lane wrote:
> Andreas Pflug <[EMAIL PROTECTED]> 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
> > c
Tom Lane wrote:
> Andreas Pflug <[EMAIL PROTECTED]> 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
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 t
Andreas Pflug <[EMAIL PROTECTED]> 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 ple
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, do
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:
On Tue, 2005-06-21 at 23:34 -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > Tom Lane wrote:
> >> In any case the correct way to solve the problem is to find out what's
> >> being left corrupt by SIGTERM, rather than install more messiness in
> >> order to avoid facing the real issue ...
>
> >
Tom Lane wrote:
> Bruce Momjian writes:
> > I have been running some tests to try to see the lock table corruption
> > but I have been unable to reproduce the problem.
>
> It's possible that what Rod was complaining of is fixed in CVS tip ---
> see discussion about RemoveFromWaitQueue() bug. If
Bruce Momjian writes:
> I have been running some tests to try to see the lock table corruption
> but I have been unable to reproduce the problem.
It's possible that what Rod was complaining of is fixed in CVS tip ---
see discussion about RemoveFromWaitQueue() bug. If so, it would have
been a bug
Tom Lane wrote:
> "Magnus Hagander" <[EMAIL PROTECTED]> writes:
> > Assuming we don't get such a case, and a chance to fix it, before 8.1
> > (while still hoping we will get it fixed properly, we can't be sure, can
> > we? If we were, it'd be fixed already). In this case, will you consider
> > such
1 - 100 of 115 matches
Mail list logo
