| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | "Jim C(dot) Nasby" <jim(at)nasby(dot)net> |
| Cc: | Heikki Linnakangas <heikki(at)enterprisedb(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Phantom Command ID |
| Date: | 2006-09-20 21:43:40 |
| Message-ID: | 19549.1158788620@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
"Jim C. Nasby" <jim(at)nasby(dot)net> writes:
> I didn't realize we had a lot of ways a backend could run a machine out
> of memory, or at least ways that didn't have some kind of limit (ie:
> work_mem). Are any of them very easy to run into?
work_mem has nothing to do with trying to guarantee "no swapping DoS".
If it did, it wouldn't be USERSET, and it wouldn't be per query step.
The fact is that ulimit does what you want in that regard already;
why should we try to reinvent that wheel?
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jim C. Nasby | 2006-09-20 21:44:32 | Re: [HACKERS] Incrementally Updated Backup |
| Previous Message | Jim C. Nasby | 2006-09-20 21:30:57 | Re: Phantom Command ID |