Exactly. In theory it probably works fine to allow one backend to exit
via kill -TERM, but it cannot be claimed that that behavior has been
tested to any significant extent --- fast shutdown is not stressing it
in the same way.
I think this is largely a question of someone doing a
Well, that's clear evidence that the only way we are going to be able to
SIGTERM a backend is it does a query cancel first, then terminates. I
don't think anything else is going to work cleanly.
---
Rod Taylor wrote:
On Thu, May 12, 2005 at 10:39:14AM -0400, Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
Another thought I had along that line was use a different signal to
simply do a query cancel and set a global flag that is more or less
get out when you're done with query cancel. Then if
Jim C. Nasby wrote:
On Thu, May 12, 2005 at 10:39:14AM -0400, Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
Another thought I had along that line was use a different signal to
simply do a query cancel and set a global flag that is more or less
get out when you're done with
Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
Another thought I had along that line was use a different signal to
simply do a query cancel and set a global flag that is more or less
get out when you're done with query cancel. Then if that flag is set,
just close the connection
Bruce Momjian pgman@candle.pha.pa.us writes:
Can't we
have a signal that does a query cancel, does the normal cancel cleanup,
then exits rather than asking for another query?
That *is* what we have.
I give up trying to explain myself, since it's obvious that I'm not
getting through to anyone.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Josh Berkus
Sent: 12 May 2005 18:04
To: Andreas Pflug
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Server instrumentation for 8.1
Andreas,
First, as some other msg states
Andrew - Supernews wrote:
On 2005-05-12, Andreas Pflug [EMAIL PROTECTED] wrote:
relpages is updated from the value of RelationGetNumberOfBlocks(rel) which
is definitive (it gets the value from smgr which gets it from the physical
file sizes); the only inaccuracy is that it is correct only as of
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Andrew Sullivan
Sent: 11 May 2005 21:04
To: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Server instrumentation for 8.1
On Wed, May 11, 2005 at 04:44:21PM +, Andreas Pflug wrote
Tom Lane wrote:
Josh Berkus josh@agliodbs.com writes:
- The superuser only generic file functions in the admin package have
been posted for 8.0, but where (more or less ) silently dropped. These
functions allow pgadmin to display the server logs, as well as editing
pg_hba.conf and postgresql.conf
Josh Berkus wrote:
- dbsize has been in contrib for a long time, though it appears to me as
quite a basic functionality to find out about storage needs.
Although not needed so much if the new system views are approved; we have a
view that calculates database size.
First, as some other msg
Andrew - Supernews wrote:
dbsize looks at the actual size of files on disk; newsysviews does not,
it shows estimated sizes as taken from relpages.
Which shows *net* size only, not actual size because non-vacuumed rows
are not covered. It is correct after a vacuum full only.
newsysviews doesn't
- There was a pg_kill_backend function in pre-8.0, but it
was dropped
because it's too dangerous. Incidentially, I've been in
the situation
more than once where I needed to kill a backend process
that was running
wild; alternatively, I'd have to shutdown the whole server.
I had to do
Magnus Hagander wrote:
Not kill -9. Kill -9 is safe because it causes a complete restart of
the postmaster (it's the same as a backend crash, really). Kill -INT is
also safe, because it does a simlpe query cancel.
I don't recall exactly; AFAIR this was discussed between Dave and Tom.
Actually,
On 2005-05-12, Andreas Pflug [EMAIL PROTECTED] wrote:
These seem potentially very dangerous though, so we wouldn't want them
installed by default.
Not more dangerous than drop table pg_class.
Have you ever tried that?
test=# drop table pg_class;
ERROR: permission denied: pg_class is a
Not kill -9. Kill -9 is safe because it causes a complete
restart of
the postmaster (it's the same as a backend crash, really).
Kill -INT
is also safe, because it does a simlpe query cancel.
I don't recall exactly; AFAIR this was discussed between Dave
and Tom.
Actually, *both*
On 2005-05-12, Andreas Pflug [EMAIL PROTECTED] wrote:
Andrew - Supernews wrote:
dbsize looks at the actual size of files on disk; newsysviews does not,
it shows estimated sizes as taken from relpages.
Which shows *net* size only, not actual size because non-vacuumed rows
are not covered. It
On Thu, May 12, 2005 at 10:55:22AM +0200, Magnus Hagander wrote:
Not kill -9. Kill -9 is safe because it causes a complete restart of
the postmaster (it's the same as a backend crash, really). Kill -INT is
also safe, because it does a simlpe query cancel.
Hmm, would it be possible to use
Not kill -9. Kill -9 is safe because it causes a complete
restart of
the postmaster (it's the same as a backend crash, really).
Kill -INT
is also safe, because it does a simlpe query cancel.
Hmm, would it be possible to use another signal for cancel
the current query and enter a
Andrew - Supernews [EMAIL PROTECTED] writes:
What currently happens is that backends respond to kill -15 (_NOT_ -9)
by cleaning up and exiting. This code path is used for implementing the
stop -mfast option, which means that as it currently exists, the cleanup
only has to be good enough to let
Magnus Hagander [EMAIL PROTECTED] writes:
Another thought I had along that line was use a different signal to
simply do a query cancel and set a global flag that is more or less
get out when you're done with query cancel. Then if that flag is set,
just close the connection and proceed as if
Andreas,
First, as some other msg states the views will estimate the sizes,
dbsize uses actual file sizes. Second, in contrast to CKL, I would *not*
use these fancy new system views, because they mean yet another
dependency for pgAdmin.
grin I like that. You're in favor of including the
On Thursday 12 May 2005 10:24, Tom Lane wrote:
Andrew - Supernews [EMAIL PROTECTED] writes:
What currently happens is that backends respond to kill -15 (_NOT_ -9)
by cleaning up and exiting. This code path is used for implementing the
stop -mfast option, which means that as it currently
On Thursday 12 May 2005 13:04, Josh Berkus wrote:
Andreas,
First, as some other msg states the views will estimate the sizes,
dbsize uses actual file sizes. Second, in contrast to CKL, I would *not*
use these fancy new system views, because they mean yet another
dependency for pgAdmin.
There's still a lengthy discussion going on whether it's a good idea to
add a forth way to read pgsql's schema (pg_* tables, pg_* views,
information_schema, did I miss one?), but I'd like to see helper
functions for issues *not* covered in the core package.
- dbsize has been in contrib for a
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Andreas Pflug
Sent: 11 May 2005 17:44
To: pgsql-hackers@postgresql.org
Subject: [HACKERS] Server instrumentation for 8.1
There's still a lengthy discussion going on whether it's a
good idea
On Wed, May 11, 2005 at 04:44:21PM +, Andreas Pflug wrote:
Yes yes I know, all of these can be done by a local administrator with
console access and an editor and cmd line tools, but there are indeed
people that do *not* have console access, or like to use decent tools
Is there a
On Wed, May 11, 2005 at 04:44:21PM +, Andreas Pflug wrote:
There's still a lengthy discussion going on whether it's a good idea to
add a forth way to read pgsql's schema (pg_* tables, pg_* views,
information_schema, did I miss one?), but I'd like to see helper
functions for issues *not*
Andreas,
I think you bring up some good points, but I also think that each package you
propose needs to be dealt with individually.
- dbsize has been in contrib for a long time, though it appears to me as
quite a basic functionality to find out about storage needs.
Although not needed so
On 2005-05-11, Jim C. Nasby [EMAIL PROTECTED] wrote:
On Wed, May 11, 2005 at 04:44:21PM +, Andreas Pflug wrote:
There's still a lengthy discussion going on whether it's a good idea to
add a forth way to read pgsql's schema (pg_* tables, pg_* views,
information_schema, did I miss one?),
Josh Berkus josh@agliodbs.com writes:
- The superuser only generic file functions in the admin package have
been posted for 8.0, but where (more or less ) silently dropped. These
functions allow pgadmin to display the server logs, as well as editing
pg_hba.conf and postgresql.conf without
31 matches
Mail list logo
