On Mon, 2006-05-15 at 09:28 -0700, Jeff Frost wrote: > I've run into a problem with a PITR setup at a client. The problem is that > whenever the CIFS NAS device that we're mounting at /mnt/pgbackup has > problems What kind of problems? > , it seems that the current client connection gets blocked and this > eventually builds up to a "sorry, too many clients already" error. This sounds like the archiver keeps waking up and trying the command, but it fails, yet that request is causing a resource leak on the NAS. Eventually, archiver retrying the command eventually fails. Or am I misunderstanding your issues? > I'm > wondering if this is expected behavior with the archive command and if I > should build in some more smarts to my archive script. Maybe I should fork > and waitpid such that I can use a manual timeout shorter than whatever the > CIFS timeout is so that I can return an error in a reasonable amount of time? The archiver is designed around the thought that *attempting* to archive is a task that it can do indefinitely without a problem; its up to you to spot that the link is down. We can put something in to make the retry period elongate, but you'd need to put a reasonable case for how that would increase robustness. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com
