Skip site navigation (1) Skip section navigation (2)

Re: EINTR error in SunOS

From: Greg Stark <gsstark(at)mit(dot)edu>
To: Rod Taylor <pg(at)rbt(dot)ca>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Greg Stark <gsstark(at)mit(dot)edu>, Qingqing Zhou <zhouqq(at)cs(dot)toronto(dot)edu>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: EINTR error in SunOS
Date: 2006-01-01 00:03:22
Message-ID: 87lky07r1x.fsf@stark.xeocode.com (view raw or flat)
Thread:
Lists: pgsql-hackers
Rod Taylor <pg(at)rbt(dot)ca> writes:

> Are there issues with having an archive_command which does things with
> NFS based filesystems?

Well, whatever command you use for archive_command -- probably just "cp" if
you're using NFS would hang if the NFS server went away. What would happen
then might be interesting. If Postgres finds the archive_command hanging
indefinitely will it correctly avoid recycling the WAL log indefinitely? I
assume so.

What's nonoptimal here is that I don't think there would be any warning that
anything was wrong until the WAL logs eventually filled up their filesystem
and then postgres stopped running. In the meantime your archived WAL logs
would be getting older and older and you would have no indication that
anything was failing.

This was the intention with the NFS error handling. The theory being that
eventually the server comes back up and things resume functioning exactly
where they left off with no lost operations. The upside is you don't have
things failing, then resuming later and unhandled errors in the meantime
leading to data corruption. The downside is there's no way for "cp" and
ultimately Postgres to know anything's wrong except to have a timeout itself
and an arbitrary maximum amount of time to expect operations to take.

-- 
greg


In response to

pgsql-hackers by date

Next:From: Tom LaneDate: 2006-01-01 00:04:42
Subject: Re: [PATCHES] default resource limits
Previous:From: Qingqing ZhouDate: 2005-12-31 22:21:14
Subject: Re: EINTR error in SunOS

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group