Skip site navigation (1) Skip section navigation (2)

Re: could not truncate directory "pg_subtrans": apparent wraparound

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: (view raw, whole thread or download thread mbox)
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/ "%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



In response to


pgsql-admin by date

Next:From: Simon RiggsDate: 2010-05-26 06:28:53
Subject: Re: could not truncate directory "pg_subtrans": apparent wraparound
Previous:From: Samuel StearnsDate: 2010-05-25 23:09:41
Subject: Re: transaction_timestamp()

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group