Zeugswetter Andreas ADI SD wrote:
> > > The probably useful next step would be to pass the current length to
> > > archive_command,
> > > so it can write the filled part of the file without the need for a
> > > filter.
> > I can see that helping a lot, but not by writing onto the file on
> > If the file is nearly empty, that would be a lot of disk I/O which
> > need to happen.
> I think you misunderstood what I meant.
> The actual archive command is constructed by expanding certain
> I am suggesting to add such a placeholder for the size of the filled
> part of the log.
> A hypothetical example (note suggested %b placeholder for size in
> archive_command=dd if=%p of=/backup/WAL/%f bs=1 count=%b
> This allows to avoid unnecessary io for the backup of partially filled
A nice improvement on that would be to have a "rearchive_command" to
allow to sync the new bytes written since a previous archive_command (so
it needs a new placeholder "start from this byte"). This allows writing
dd seek=%s skip=%s count=%b bs=1
(I had suggested something like this when PITR was just invented, but it
was disregarded because it was too complex for the first cut or the
Alvaro Herrera http://www.amazon.com/gp/registry/DXLWNGRJD34J
"Sallah, I said NO camels! That's FIVE camels; can't you count?"
In response to
pgsql-hackers by date
|Next:||From: Zeugswetter Andreas ADI SD||Date: 2007-09-28 13:44:36|
|Subject: Re: [FEATURE REQUEST] Streaming Onlinebackup (MaybeOFFTOPIC)|
|Previous:||From: Pavel Stehule||Date: 2007-09-28 12:46:36|
|Subject: Re: proposal casting from XML to int, numeric, text|