- Original Message -
Subject: Re: [ADMIN] Shutdown fails with both 'fast' and 'immediate'
David Schnur writes:
I'm less concerned with the particular query than with the general
question
of when a shutdown could hang like this. I expected this to be possible
when using -m fast, b
David Schnur writes:
> I'm less concerned with the particular query than with the general question
> of when a shutdown could hang like this. I expected this to be possible
> when using -m fast, but my understanding was that -m immediate really forced
> termination.
Yeah, it's supposed to. The
@Julio Leyva: The table does get vacuumed at the end of the maintenance
tasks; in this case it's not making it that far, of course.
@Scott Marlowe: Truncate isn't an option here, unfortunately.
I'm less concerned with the particular query than with the general question
of when a shutdown could ha
On Wed, May 12, 2010 at 8:45 AM, Kenneth Marshall wrote:
> On Wed, May 12, 2010 at 10:22:14AM -0400, David Schnur wrote:
>> I develop an app that uses a back-end Postgres database, currently 8.3.9.
>> The database is started when the app starts up, and stopped when it shuts
>> down. Shutdown use
Hi
A hint : do you have any long running SQL requests, while there is some
network-control devices like firewalls between the client and the server ?
Using Oracle, we faced the same situation where a firewall in the middle broke
the connection after a period of network inactivity between the cl
On Wed, May 12, 2010 at 10:22:14AM -0400, David Schnur wrote:
> I develop an app that uses a back-end Postgres database, currently 8.3.9.
> The database is started when the app starts up, and stopped when it shuts
> down. Shutdown uses pg_ctl with -m fast, and waits two minutes for the
> process
David Schnur writes:
> I develop an app that uses a back-end Postgres database, currently 8.3.9.
> The database is started when the app starts up, and stopped when it shuts
> down. Shutdown uses pg_ctl with -m fast, and waits two minutes for the
> process to complete. If it doesn't, it tries -m
I develop an app that uses a back-end Postgres database, currently 8.3.9.
The database is started when the app starts up, and stopped when it shuts
down. Shutdown uses pg_ctl with -m fast, and waits two minutes for the
process to complete. If it doesn't, it tries -m immediate, and waits two
more
Kevin Grittner ha scritto:
Silvio Brandani wrote:
postgresql-2010-05-12_053937.log:2010-05-12 06:30:57 CEST [26617]:
[288-1] LOG: could not receive data from client: Connection reset
by peer
postgresql-2010-05-12_053937.log:2010-05-12 06:30:57 CEST [26617]:
[289-1] LOG: unexpected EOF on c
Silvio Brandani wrote:
> postgresql-2010-05-12_053937.log:2010-05-12 06:30:57 CEST [26617]:
> [288-1] LOG: could not receive data from client: Connection reset
> by peer
> postgresql-2010-05-12_053937.log:2010-05-12 06:30:57 CEST [26617]:
> [289-1] LOG: unexpected EOF on client connection
>
>
I had a problem with neverending forced autovacuum process, running as
preventing xid wraparound. As I finally (?) found, following some
advices given here: ->
http://forums.enterprisedb.com/posts/list/2028.page, that autovacuum in
question was not just one autovacuum, but many different autov
We have many postgres installation 8.3.x on different linux servers
we get each days a lot of messages like the following:
postgresql-2010-05-12_053937.log:2010-05-12 06:30:57 CEST [26617]:
[288-1] LOG: could not receive data from client: Connection reset by peer
postgresql-2010-05-12_053937.
12 matches
Mail list logo
