Re: does wal archiving block the current client connection?

Поиск
Список
Период
Сортировка
От Jeff Frost
Тема Re: does wal archiving block the current client connection?
Дата
Msg-id Pine.LNX.4.64.0605151424500.9581@discord.dyndns.org
обсуждение исходный текст
Ответ на Re: does wal archiving block the current client connection?  (Simon Riggs <simon@2ndquadrant.com>)
Ответы Re: does wal archiving block the current client connection?  (Scott Marlowe <smarlowe@g2switchworks.com>)
Re: does wal archiving block the current client connection?  (Simon Riggs <simon@2ndquadrant.com>)
Список pgsql-admin
On Mon, 15 May 2006, Simon Riggs wrote:

> 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 becomes unwritable for whatever reason CIFS shares become unwritable.  It's
a windows 2003 NAS device and a reboot solves the problem, but it leaves no
event logs on the windows side of things, so difficult to determine the root
cause.

>
>> , 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?

that's possible.  Does the archiver use a DB connection whenever it tries to
run archive_command?  If so, then that's almost certainly the problem.  I
suspect a faster timeout on the CIFS mount would fix the issue as well, but I
didn't see any such options in the mount.cifs manpage.

> 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.

That all sounds perfectly reasonable.  If the archiver is using up a
connection for each archive_command issued, then I suspect that's our problem,
as there were also lots of debug logs showing that the db was trying to
archive several WAL files at near the same time, likely pushing us over our
100 connection limit.  If the archiver does not use up a connection, then I
suppose I don't know what's actually going on unless postgres blocks the
commit of the transaction which triggered the archive_command until the
archive command finishes (or fails).

--
Jeff Frost, Owner     <jeff@frostconsultingllc.com>
Frost Consulting, LLC     http://www.frostconsultingllc.com/
Phone: 650-780-7908    FAX: 650-649-1954

В списке pgsql-admin по дате отправления:

Предыдущее
От: Simon Riggs
Дата:
Сообщение: Re: does wal archiving block the current client connection?
Следующее
От: Scott Marlowe
Дата:
Сообщение: Re: does wal archiving block the current client connection?