Re: pg_retainxlog for inclusion in 9.3?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Magnus Hagander <magnus(at)hagander(dot)net>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, 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-24 17:25:18
Message-ID: 20700.1359048318@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Magnus Hagander <magnus(at)hagander(dot)net> writes:
> On Thu, Jan 24, 2013 at 6:04 PM, Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
>> I think it might be better to just document this as an example. I don't
>> quite see the overhead of maintaining another tool justified.

> Well, obviously I don't entirely agree ;)

> Yes, it's a convenience command. Like pg_standby was. And like many
> other commands that we maintain as part of *core*, such as createuser,
> vacuumdb, etc. Those can all be done with an even *simpler* command
> than the one you suggest above. So I don't see that as an argument why
> it wouldn't be useful.

We've discussed removing a lot of those tools, too. Not breaking
backwards compatibility is probably the only reason they're still there.

In the case at hand, I seem to recall from upthread that we expect
this'd be obsolete in a release or two. If that's true then I think
a para or two of documentation is a better idea than a tool we'll be
essentially condemned to keep maintaining forever.

> Also, the command you suggest above does not work on Windows. You can
> probably write a .BAT file to do it for you, but I'm pretty sure it's
> impossible to do it as an archive_command there.

Perhaps we could whip up such a .BAT file and put it in the docs?

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Magnus Hagander 2013-01-24 17:28:28 Re: pg_retainxlog for inclusion in 9.3?
Previous Message Andres Freund 2013-01-24 17:24:42 Re: Proposal for Allow postgresql.conf values to be changed via SQL [review]