On Sun, Feb 9, 2014 at 9:14 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> linuxhippy@gmail.com writes:
> > It seems wal_writer_delay is limited to 10s without any technical reason.
>
> The "technical reason" is that values much larger than that would be a
> performance and reliability disaster for typical installations.
>
How so? I think most installations run with synchronous_commit on.
We seem to be arguing both that making it larger would do absolutely
nothing, and that making it larger would do something very bad.
While it could certainly be argued that the limit of 10s is a bit too
> tight, allowing values as large as 1h would be a large-caliber foot gun
> for most people. So I'm very hesitant to raise it that far without a
> more convincing argument that useful behavior can be had there.
>
We let them turn fsync off. How much bigger of a foot gun could we
possibly hand them?
If we make people turn fsync off, rather than letting them
use wal_writer_delay to do the very thing that it is intended to do, I
don't see that as doing them any favors.
>
> The bigger picture is that if you allow WAL to not reach disk for 1h,
> that's up to 1h worth of data that you lose irretrievably in a crash.
> So even if this adjustment allowed you to get that behavior, it's not
> very attractive behavior. If you actually are OK with such little data
> security, maybe you should consider other approaches. Perhaps you could
> keep the whole database on a RAM disk (tmpfs) and rsync it to flash every
> hour, or some variant of that?
>
And hope that the rsync didn't leave it in an inconsistent state because it
fired up just when a change was starting to get written. Ick. I think
that having knobs that do what they say and say what they do seems much
safer than forcing people to jump through dangerous hoops.
Cheers,
Jeff