Tom Lane wrote:
> "Kevin Grittner" <[EMAIL PROTECTED]> writes:
> > As I understand it, the log space accumulates for the oldest transaction
> > which is still running, and all transactions which started after it.
>
> No, pg_xlog can be truncated as soon as a checkpoint occurs. If Jeremy
> wasn't
On Fri, Dec 22, 2006 at 07:47:05PM +0100, ohp@pyrenet.fr wrote:
>> No, pg_xlog can be truncated as soon as a checkpoint occurs.
> Even for currently running transactions ?
Isn't that the entire point of having checkpoints in the first place? :-)
/* Steinar */
--
Homepage: http://www.sesse.net/
ohp@pyrenet.fr wrote:
> On Fri, 22 Dec 2006, Tom Lane wrote:
>
> > Date: Fri, 22 Dec 2006 13:14:18 -0500
> > From: Tom Lane <[EMAIL PROTECTED]>
> > To: Kevin Grittner <[EMAIL PROTECTED]>
> > Cc: Jeremy Haile <[EMAIL PROTECTED]>, pgsql-performance@postgresql.org
> > Subject: Re: [PERFORM] URGENT: O
ohp@pyrenet.fr writes:
> On Fri, 22 Dec 2006, Tom Lane wrote:
>> No, pg_xlog can be truncated as soon as a checkpoint occurs.
> Even for currently running transactions ?
Yes.
regards, tom lane
---(end of broadcast)---
TIP 1
On Fri, 22 Dec 2006, Tom Lane wrote:
> Date: Fri, 22 Dec 2006 13:14:18 -0500
> From: Tom Lane <[EMAIL PROTECTED]>
> To: Kevin Grittner <[EMAIL PROTECTED]>
> Cc: Jeremy Haile <[EMAIL PROTECTED]>, pgsql-performance@postgresql.org
> Subject: Re: [PERFORM] URGENT: Out of disk space pg_xlog
>
> "Kevin
"Kevin Grittner" <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> wrote:
>> before the system crash? The scenario we've seen in the past is
>>
>> * data partition out of space, so writes fail
>> * each time Postgres attempts a checkpoint, writes fail, so the
>> checkpoint fails. No da
>>> On Fri, Dec 22, 2006 at 12:14 PM, in message
<[EMAIL PROTECTED]>,
Tom Lane <[EMAIL PROTECTED]> wrote:
> "Kevin Grittner" <[EMAIL PROTECTED]> writes:
>> As I understand it, the log space accumulates for the oldest
transaction
>> which is still running, and all transactions which started after
i
"Kevin Grittner" <[EMAIL PROTECTED]> writes:
> As I understand it, the log space accumulates for the oldest transaction
> which is still running, and all transactions which started after it.
No, pg_xlog can be truncated as soon as a checkpoint occurs. If Jeremy
wasn't using archive_command then t
checkpoint_segments has been set at 12 for a while and was never set
higher than that. (before that it was set to the PG default - 3 I think)
Before the server crashed I was running an update that updates a boolean
flag on two large tables (10 million rows each) for transactions older
than today (
On Fri, 2006-12-22 at 12:30 -0500, Jeremy Haile wrote:
> The archive_status directory is empty. I've never seen any files in
> there and I've never set archive_command.
>
> Well, the problem has since resolved, but here is what is in the
> directory now. Previously there were hundreds of files,
The archive_status directory is empty. I've never seen any files in
there and I've never set archive_command.
Well, the problem has since resolved, but here is what is in the
directory now. Previously there were hundreds of files, but these
disappeared after Postgres performed the automatic reco
As I understand it, the log space accumulates for the oldest transaction
which is still running, and all transactions which started after it. I
don't think there is any particular limit besides available disk space.
Long running transactions can cause various problems, including table
and index b
On Fri, 2006-12-22 at 11:52 -0500, Jeremy Haile wrote:
> I would still appreciate ... explaining how to estimate size for a
> pg_xlog partition. It seems like it can vary considerably depending on
> how intensive your current transactions are. Is there a way to
> determine a maximum?
There shou
> 2006-12-22 10:50:09 LOG: database system was not properly shut down;
> automatic recovery in progress
> 2006-12-22 10:50:09 LOG: redo starts at 2E/8729A6E8
>
>
> This has been running for 20 minutes. What can I do? Please help!
1. Turn off postgresql.
2. Make tar backup of entire thing
3.
Sorry for my rushed posting, as I was in a bit of a panic.
We moved the pg_xlog directory over to a 70GB partition, and after 15-20
minutes the automatic recovery finished. Everything is working fine
now.
I would still appreciate a PG guru explaining how to estimate size for a
pg_xlog partition.
I created a 10GB partition for pg_xlog and ran out of disk space today
during a long running update. My checkpoint_segments is set to 12, but
there are 622 files in pg_xlog. What size should the pg_xlog partition
be?
Postmaster is currently not starting up (critical for my organization)
and re
16 matches
Mail list logo
