Re: Phantom Command ID - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Phantom Command ID
Date
Msg-id 18367.1158783767@sss.pgh.pa.us
Whole thread Raw
In response to Re: Phantom Command ID  ("Jim C. Nasby" <jim@nasby.net>)
Responses Re: Phantom Command ID  ("Jim C. Nasby" <jim@nasby.net>)
List pgsql-hackers
"Jim C. Nasby" <jim@nasby.net> writes:
> What would the failure mode be? Would we just keep going until the box
> ran out of memory? I think it'd be better to have some kind of hard
> limit so that a single backend can't grind a production server into a
> swap-storm. (Arguably, not having a limit is exposing a DoS
> vulnerability).

[ shrug... ]  If we tried to guarantee such a thing we'd be putting
arbitrary limits into hundreds if not thousands of different bits of the
backend.  I think the correct answer for an admin who is worried about
such a thing is to make sure that the process ulimit is a sufficiently
small fraction of the machine's available RAM.  Only if we can't
gracefully handle running up against ulimit is it our problem (hence,
we have a stack-size overflow check, but not any such thing for data size).
        regards, tom lane


pgsql-hackers by date:

Previous
From: "Jim C. Nasby"
Date:
Subject: Re: [PATCHES] Incrementally Updated Backup
Next
From: David Fetter
Date:
Subject: Re: Units in postgresql.conf.sample