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
> > wa
* 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 t
* Aidan Van Dyk <[EMAIL PROTECTED]> [081031 15:11]:
> Archiving 00010012
> Archiving 00010013
> Archiving 00010014
> Archiving 00010017
> Archiving 00010018
> Archiving 00010
* 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
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) log-
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
truncated.
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
WAL-segment-at
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
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.
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 w
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, 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 data
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 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, safely?
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 th
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 s
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?
T
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 you
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, 1M
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.
W
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 o
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
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 comp
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 the
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 faster.
25 matches
Mail list logo
