From: Tom Lane <tgl@sss.pgh.pa.us>
To: Christian Ullrich <chris@chrullrich.net>
cc: pgsql-admin@postgresql.org
Subject: Re: Why does the WAL writer sit on completed segments (on Windows)?
In-reply-to: <od2lad$df0$1@blaine.gmane.org>
References: <od2lad$df0$1@blaine.gmane.org>
Comments: In-reply-to Christian Ullrich <chris@chrullrich.net>
	message dated "Mon, 17 Apr 2017 17:00:35 +0200"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <17212.1492442911.1@sss.pgh.pa.us>
Date: Mon, 17 Apr 2017 11:28:31 -0400
Message-ID: <17213.1492442911@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-admin-owner@postgresql.org

Christian Ullrich <chris@chrullrich.net> writes:
> The reason, as Process Monitor shows, is that the WAL writer process 
> keeps the file open for about one second after the 
> archive_status\*.ready file has been created. The archiver runs the 
> archive_command "too early", resulting in the sharing [1] violation seen 
> above.

I'm not sure why that happens, but even if we changed the logic inside
walwriter to avoid it, you'd still need to adapt your archiving script
to deal with the case.  The reason is that the walwriter isn't necessarily
the only process writing WAL --- regular backends do it too, depending on
timing.  In such a case a backend would be holding an open-file reference
until the next time it tries to write WAL, which might be awhile.  It's
not really practical to change that behavior; we certainly wouldn't want
to open and close WAL files for every write.

			regards, tom lane


-- 
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin