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

Re: pg_retainxlog for inclusion in 9.3?

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_retainxlog for inclusion in 9.3?
Date: 2013-01-14 10:03:19
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Sat, Jan 5, 2013 at 3:11 PM, Magnus Hagander <magnus(at)hagander(dot)net> wrote:
> On Fri, Jan 4, 2013 at 7:13 PM, Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
>> On 1/3/13 12:30 PM, Robert Haas wrote:
>>> On Thu, Jan 3, 2013 at 11:32 AM, Magnus Hagander <magnus(at)hagander(dot)net> wrote:
>>>> Any particular reason? It goes pretty tightly together with
>>>> pg_receivexlog, which is why I'd prefer putting it alongside that one.
>>>> But if you have a good argument against it, I can change my mind :)
>>> Mostly that it seems like a hack, and I suspect we may come up with a
>>> better way to do this in the future.
>> It does seem like a hack.  Couldn't this be implemented with a backend
>> switch instead?
> It definitely is a bit of a hack.
> I assume by backend switch you mean guc, right? If so, no, not easily
> so. Because it's the archiver process that does the deleting. And this
> process does not have access to a "full backend interface", e.g. the
> ability to run a query. We could make it look at the same data that's
> currently shown in pg_stat_replicatoin through shared memory, but thta
> would *only* work in the very most simple cases (e.g. a single
> pg_receivexlog and no other replication). The ability to run a custom
> SQL query is going to be necessary for anything a bit more advanced.
>> Also, as a small practical matter, since this is a server-side program
>> (since it's being used as archive_command), we shouldn't put it into the
>> pg_basebackup directory, because that would blur the lines about what to
>> install where, in particular for the translations.
> Good argument. That along with the being a hack, and the comment from
> Robert, means that maybe contrib/ is a better place for it, yes.

Here's a version for inclusion in /contrib.

 Magnus Hagander

Attachment: pg_retainxlog.diff
Description: application/octet-stream (16.1 KB)

In response to


pgsql-hackers by date

Next:From: Abhijit Menon-SenDate: 2013-01-14 10:55:01
Subject: common fe/be library (was Re: [PATCH] binary heap implementation)
Previous:From: Dean RasheedDate: 2013-01-14 09:29:56
Subject: Thinking about WITH CHECK OPTION for views

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