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:
> > >
> > 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 someon
Bruce Momjian 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. Commit the darn th
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 clos
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 wi
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
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 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,
>
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 p
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 curre
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.
I like that. You're in favor of including the serv
"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 proce
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 t
> > 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
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
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 co
> > 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.
> Actu
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
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
> >>- 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
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
al
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 states
Tom Lane wrote:
Josh Berkus 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 console ac
> -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:4
Josh Berkus 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 console access
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 mis
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 mu
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 *n
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
> -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 go
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 lo
31 matches
Mail list logo
