Alvaro Herrera writes:
> Maybe we should have another inter-backend signal: when a process gets
> ENFILE, signal all other backends and they close a bunch of files each.
I was wondering about that myself, but on balance I think it'd be a lot
of work to achieve not much. What you would have is th
On Fri, Aug 28, 2009 at 4:13 AM, Alvaro
Herrera wrote:
> Maybe we should have another inter-backend signal: when a process gets
> ENFILE, signal all other backends and they close a bunch of files each.
I wonder if this is a new problem due to the FSM and VM using up extra
file handles?
--
greg
Vick Khera wrote:
> On Tue, Aug 25, 2009 at 4:55 PM, Tom Lane wrote:
> > I've always thought that the fd.c layer is more about not having to
> > configure the code explicitly for max-files-per-process limits. Once
> > you get into ENFILE conditions, even if Postgres manages to stay up,
> > everyth
On Tue, Aug 25, 2009 at 4:55 PM, Tom Lane wrote:
> I've always thought that the fd.c layer is more about not having to
> configure the code explicitly for max-files-per-process limits. Once
> you get into ENFILE conditions, even if Postgres manages to stay up,
> everything else on the box is going
Alvaro Herrera writes:
> Would it be worth for walwriter to grab a dozen of dummy fd's?
I don't think so. As you point out, we could never positively guarantee
no ENFILE failures anyway. If we were in an out-of-FDs situation, any
such cushion would get whittled down to nothing pretty quickly, t
On Tue, Aug 25, 2009 at 2:49 PM, Alvaro
Herrera wrote:
> Vivek, do you see this error message before the PANIC?
> LOG: out of file descriptors: %m; release and retry
>
Nope. no mention of "release" in that log file. I have a handful of
lines like these:
ERROR: could not load library
"/usr/l
Tom Lane wrote:
> Vick Khera writes:
> > On Tue, Aug 25, 2009 at 1:09 PM, Alvaro
> > Herrera wrote:
> >> PG is not supposed to crash when it runs out of file descriptors. �In
> >> fact there's a whole abstraction layer to ensure this does not happen.
>
> > From my syslog:
> > Aug 21 15:11:13 d01
Vick Khera writes:
> On Tue, Aug 25, 2009 at 1:09 PM, Alvaro
> Herrera wrote:
>> PG is not supposed to crash when it runs out of file descriptors. In
>> fact there's a whole abstraction layer to ensure this does not happen.
> From my syslog:
> Aug 21 15:11:13 d01 postgres[12037]: [156-1] PANIC:
On Tue, Aug 25, 2009 at 1:09 PM, Alvaro
Herrera wrote:
> Vick Khera wrote:
>> On Sat, Aug 22, 2009 at 6:55 PM, Greg Sabino Mullane
>> wrote:
>> > A server crash is a pretty rare event in the Postgres world, so I
>> > would not spend too many cycles on this...
>>
>> I had one the other day caused b
Vick Khera wrote:
> On Sat, Aug 22, 2009 at 6:55 PM, Greg Sabino Mullane wrote:
> > A server crash is a pretty rare event in the Postgres world, so I
> > would not spend too many cycles on this...
>
> I had one the other day caused by server resource issues: I ran out of
> file descriptors when I
On Mon, Aug 24, 2009 at 2:10 AM, Scott Marlowe wrote:
> On Sat, Aug 22, 2009 at 4:55 PM, Greg Sabino Mullane wrote:
>> A server crash is a pretty rare event in the Postgres world, so I
>> would not spend too many cycles on this...
>
> I've been running pg in production since 7.0 came out. zero ser
On Sat, Aug 22, 2009 at 6:55 PM, Greg Sabino Mullane wrote:
> A server crash is a pretty rare event in the Postgres world, so I
> would not spend too many cycles on this...
>
I had one the other day caused by server resource issues: I ran out of
file descriptors when I had a very large surge in ac
On Tue, 2009-08-25 at 00:26 +0400, Sergey Samokhin wrote:
> Though I don't think there are any differences between the crash of
> PosgreSQL itself and the crash of the machine PostgreSQL is running on
> from the client's point of view.
There certainly are!
For one thing, if a client with an esta
On Tue, 2009-08-25 at 00:26 +0400, Sergey Samokhin wrote:
> Hello!
>
> > If, however, you mean a crash of the server machine PostgreSQL is
> > runnning on, which is MUCH more likely and will have different
> > effects/behaviour, then Ray Stell's advice to bring the interface down
> > is probably p
On Tue, 2009-08-25 at 00:26 +0400, Sergey Samokhin wrote:
> Hello!
>
> > If, however, you mean a crash of the server machine PostgreSQL is
> > runnning on, which is MUCH more likely and will have different
> > effects/behaviour, then Ray Stell's advice to bring the interface down
> > is probably p
Hello!
> You should also test your client's response to the Pg server remaining
> up but becoming non-responsive (eg: failed disk array causes Pg backends
> to remain in uninterruptable disk I/O system calls in the kernel). A
> possibly good way to do this is to SIGSTOP the backend(s).
I haven't
Hello!
> If, however, you mean a crash of the server machine PostgreSQL is
> runnning on, which is MUCH more likely and will have different
> effects/behaviour, then Ray Stell's advice to bring the interface down
> is probably pretty good.
Sorry for a bit ambiguous usage of both "crash" and "faul
On Mon, Aug 24, 2009 at 12:41 PM, David Fetter wrote:
> On Mon, Aug 24, 2009 at 12:10:30AM -0600, Scott Marlowe wrote:
>> On Sat, Aug 22, 2009 at 4:55 PM, Greg Sabino Mullane
>> wrote:
>> > A server crash is a pretty rare event in the Postgres world, so I
>> > would not spend too many cycles on th
On Mon, Aug 24, 2009 at 12:10:30AM -0600, Scott Marlowe wrote:
> On Sat, Aug 22, 2009 at 4:55 PM, Greg Sabino Mullane wrote:
> > A server crash is a pretty rare event in the Postgres world, so I
> > would not spend too many cycles on this...
>
> I've been running pg in production since 7.0 came ou
On Mon, Aug 24, 2009 at 12:49 AM, Craig
Ringer wrote:
> You should also test your client's response to the Pg server remaining
> up but becoming non-responsive (eg: failed disk array causes Pg backends
> to remain in uninterruptable disk I/O system calls in the kernel). A
> possibly good way to do
On Sat, 2009-08-22 at 13:03 -0700, Sergey Samokhin wrote:
> Hello!
>
> To make my client application tolerant of PostgreSQL failures I first
> need to be able to simulate them in a safe manner (hard reset isn't a
> solution I'm looking for :)
>
> Is there a way to disconnect all the clients as if
On Sat, Aug 22, 2009 at 4:55 PM, Greg Sabino Mullane wrote:
> A server crash is a pretty rare event in the Postgres world, so I
> would not spend too many cycles on this...
I've been running pg in production since 7.0 came out. zero server crashes.
--
Sent via pgsql-general mailing list (pgsql-
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
>> Is there a way to disconnect all the clients as if the server has
>> crashed? It should look like a real crash from the client's point of
>> view.
> ifconfig ethx d
On Sat, Aug 22, 2009 at 01:03:43PM -0700, Sergey Samokhin wrote:
> Is there a way to disconnect all the clients as if the server has
> crashed? It should look like a real crash from the client's point of
> view.
ifconfig ethx down ?
--
Sent via pgsql-general mailing list (pgsql-general@postgresq
24 matches
Mail list logo
