| From: | Peter Geoghegan <pg(at)heroku(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com> |
| Subject: | Re: Hard limit on WAL space used (because PANIC sucks) |
| Date: | 2014-01-21 23:38:48 |
| Message-ID: | CAM3SWZRpiji3+oQN6aeN0=a5etc73n_4mFyTq4to=nyxc0DRRQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Jan 21, 2014 at 3:24 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Maybe we could get some mileage out of the fact that very approximate
> techniques would be good enough. For instance, I doubt anyone would bleat
> if the system insisted on having 10MB or even 100MB of future WAL space
> always available. But I'm not sure exactly how to make use of that
> flexibility.
In the past I've thought that one approach that would eliminate
concerns about portably and efficiently knowing how much space is left
on the pg_xlog filesystem is to have a "ballast file". Under this
scheme, perhaps XLogInsert() could differentiate between a soft and
hard failure. Hopefully the reserve function you mentioned, which is
still called at the same place, just before each critical section
thereby becomes cheap. Perhaps I'm just restating what you said,
though.
--
Peter Geoghegan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2014-01-21 23:43:29 | Re: Hard limit on WAL space used (because PANIC sucks) |
| Previous Message | Tom Lane | 2014-01-21 23:24:39 | Re: Hard limit on WAL space used (because PANIC sucks) |