From: | "MauMau" <maumau307(at)gmail(dot)com> |
---|---|
To: | "Josh Berkus" <josh(at)agliodbs(dot)com>, <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Hard limit on WAL space used (because PANIC sucks) |
Date: | 2013-06-09 00:32:25 |
Message-ID: | D117F8165E894FA1B805302504C6F1D7@maumau |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
From: "Josh Berkus" <josh(at)agliodbs(dot)com>
> There's actually three potential failure cases here:
>
> - One Volume: WAL is on the same volume as PGDATA, and that volume is
> completely out of space.
>
> - XLog Partition: WAL is on its own partition/volume, and fills it up.
>
> - Archiving: archiving is failing or too slow, causing the disk to fill
> up with waiting log segments.
I think there is one more case. Is this correct?
- Failure of a disk containing data directory or tablespace
If checkpoint can't write buffers to disk because of disk failure,
checkpoint cannot complete, thus WAL files accumulate in pg_xlog/.
This means that one disk failure will lead to postgres shutdown.
> xLog Partition
> --------------
>
> As Heikki pointed, out, a full dedicated WAL drive is hard to fix once
> it gets full, since there's nothing you can safely delete to clear
> space, even enough for a checkpoint record.
This sounds very scary. Is it possible to complete recovery and start up
postmaster with either or both of the following modifications?
[Idea 1]
During recovery, force archiving a WAL file and delete/recycle it in
pg_xlog/ as soon as its contents are applied.
[Idea 2]
During recovery, when disk full is encountered at end-of-recovery
checkpoint, force archiving all unarchived WAL files and delete/recycle them
at that time.
Regards
MauMau
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2013-06-09 00:37:21 | Re: Cost limited statements RFC |
Previous Message | Robert Haas | 2013-06-09 00:20:42 | Re: Optimising Foreign Key checks |