Tom Lane wrote:
Greg Smith [EMAIL PROTECTED] writes:
That pushes the problem of writing a little chunk of code that reads only
the right amount of data and doesn't bother compressing the rest onto the
person writing the archive command. Seems to me that leads back towards
wanting to
Jason Long wrote:
Greg Smith wrote:
On Thu, 30 Oct 2008, Tom Lane wrote:
The real reason not to put that functionality into core (or even
contrib) is that it's a stopgap kluge. What the people who want this
functionality *really* want is continuous (streaming) log-shipping, not
If Pg truncated the WAL files before calling archive_command, and would
accept truncated WAL files on restore, that'd be really useful.
On second thought - that'd prevent reuse of WAL files, or at least force
the filesystem to potentially allocate new storage for the part that was
On 31 okt 2008, at 02.18, Greg Smith [EMAIL PROTECTED] wrote:
On Thu, 30 Oct 2008, Tom Lane wrote:
The real reason not to put that functionality into core (or even
contrib) is that it's a stopgap kluge. What the people who want this
functionality *really* want is continuous (streaming)
* Greg Smith [EMAIL PROTECTED] [081001 00:00]:
The overhead of clearing out the whole thing is just large enough that it
can be disruptive on systems generating lots of WAL traffic, so you don't
want the main database processes bothering with that. A related fact is
that there is a
* Aidan Van Dyk [EMAIL PROTECTED] [081031 15:11]:
Archiving 00010012
Archiving 00010013
Archiving 00010014
Archiving 00010017
Archiving 00010018
Archiving
* Aidan Van Dyk [EMAIL PROTECTED] [081031 15:11]:
How about something like the attached. It's been spun quickly, passed
regression tests, and some simple hand tests on REL8_3_STABLE. It seem slike
HEAD can't initdb on my machine (quad opteron with SW raid1), I tried a few
revision in the
On Wed, 2008-10-29 at 09:05 -0400, Greg Smith wrote:
On Tue, 28 Oct 2008, Jason Long wrote:
I also have to ship them off site using a T1 so setting the time to
automatically switch files will just waste bandwidth if they are still
going
to be 16 MB anyway.
The best way to handle
On Thu, 30 Oct 2008, Joshua D. Drake wrote:
This reminds me yet again that pg_clearxlogtail should probably get added
to the next commitfest for inclusion into 8.4; it's really essential for a
WAN-based PITR setup and it would be nice to include it with the
distribution.
What is to be gained
Greg Smith wrote:
On Thu, 30 Oct 2008, Joshua D. Drake wrote:
This reminds me yet again that pg_clearxlogtail should probably get
added
to the next commitfest for inclusion into 8.4; it's really essential
for a
WAN-based PITR setup and it would be nice to include it with the
distribution.
Greg Smith wrote:
there's no chance it can accidentally look like a valid segment. But
when an existing segment is recycled, it gets a new header and that's
it--the rest of the 16MB is still left behind from whatever was in that
segment before. That means that even if you only write, say,
Kyle Cordes wrote:
Greg Smith wrote:
there's no chance it can accidentally look like a valid segment. But
when an existing segment is recycled, it gets a new header and that's
it--the rest of the 16MB is still left behind from whatever was in
that segment before. That means that even if
On Thu, 30 Oct 2008, Kyle Cordes wrote:
It sure would be nice if there was a way for PG itself to zero the unused
portion of logs as they are completed, perhaps this will make it in as part
of the ideas discussed on this list a while back to make a more out of the
box log-ship mechanism?
Greg Smith wrote:
On Thu, 30 Oct 2008, Kyle Cordes wrote:
It sure would be nice if there was a way for PG itself to zero the
unused portion of logs as they are completed, perhaps this will make
The overhead of clearing out the whole thing is just large enough that
it can be disruptive on
Greg Smith [EMAIL PROTECTED] writes:
Now, it would be possible to have that less sensitive archive code path zero
things out, but you'd need to introduce a way to note when it's been done (so
you don't do it for a segment twice) and a way to turn it off so everybody
doesn't go through that
On Oct 30, 2008, at 2:54 PM, Gregory Stark wrote:
Wouldn't it be just as good to indicate to the archive command the
amount of
real data in the wal file and have it only bother copying up to
that point?
Hm! Interesting question: Can the WAL files be truncated, rather
than zeroed,
Gregory Stark wrote:
Greg Smith [EMAIL PROTECTED] writes:
Wouldn't it be just as good to indicate to the archive command the amount of
real data in the wal file and have it only bother copying up to that point?
That sounds like a great solution to me; ideally it would be done in a
way that
On Thu, 30 Oct 2008, Gregory Stark wrote:
Wouldn't it be just as good to indicate to the archive command the amount of
real data in the wal file and have it only bother copying up to that point?
That pushes the problem of writing a little chunk of code that reads only
the right amount of
Greg Smith [EMAIL PROTECTED] writes:
That pushes the problem of writing a little chunk of code that reads only
the right amount of data and doesn't bother compressing the rest onto the
person writing the archive command. Seems to me that leads back towards
wanting to bundle a contrib
On Thu, 30 Oct 2008, Tom Lane wrote:
The real reason not to put that functionality into core (or even
contrib) is that it's a stopgap kluge. What the people who want this
functionality *really* want is continuous (streaming) log-shipping, not
WAL-segment-at-a-time shipping.
Sure, and that's
Greg Smith wrote:
On Thu, 30 Oct 2008, Tom Lane wrote:
The real reason not to put that functionality into core (or even
contrib) is that it's a stopgap kluge. What the people who want this
functionality *really* want is continuous (streaming) log-shipping, not
WAL-segment-at-a-time shipping.
Jason Long wrote:
Sure I would rather have synchronous WAL shipping, but if that is going
to be a while or synchronous would slow down my applicaton I can get
comfortably close enough for my purposes with some highly compressible
WALs.
I'm way out here on the outskirts (just a user with a
Jason Long wrote:
I am planning on setting up PITR for my application.
I also have to ship them off site using a T1 so setting the time to
automatically switch files will just waste bandwidth if they are still
going to be 16 MB anyway.
*1. What is the effect of recompiling and reducing
On Tue, 28 Oct 2008, Jason Long wrote:
I also have to ship them off site using a T1 so setting the time to
automatically switch files will just waste bandwidth if they are still going
to be 16 MB anyway.
The best way to handle this is to clear the unused portion of the WAL file
and then
I am planning on setting up PITR for my application.
It does not see much traffic and it looks like the 16 MB log files
switch about every 4 hours or so during business hours.
I am also about to roll out functionality to store documents in a bytea
column. This should make the logs roll
25 matches
Mail list logo
