From: | Mikko Partio <mpartio(at)gmail(dot)com> |
---|---|
To: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-admin(at)postgresql(dot)org |
Subject: | Re: could not truncate directory "pg_subtrans": apparent wraparound |
Date: | 2010-05-26 06:01:41 |
Message-ID: | AANLkTilMgQHt9h4lO_Nj8j32bQtEWNuogt4vEbNkce6B@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
On Mon, May 24, 2010 at 10:55 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> On Mon, 2010-05-24 at 08:46 +0300, Mikko Partio wrote:
>
> > It was freshly initdb'd with beta1 binaries, the contents were loded
> > from a pg_dump file. The number of transactions is very small, we're
> > talking about thousands (not billions). This database is the master of
> > a hot standby installation, if that matters.
>
> Have you ever performed a switchover operation? If you've never run an
> extended recovery on that server, its less likely to be anything HS
> related.
>
> Are you running any special hot standby parameters?
With this database instance (beta1 initdb'd) I have not made failovers. I
don't think I have any special hot standby parameters either.
Non-default hot standby related configuration options (master database):
wal_level = hot_standby # minimal, archive, or hot_standby
archive_mode = on # allows archiving to be done
archive_command = '/postgresql/bin/archive_wal.sh "%p" "%f"' #
command to use to archive a logfile segment
archive_timeout = 3600 # force a logfile segment switch after this
hot_standby = off # allows queries during recovery
max_wal_senders = 3 # max number of walsender processes
wal_keep_segments = 10 # in logfile segments, 16MB each; 0 disables
Regards
Mikko
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2010-05-26 06:28:53 | Re: could not truncate directory "pg_subtrans": apparent wraparound |
Previous Message | Samuel Stearns | 2010-05-25 23:09:41 | Re: transaction_timestamp() |