Received: from maia.hub.org (maia-2.hub.org [200.46.204.251]) by mail.postgresql.org (Postfix) with ESMTP id D11E51668E70 for ; Mon, 14 Nov 2011 17:41:28 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.251]) (amavisd-maia, port 10024) with ESMTP id 01815-07 for ; Mon, 14 Nov 2011 21:41:22 +0000 (UTC) X-Greylist: delayed 00:07:32.050581 by SQLgrey-1.8.0-rc2 Received: from makus.postgresql.org (makus.postgresql.org [98.129.198.125]) by mail.postgresql.org (Postfix) with ESMTP id 7F92A1668E6D for ; Mon, 14 Nov 2011 17:41:22 -0400 (AST) Received: from smtp.peak6.com ([38.98.137.6]) by makus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1RQ4A1-0003El-Ao for pgsql-performance@postgresql.org; Mon, 14 Nov 2011 21:33:49 +0000 X-AuditID: 0a64cb1e-b7c21ae0000074d4-10-4ec1892b517a Message-ID: <4EC1892F.2050506@peak6.com> Date: Mon, 14 Nov 2011 15:33:35 -0600 From: Shaun Thomas Reply-To: Organization: Peak6 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: CC: "pgsql-performance@postgresql.org" Subject: Re: Using incrond for archiving References: <4EBD9FDE.4000104@peak6.com> In-Reply-To: <4EBD9FDE.4000104@peak6.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed content-transfer-encoding: 7bit X-Originating-IP: [10.10.220.61] X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrMIsWRmVeSWpSXmKPExsXCxcQrpqvdedDPYP9vPYvrM88xOzB6XNg3 jT2AMaqB0SYxLy+/JLEkVSEltTjZVinA1dHbTMElszg5JzEzN7VISSEzxVbJTEmhICcxOTU3 Na/EVimxoCA1L0XJjksBA9gAlWXmKaTmJeenZOal2yp5BvvrWliYWuoaKtnFYwEJTSwZs26u YC6YJFzx+8oe1gbGV/xdjJwcEgImEr/a/jNC2GISF+6tZ+ti5ODgFdCQWLspASTMIqAqsWfj dyYQm01ATWLh7ptg5UICshL7V51jBbH5BYQl9n1oYgaxRQVCJJ5NeM4GYvMKCEqcnPmEBcQW ERCX2LbiPzuIzSzgKdFxahXYHGEBI4kHn2azQczUkDi57ypYPaeApsT1p9eZIeptJS7Muc4C YctLbH87hxmiXk7iTsNzsJMlBBQkri/3n8AoNAvJ5llIumch6V7AyLyKUby4LDE5I9O0oDi3 pMBQryA1MdtMLy+1ZBMjKEJTTsvtYJy+VPEQowAHoxIPr1L4QT8h1sSy4srcQ4wSHMxKIrxB ZUAh3pTEyqrUovz4otKc1OJDjKbAIJvILCWanA9MHnkl8YbGhpamlsZmBkYmlhZK4rzvn23z ExJIByaG7NTUgtQimD4mDk6pBsbkOYbV4QV/1OdMOJT74aX16vLfK//uv6rR82DfT4lviU+Y q+WeevvWXuw/fvnjat+ZR/9NXhnP/F3C7Nfx2ini63/8q6/IaSjzZHR+fq7d7zCL+6cwjaoE g+1BS2236F9UW7PK8OOdpcx95SsWXlyZkZxw+FpkjqLbYgdjhm/yyySj/m9bnv1KiaU4I9FQ i7moOBEAuxs7/eYCAAA= X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.9 tagged_above=-10 required=5 tests=BAYES_00=-1.9 X-Spam-Level: X-Archive-Number: 201111/167 X-Sequence-Number: 45678 On 11/11/2011 04:21 PM, Shaun Thomas wrote: > So my real question: is this safe? So to answer my own question: no, it's not safe. The PG backends apparently write to the xlog files periodically and *close* them after doing so. There's no open filehandle that gets written until the file is full and switched to the next one. Knowing that, I used pg_xlogfile_name(pg_current_xlog_location()) to get the most recent xlog file, and wrote a small script incrond would launch. In the script, it gets the current xlog, and will refuse to copy that one. What I don't quite understand is that after calling pg_xlog_switch(), it will sometimes still write to an old xlog several minutes later. Here's an example (0069 is the current xlog): 2011-11-14 15:05:01 : 0000000200000ED500000069 : xlog : too current 2011-11-14 15:05:06 : 0000000200000ED500000069 : xlog : too current 2011-11-14 15:05:20 : 0000000200000ED500000069 : xlog : too current 2011-11-14 15:06:01 : 0000000200000ED500000069 : xlog : too current 2011-11-14 15:06:06 : 0000000200000ED500000069 : xlog : too current 2011-11-14 15:06:06 : 0000000200000ED500000069 : xlog : too current 2011-11-14 15:06:37 : 0000000200000ED500000069 : xlog : too current 2011-11-14 15:06:58 : 0000000200000ED500000045 : xlog : copying 2011-11-14 15:07:01 : 0000000200000ED500000069 : xlog : too current 2011-11-14 15:07:06 : 0000000200000ED500000069 : xlog : too current 2011-11-14 15:07:08 : 0000000200000ED500000069 : xlog : too current 2011-11-14 15:07:20 : 0000000200000ED500000064 : xlog : copying 2011-11-14 15:07:24 : 0000000200000ED500000014 : xlog : copying 2011-11-14 15:07:39 : 0000000200000ED500000069 : xlog : too current 2011-11-14 15:07:45 : 0000000200000ED500000061 : xlog : copying 2011-11-14 15:08:01 : 0000000200000ED500000069 : xlog : too current Why on earth is it sending IN_CLOSE_WRITE messages for 0014, 1145, and 0061? Is that just old threads closing their old filehandles after they realize they can't write to that particular xlog? Either way, adding lsof or (ironically much faster pg_current_xlog_location) checking for the most recent xlog to ignore, I can "emulate" PG archive mode using an asynchronous background process. On another note, watching kernel file IO messages is quite fascinating. -- Shaun Thomas OptionsHouse | 141 W. Jackson Blvd. | Suite 800 | Chicago IL, 60604 312-676-8870 sthomas@peak6.com ______________________________________________ See http://www.peak6.com/email_disclaimer/ for terms and conditions related to this email