From: | Greg Stark <stark(at)mit(dot)edu> |
---|---|
To: | Andres Freund <andres(at)2ndquadrant(dot)com> |
Cc: | Christian Ullrich <chris(at)chrullrich(dot)net>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Hard limit on WAL space used (because PANIC sucks) |
Date: | 2013-06-06 22:42:11 |
Message-ID: | CAM-w4HP8nThcxhaQRj_e8zx4A+EV6yseogWLAZ2Q=Z2aB8wp8w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Jun 6, 2013 at 10:38 PM, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
> That's not a bad technique. I wonder how reliable it would be in
> postgres. Do all filesystems allow a rename() to succeed if there isn't
> actually any space left? E.g. on btrfs I wouldn't be sure. We need to
> rename because WAL files need to be named after the LSN timelineid...
I suppose we could just always do the rename at the same time as
setting up the current log file. That is, when we start wal log x also
set up wal file x+1 at that time.
This isn't actually guaranteed to be enough btw. It's possible that
the record we're actively about to write will require all of both
those files... But that should be very unlikely.
--
greg
From | Date | Subject | |
---|---|---|---|
Next Message | Ants Aasma | 2013-06-06 22:42:39 | Proposal for CSN based snapshots |
Previous Message | Greg Stark | 2013-06-06 22:32:49 | Re: SPGist "triple parity" concept doesn't work |