Dimitri Fontaine <dfontaine(at)hi-media(dot)com> writes:
> Also, should I try to send a patch implementing my proposal (internal
> command exposed as a function at the SQL level, and while at it, maybe
> the internal command "pg_archive_bypass" to mimic /usr/bin/true as an
I had to have a try at it, even if quick and dirty. I've not tried to
code the pg_archive_bypass internal command for lack of discussion, but
I still think it would be great to have it.
So here's a "see my idea in code" patch, that put the previous code by
Simon into a backend function. As the goal was not to adapt the existing
code intended as external to use the internal APIs, you'll find it quite
ugly I'm sure.
For example, this #define XLOG_DATA_FNAME_LEN has to go away, but that
won't help having the idea accepted or not, and as I'm only warming up,
I didn't tackle the problem. If you want me to do it, I'd appreciate
some guidance as how to, though.
It goes like this:
dim=# select pg_switch_xlog();
dim=# select pg_archive_cleanup('0/1000098');
DEBUG: removing "pg_xlog/000000010000000000000000"
DEBUG: removing "pg_xlog/000000010000000000000001"
I hope you too will find this way of interfacing is easier to deal with
for everybody (from code maintenance to user settings).
In response to
pgsql-hackers by date
|Next:||From: Bruce Momjian||Date: 2010-06-13 01:08:17|
|Subject: Re: [PERFORM] Large (almost 50%!) performance drop after
upgrading to 8.4.4?|
|Previous:||From: Dimitri Fontaine||Date: 2010-06-12 18:00:03|
|Subject: Re: Command to prune archive at restartpoints|