Joe Conway <mail@joeconway.com> writes:
> Tom Lane wrote:
>> Joe Conway <mail@joeconway.com> writes:
>>> Maybe specify an archive location (that of course could be on a separate
>>> partition) that the external archiver should check in addition to the
>>> normal WAL location. At some predetermined interval, push WAL log
>>> segments no longer needed to the archive location.
>>
>> Does that really help? The panic happens when you fill the "normal" and
>> "archive" partitions, how's that different from one partition?
> I see your point. But it would allow you to use a relatively modest
> local partition for WAL segments, while you might be using a 1TB netapp
> tray over NFS for the archive segments.
Fair enough, but it seems to me that that sort of setup really falls in
the category of a user-defined archiving process --- that is, the hook
that Postgres calls will push WAL segments from the local partition to
the NFS server, and then pushing them off NFS to tape is the
responsibility of some other user-defined subprocess. Database panic
happens if and only if the local partition overflows. I don't see that
making Postgres explicitly aware of the secondary NFS arrangement will
buy anything.
> I guess if the archive partition fills up, I would err on the side of
> dropping archive segments on the floor.
That should be user-scriptable policy, in my worldview.
We haven't yet talked much about what the WAL-segment-archiving API
should look like, but if it cannot support implementing the above kind
of arrangement outside the database, then we've dropped the ball.
IMHO anyway.
regards, tom lane
