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

Re: [FEATURE REQUEST] Streaming Onlinebackup (Maybe OFFTOPIC)

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Florian G(dot) Pflug" <fgp(at)phlo(dot)org>
Cc: "Simon Riggs" <simon(at)2ndquadrant(dot)com>,"Jeff Davis" <pgsql(at)j-davis(dot)com>,<pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [FEATURE REQUEST] Streaming Onlinebackup (Maybe OFFTOPIC)
Date: 2007-09-27 14:28:22
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
>>> On Wed, Sep 26, 2007 at  7:29 PM, in message <46FAF95D(dot)6070003(at)phlo(dot)org>,
"Florian G. Pflug" <fgp(at)phlo(dot)org> wrote: 
> Kevin Grittner wrote:
>> I omitted the code I was originally considering to have it work against
>> files "in place" rather than as a filter.  It seemed much simpler this
>> way, we didn't actually have a use case for the additional functionality,
>> and it seemed safer as a filter.  Thoughts?
> A special "non-filter" mode could save some IO and diskspace by not actually 
> writing all those zeros, but instead just seek to SizeOfWal-1 after writing 
> the 
> last valid byte, and writing one more zero. Of course, if you're gonna
> compress the WAL anyway, there is no point...
Right.  And if you're not, why bother setting to zero?  I couldn't invent
a plausible scenario where we would want to do the update in place, and
I'm afraid someone might be tempted to run it against "live" WAL files.
So I decided it was best to let it lie unless someone else had a real-
life situation where it was useful.  Even then, I could write a bash
script to do it using the filter a lot faster than I could modify the C
code to safely deal with the files in-place, so I'm pretty skeptical.

In response to

pgsql-hackers by date

Next:From: Tom LaneDate: 2007-09-27 14:51:59
Subject: Re: Assertion failure due to ColumnRefStar
Previous:From: Heikki LinnakangasDate: 2007-09-27 14:23:05
Subject: Re: Assertion failure due to ColumnRefStar

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