--0016e68ee2bdcebb000486ebe324
Content-Type: text/plain; charset=ISO-8859-1

Hi

got the following line at postgresql log:

May 16 01:17:35 xxx postgres[25550]: [1-1] LOG: could not truncate
directory "pg_subtrans": apparent wraparound

I assume this does not refer to xid wraparound? Should I be worried?

Database has only a few users and probably noone accessed it during those
hours. No other relevant lines were in the log, no crashes etc have occured.

postgres=# select version();
version

------------------------------------------------------------ ----------------------------------------------------------
PostgreSQL 9.0beta1 on x86_64-unknown-linux-gnu, compiled by GCC gcc (GCC)
4.1.2 20080704 (Red Hat 4.1.2-46), 64-bit


Regards

Mikko

--0016e68ee2bdcebb000486ebe324
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi<div><br></div><div>got the following line at postgresql log:</div><div><=
br></div><div><div>May 16 01:17:35 xxx postgres[25550]: [1-1] LOG: =A0could=
not truncate directory "pg_subtrans": apparent wraparound</div>
</div><div><br></div><div>I assume this does not refer to xid wraparound? S=
hould I be worried?</div><div><br></div><div>Database has only a few users =
and probably noone accessed it during those hours. No other relevant lines =
were in the log, no crashes etc have occured.</div>
<div><br></div><div><div>postgres=3D# select version();</div><div>=A0=A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
=A0 =A0 =A0 =A0 =A0 =A0 =A0 version =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
</div><div> ------------------------------------------------------------ ----=
------------------------------------------------------</div>
<div>=A0PostgreSQL 9.0beta1 on x86_64-unknown-linux-gnu, compiled by GCC gc=
c (GCC) 4.1.2 20080704 (Red Hat 4.1.2-46), 64-bit</div></div><div><br></div=
><div><br></div><div>Regards</div><div><br></div><div>Mikko</div>

--0016e68ee2bdcebb000486ebe324--

On Wed, May 19, 2010 at 08:40:04AM +0300, Mikko Partio wrote:
>
> May 16 01:17:35 xxx postgres[25550]: [1-1] LOG: could not truncate
> directory "pg_subtrans": apparent wraparound
>

http://archives.postgresql.org/pgsql-general/2007-06/msg0105 0.php

