Jeff Janes wrote:
> Kevin Grittner wrote:
>> We pipe the file into pg_clearxlogtail | gzip and pipe it out to
>> the archive directory (with a ".gz" suffix), rather than using cp
>> and processing it later. Well, actually, we pipe it to a
>> directory on the same mount point as the archive dir
On Tue, Sep 11, 2012 at 5:36 AM, Kevin Grittner
wrote:
> Jeff Janes wrote:
>> Kevin Grittner wrote:
>
>>> BTW, that's also why I wrote the pg_clearxlogtail utility (source
>>> code on pgfoundry). We pipe our archives through that and gzip
>>> which changes this to an endless stream of 16KB files
Jeff Janes wrote:
> Kevin Grittner wrote:
>> Jeff Janes wrote:
>>> So a server that is completely free of user activity will still
>>> generate an endless stream of WAL files, averaging one file per
>>> max(archive_timeout, checkpoint_timeout). That comes out to one
>>> 16MB file per hour (sin
On Thu, Aug 16, 2012 at 9:30 AM, Kevin Grittner
wrote:
> Jeff Janes wrote:
>
>> So a server that is completely free of
>> user activity will still generate an endless stream of WAL files,
>> averaging one file per max(archive_timeout, checkpoint_timeout).
>> That comes out to one 16MB file per ho
Jeff Janes wrote:
> archive_timeout and checkpoint_timeout have a pernicious
> interaction. Each one individually suppresses needless
> operations, i.e. not checkpointing if no WAL was written since
> last checkpoint, and not log-switching if no WAL was written since
> the last log-switch. But
I have a database that only receives updates maybe a few times a week.
It is the storage for some web content where the content is not
changed very often.
I set archive_timeout to 5 minutes, because when an update is made I
would like the log that contains that change to get archived fairly
soon,
"Thomas F.O'Connell" <[EMAIL PROTECTED]> writes:
> "This option can only be set at server start or in the postgresql.conf
> file."
> Perhaps I've been misunderstanding the "or" clause? Does the "or"
> clause refer to the fact that it can be sent as an option at server
> start or changed with a
Both the 7.4.x docs and the 8.0.x docs state:
"This option can only be set at server start or in the postgresql.conf
file."
Perhaps I've been misunderstanding the "or" clause? Does the "or"
clause refer to the fact that it can be sent as an option at server
start or changed with a HUP from post
Greg Stark wrote:
> Bruce Momjian writes:
>
> > I don't see something that happens every five minutes as any kind of
> > performance problem. I am not sure what Josh saw that made him want to
> > increase that.
>
> I would have thought checkpoint_timeout would be something you would adjust
> d
Bruce Momjian writes:
> I don't see something that happens every five minutes as any kind of
> performance problem. I am not sure what Josh saw that made him want to
> increase that.
I would have thought checkpoint_timeout would be something you would adjust
depending on whether you want even
"Thomas F.O'Connell" <[EMAIL PROTECTED]> writes:
> Instinctively, it seems like it would be nice to have something similar
> for checkpoint_timeout, but is there any disadvantage to having a value
> "dramatically" higher than the default for general use, considering
> that checkpoint_timeout can
Thomas F.O'Connell wrote:
> In the annotated conf file for 8.0, Josh Berkus notes that
> checkpoint_timeout should be increased "dramatically" for large data
> loads. For settings like sort_mem (now work_mem), it's been convenient
> to be able to have a default setting for standard work and a
>
In the annotated conf file for 8.0, Josh Berkus notes that
checkpoint_timeout should be increased "dramatically" for large data
loads. For settings like sort_mem (now work_mem), it's been convenient
to be able to have a default setting for standard work and a
per-connection configuration option
13 matches
Mail list logo