--
Sent via pgsql-admin mailing list (pgsql-admin [at] postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin

Mikko Partio <mpartio [at] gmail.com> writes:
> got the following line at postgresql log:
> May 16 01:17:35 xxx postgres[25550]: [1-1] LOG: could not truncate
> directory "pg_subtrans": apparent wraparound

What's in $PGDATA/pg_subtrans?

regards, tom lane

--
Sent via pgsql-admin mailing list (pgsql-admin [at] postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin

--0016e68ef09672988a0486ff0fa2
Content-Type: text/plain; charset=ISO-8859-1

On Wed, May 19, 2010 at 10:01 PM, Tom Lane <tgl [at] sss.pgh.pa.us> wrote:

> Mikko Partio <mpartio [at] gmail.com> writes:
> > got the following line at postgresql log:
> > May 16 01:17:35 xxx postgres[25550]: [1-1] LOG: could not truncate
> > directory "pg_subtrans": apparent wraparound
>
> What's in $PGDATA/pg_subtrans?
>
>
$ ls -l $PGDATA/pg_subtrans
total 228
-rw------- 1 postgres dba 229376 May 20 07:27 000E


Regards

Mikko

--0016e68ef09672988a0486ff0fa2
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br><div class=3D"gmail_quote">On Wed, May 19, 2010 at 10:01 PM, Tom La=
ne <span dir=3D"ltr"><<a href=3D"mailto:tgl [at] sss.pgh.pa.us">tgl [at] sss.pgh.p=
a.us</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class=3D"im">Mikko Partio <<a href=3D"mailto:mpartio [at] gmail.com">mpa=
rtio [at] gmail.com</a>> writes:<br>
> got the following line at postgresql log:<br>
> May 16 01:17:35 xxx postgres[25550]: [1-1] LOG: =A0could not truncate<=
br>
> directory "pg_subtrans": apparent wraparound<br>
<br>
</div>What's in $PGDATA/pg_subtrans?<br><br></blockquote><div><br></div=
><div>$ ls -l $PGDATA/pg_subtrans</div><div>total 228</div><div>-rw------- =
1 postgres dba 229376 May 20 07:27 000E</div><div><br></div><div><br></div>
<div>Regards</div><div><br></div><div>Mikko=A0</div></div>

--0016e68ef09672988a0486ff0fa2--

--0016e68ee4694483a40486ff278e
Content-Type: text/plain; charset=ISO-8859-1

On Wed, May 19, 2010 at 3:21 PM, Ray Stell <stellr [at] cns.vt.edu> wrote:

> On Wed, May 19, 2010 at 08:40:04AM +0300, Mikko Partio wrote:
> >
> > May 16 01:17:35 xxx postgres[25550]: [1-1] LOG: could not truncate
> > directory "pg_subtrans": apparent wraparound
> >
>
> http://archives.postgresql.org/pgsql-general/2007-06/msg0105 0.php
>


Browsing through that thread I can see that I have similar symptoms:

$ pg_controldata | grep Multi
Latest checkpoint's NextMultiXactId: 1
Latest checkpoint's NextMultiOffset: 0

$ ls -l $PGDATA/pg_multixact/members
total 8
-rw------- 1 postgres dba 8192 May 3 08:21 0000

$ ls -l $PGDATA/pg_multixact/offsets
total 8
-rw------- 1 postgres dba 8192 May 3 08:49 0000

I don't see any resolution to that thread though.

Regards

Mikko

--0016e68ee4694483a40486ff278e
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br><div class=3D"gmail_quote">On Wed, May 19, 2010 at 3:21 PM, Ray Ste=
ll <span dir=3D"ltr"><<a href=3D"mailto:stellr [at] cns.vt.edu">stellr [at] cns.vt=
..edu</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class=3D"im">On Wed, May 19, 2010 at 08:40:04AM +0300, Mikko Partio wr=
ote:<br>
><br>
> May 16 01:17:35 xxx postgres[25550]: [1-1] LOG: =A0could not truncate<=
br>
> directory "pg_subtrans": apparent wraparound<br>
><br>
<br>
</div><a href=3D"http://archives.postgresql.org/pgsql-general/2007-06/msg01=
050.php" target=3D"_blank">http://archives.postgresql.org/pgsql-gener al/200=
7-06/msg01050.php</a><br>
</blockquote></div><br><div><br></div><div>Browsing through that thread I c=
an see that I have similar symptoms:</div><div><br></div><div><div><div>$ p=
g_controldata | grep Multi</div><div>Latest checkpoint's NextMultiXactI=
d: =A01</div>
<div>Latest checkpoint's NextMultiOffset: =A00</div></div></div><div><b=
r></div><div><div>$ ls -l $PGDATA/pg_multixact/members</div><div>total 8</d=
iv><div>-rw------- 1 postgres dba 8192 May =A03 08:21 0000</div></div><div>
<br></div><div><div>$ ls -l $PGDATA/pg_multixact/offsets</div><div>total 8<=
/div><div>-rw------- 1 postgres dba 8192 May =A03 08:49 0000</div></div><di=
v><br></div><div>I don't see any resolution to that thread though.</div=
>
<div><br></div><div>Regards</div><div><br></div><div>Mikko</div><div><br></=
div><div><br></div>

--0016e68ee4694483a40486ff278e--

Excerpts from Mikko Partio's message of jue may 20 00:39:00 -0400 2010:
> On Wed, May 19, 2010 at 3:21 PM, Ray Stell <stellr [at] cns.vt.edu> wrote:

> > http://archives.postgresql.org/pgsql-general/2007-06/msg0105 0.php
>
> Browsing through that thread I can see that I have similar symptoms:
>
> $ pg_controldata | grep Multi
> Latest checkpoint's NextMultiXactId: 1
> Latest checkpoint's NextMultiOffset: 0

I don't remember why I insisted talking about multixacts in that thread,
but seeing that both the poster in the 2007 thread and you have problems
with the pg_subtrans directory, not pg_multixact, these "symptoms"
actually mean nothing at all. pg_subtrans and pg_multixact are
unrelated.

I wonder if there's an off-by-one bug in SimpleLruTruncate, or perhaps
the "cutoffPage" value passed by the caller is bogus once every ten blue
moons ... hmm, it comes from GetOldestXmin ...

Being more explicit in that error message (logging the cutoffPage) would
help figuring out what's going on.
--

--
Sent via pgsql-admin mailing list (pgsql-admin [at] postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin

--001636c92713fa2e08048713f973
Content-Type: text/plain; charset=ISO-8859-1

On Thu, May 20, 2010 at 7:53 PM, Alvaro Herrera <alvherre [at] alvh.no-ip.org>wrote:

> Excerpts from Mikko Partio's message of jue may 20 00:39:00 -0400 2010:
> > On Wed, May 19, 2010 at 3:21 PM, Ray Stell <stellr [at] cns.vt.edu> wrote:
>
> > > http://archives.postgresql.org/pgsql-general/2007-06/msg0105 0.php
> >
> > Browsing through that thread I can see that I have similar symptoms:
> >
> > $ pg_controldata | grep Multi
> > Latest checkpoint's NextMultiXactId: 1
> > Latest checkpoint's NextMultiOffset: 0
>
> I don't remember why I insisted talking about multixacts in that thread,
> but seeing that both the poster in the 2007 thread and you have problems
> with the pg_subtrans directory, not pg_multixact, these "symptoms"
> actually mean nothing at all. pg_subtrans and pg_multixact are
> unrelated.
>
> I wonder if there's an off-by-one bug in SimpleLruTruncate, or perhaps
> the "cutoffPage" value passed by the caller is bogus once every ten blue
> moons ... hmm, it comes from GetOldestXmin ...
>


So, I gather this error (is it even error if it's logged on LOG level?)
isn't anything serious?

Regards

Mikko

--001636c92713fa2e08048713f973
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br><div class=3D"gmail_quote">On Thu, May 20, 2010 at 7:53 PM, Alvaro =
Herrera <span dir=3D"ltr"><<a href=3D"mailto:alvherre [at] alvh.no-ip.org">al=
vherre [at] alvh.no-ip.org</a>></span> wrote:<br><blockquote class=3D"gmail_q=
uote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1e=
x;">
Excerpts from Mikko Partio's message of jue may 20 00:39:00 -0400 2010:=
<br>
<div class=3D"im">> On Wed, May 19, 2010 at 3:21 PM, Ray Stell <<a hr=
ef=3D"mailto:stellr [at] cns.vt.edu">stellr [at] cns.vt.edu</a>> wrote:<br>
<br>
</div><div class=3D"im">> > <a href=3D"http://archives.postgresql.org=
/pgsql-general/2007-06/msg01050.php" target=3D"_blank">http://archives.post=
gresql.org/pgsql-general/2007-06/msg01050.php</a><br>
><br>
> Browsing through that thread I can see that I have similar symptoms:<b=
r>
><br>
> $ pg_controldata | grep Multi<br>
> Latest checkpoint's NextMultiXactId: =A01<br>
> Latest checkpoint's NextMultiOffset: =A00<br>
<br>
</div>I don't remember why I insisted talking about multixacts in that =
thread,<br>
but seeing that both the poster in the 2007 thread and you have problems<br=
>
with the pg_subtrans directory, not pg_multixact, these "symptoms"=
;<br>
actually mean nothing at all. =A0pg_subtrans and pg_multixact are<br>
unrelated.<br>
<br>
I wonder if there's an off-by-one bug in SimpleLruTruncate, or perhaps<=
br>
the "cutoffPage" value passed by the caller is bogus once every t=
en blue<br>
moons ... hmm, it comes from GetOldestXmin ...<br></blockquote><div><br></d=
iv><div><br></div><div>So, I gather this error (is it even error if it'=
s logged on LOG level?) isn't anything serious?</div><div><br></div>
<div>Regards</div><div><br></div><div>Mikko</div></div>

--001636c92713fa2e08048713f973--

Mikko Partio <mpartio [at] gmail.com> writes:
> got the following line at postgresql log:

> May 16 01:17:35 xxx postgres[25550]: [1-1] LOG: could not truncate
> directory "pg_subtrans": apparent wraparound

> PostgreSQL 9.0beta1 on x86_64-unknown-linux-gnu, compiled by GCC gcc (GCC)
> 4.1.2 20080704 (Red Hat 4.1.2-46), 64-bit

Where did this beta1 installation come from --- was it freshly initdb'd
under 9.0, or did you use pg_upgrade on a pre-existing database that had
been around for awhile? It strikes me that the recently identified bug
in pg_upgrade about not fixing the datfrozenxid of template0 might
possibly explain this. You'd need to have upgraded an installation that
was at least a couple billion transactions old to hit that bug.

regards, tom lane

--
Sent via pgsql-admin mailing list (pgsql-admin [at] postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin

--005045015d83c7e908048750905d
Content-Type: text/plain; charset=ISO-8859-1

On Sun, May 23, 2010 at 9:02 PM, Tom Lane <tgl [at] sss.pgh.pa.us> wrote:

> Mikko Partio <mpartio [at] gmail.com> writes:
> > got the following line at postgresql log:
>
> > May 16 01:17:35 xxx postgres[25550]: [1-1] LOG: could not truncate
> > directory "pg_subtrans": apparent wraparound
>
> > PostgreSQL 9.0beta1 on x86_64-unknown-linux-gnu, compiled by GCC gcc
> (GCC)
> > 4.1.2 20080704 (Red Hat 4.1.2-46), 64-bit
>
> Where did this beta1 installation come from --- was it freshly initdb'd
> under 9.0, or did you use pg_upgrade on a pre-existing database that had
> been around for awhile? It strikes me that the recently identified bug
> in pg_upgrade about not fixing the datfrozenxid of template0 might
> possibly explain this. You'd need to have upgraded an installation that
> was at least a couple billion transactions old to hit that bug.
>


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.

Regards

Mikko

--005045015d83c7e908048750905d
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br><div class=3D"gmail_quote">On Sun, May 23, 2010 at 9:02 PM, Tom Lan=
e <span dir=3D"ltr"><<a href=3D"mailto:tgl [at] sss.pgh.pa.us">tgl [at] sss.pgh.pa=
..us</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class=3D"im">Mikko Partio <<a href=3D"mailto:mpartio [at] gmail.com">mpa=
rtio [at] gmail.com</a>> writes:<br>
</div><div class=3D"im">> got the following line at postgresql log:<br>
<br>
> May 16 01:17:35 xxx postgres[25550]: [1-1] LOG: =A0could not truncate<=
br>
> directory "pg_subtrans": apparent wraparound<br>
<br>
</div><div class=3D"im">> =A0PostgreSQL 9.0beta1 on x86_64-unknown-linux=
-gnu, compiled by GCC gcc (GCC)<br>
> 4.1.2 20080704 (Red Hat 4.1.2-46), 64-bit<br>
<br>
</div>Where did this beta1 installation come from --- was it freshly initdb=
'd<br>
under 9.0, or did you use pg_upgrade on a pre-existing database that had<br=
>
been around for awhile? =A0It strikes me that the recently identified bug<b=
r>
in pg_upgrade about not fixing the datfrozenxid of template0 might<br>
possibly explain this. =A0You'd need to have upgraded an installation t=
hat<br>
was at least a couple billion transactions old to hit that bug.<br></blockq=
uote><div><br></div><div><br></div><div>It was freshly initdb'd with be=
ta1 binaries, the contents were loded from a pg_dump file. The number of tr=
ansactions is very small, we're talking about thousands (not billions).=
This database is the master of a hot standby installation, if that matters=
..</div>
<div><br></div><div>Regards</div><div><br></div><div>Mikko</div></div>

--005045015d83c7e908048750905d--

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?

--
Simon Riggs www.2ndQuadrant.com


--
Sent via pgsql-admin mailing list (pgsql-admin [at] postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin

--0016e64761620e66e704877902eb
Content-Type: text/plain; charset=ISO-8859-1

On Mon, May 24, 2010 at 10:55 PM, Simon Riggs <simon [at] 2ndquadrant.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

--0016e64761620e66e704877902eb
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br><div class=3D"gmail_quote">On Mon, May 24, 2010 at 10:55 PM, Simon =
Riggs <span dir=3D"ltr"><<a href=3D"mailto:simon [at] 2ndquadrant.com">simon [at] =
2ndquadrant.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" =
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class=3D"im">On Mon, 2010-05-24 at 08:46 +0300, Mikko Partio wrote:<br=
>
<br>
> It was freshly initdb'd with beta1 binaries, the contents were lod=
ed<br>
> from a pg_dump file. The number of transactions is very small, we'=
re<br>
> talking about thousands (not billions). This database is the master of=
<br>
> a hot standby installation, if that matters.<br>
<br>
</div>Have you ever performed a switchover operation? If you've never r=
un an<br>
extended recovery on that server, its less likely to be anything HS<br>
related.<br>
<br>
Are you running any special hot standby parameters?</blockquote><div><br></=
div><div><br></div><div>With this database instance (beta1 initdb'd) I =
have not made failovers. I don't think I have any special hot standby p=
arameters either.=A0</div>
<div><br></div><div>Non-default hot standby related configuration options (=
master database):</div><div><br></div><div><div>wal_level =3D hot_standby =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 # minimal, archive, or hot_standby</div></d=
iv><div>archive_mode =3D on =A0 =A0 =A0 =A0 =A0 =A0 =A0 # allows archiving =
to be done</div>
<div><div>archive_command =3D '/postgresql/bin/archive_wal.sh "%p&=
quot; "%f"' =A0 =A0 =A0 =A0 =A0 =A0# command to use to archiv=
e a logfile segment</div><div>archive_timeout =3D 3600 =A0 =A0 =A0 =A0 =A0#=
force a logfile segment switch after this</div>
</div><div><div>hot_standby =3D off =A0 =A0 =A0 =A0 =A0 =A0 =A0 # allows qu=
eries during recovery</div></div><div><div>max_wal_senders =3D 3 =A0 =A0 =
=A0 =A0 =A0 =A0 # max number of walsender processes</div><div>wal_keep_segm=
ents =3D 10 =A0 =A0 =A0 =A0 =A0# in logfile segments, 16MB each; 0 disables=
</div>
</div><div><br></div><div>Regards</div><div><br></div><div>Mikko</div></div=
>

--0016e64761620e66e704877902eb--

On Wed, 2010-05-26 at 09:01 +0300, Mikko Partio wrote:

> With this database instance (beta1 initdb'd) I have not made
> failovers. I don't think I have any special hot standby parameters
> either.

OK, so that pretty much rules out HS as a direct cause.

> 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

--
Simon Riggs www.2ndQuadrant.com


--
Sent via pgsql-admin mailing list (pgsql-admin [at] postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin