pg.ddx.io  pgsql-admin@postgresql.org mailing list archive  
help / color / mirror / Atom feed
could not truncate directory "pg_subtrans": apparent wraparound
13+ messages / 6 participants
[nested] [flat]

* could not truncate directory "pg_subtrans": apparent wraparound
@ 2010-05-19 05:40  Mikko Partio <mpartio@gmail.com>
  0 siblings, 3 replies; 13+ messages in thread

From: Mikko Partio @ 2010-05-19 05:40 UTC (permalink / raw)
  To: pgsql-admin

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

^ permalink  raw  reply  [nested|flat] 13+ messages in thread

* Re: could not truncate directory "pg_subtrans": apparent wraparound
@ 2010-05-19 12:21  Ray Stell <stellr@cns.vt.edu>
  parent: Mikko Partio <mpartio@gmail.com>
  2 siblings, 1 reply; 13+ messages in thread

From: Ray Stell @ 2010-05-19 12:21 UTC (permalink / raw)
  To: Mikko Partio <mpartio@gmail.com>; +Cc: pgsql-admin

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/msg01050.php



^ permalink  raw  reply  [nested|flat] 13+ messages in thread

* Re: could not truncate directory "pg_subtrans": apparent wraparound
@ 2010-05-19 19:01  Tom Lane <tgl@sss.pgh.pa.us>
  parent: Mikko Partio <mpartio@gmail.com>
  2 siblings, 1 reply; 13+ messages in thread

From: Tom Lane @ 2010-05-19 19:01 UTC (permalink / raw)
  To: Mikko Partio <mpartio@gmail.com>; +Cc: pgsql-admin

Mikko Partio <mpartio@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



^ permalink  raw  reply  [nested|flat] 13+ messages in thread

* Re: could not truncate directory "pg_subtrans": apparent wraparound
@ 2010-05-20 04:32  Mikko Partio <mpartio@gmail.com>
  parent: Tom Lane <tgl@sss.pgh.pa.us>
  0 siblings, 0 replies; 13+ messages in thread

From: Mikko Partio @ 2010-05-20 04:32 UTC (permalink / raw)
  To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: pgsql-admin

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

> Mikko Partio <mpartio@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

^ permalink  raw  reply  [nested|flat] 13+ messages in thread

* Re: could not truncate directory "pg_subtrans": apparent wraparound
@ 2010-05-20 04:39  Mikko Partio <mpartio@gmail.com>
  parent: Ray Stell <stellr@cns.vt.edu>
  0 siblings, 1 reply; 13+ messages in thread

From: Mikko Partio @ 2010-05-20 04:39 UTC (permalink / raw)
  To: Ray Stell <stellr@cns.vt.edu>; +Cc: pgsql-admin

On Wed, May 19, 2010 at 3:21 PM, Ray Stell <stellr@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/msg01050.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

^ permalink  raw  reply  [nested|flat] 13+ messages in thread

* Re: could not truncate directory "pg_subtrans": apparent wraparound
@ 2010-05-20 16:53  Alvaro Herrera <alvherre@alvh.no-ip.org>
  parent: Mikko Partio <mpartio@gmail.com>
  0 siblings, 1 reply; 13+ messages in thread

From: Alvaro Herrera @ 2010-05-20 16:53 UTC (permalink / raw)
  To: Mikko Partio <mpartio@gmail.com>; +Cc: Ray Stell <stellr@cns.vt.edu>; pgsql-admin

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@cns.vt.edu> wrote:

> > http://archives.postgresql.org/pgsql-general/2007-06/msg01050.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.
-- 



^ permalink  raw  reply  [nested|flat] 13+ messages in thread

* Re: could not truncate directory "pg_subtrans": apparent wraparound
@ 2010-05-21 05:29  Mikko Partio <mpartio@gmail.com>
  parent: Alvaro Herrera <alvherre@alvh.no-ip.org>
  0 siblings, 0 replies; 13+ messages in thread

From: Mikko Partio @ 2010-05-21 05:29 UTC (permalink / raw)
  To: Alvaro Herrera <alvherre@alvh.no-ip.org>; +Cc: Ray Stell <stellr@cns.vt.edu>; pgsql-admin

On Thu, May 20, 2010 at 7:53 PM, Alvaro Herrera <alvherre@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@cns.vt.edu> wrote:
>
> > > http://archives.postgresql.org/pgsql-general/2007-06/msg01050.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

^ permalink  raw  reply  [nested|flat] 13+ messages in thread

* Re: could not truncate directory "pg_subtrans": apparent wraparound
@ 2010-05-23 18:02  Tom Lane <tgl@sss.pgh.pa.us>
  parent: Mikko Partio <mpartio@gmail.com>
  2 siblings, 1 reply; 13+ messages in thread

From: Tom Lane @ 2010-05-23 18:02 UTC (permalink / raw)
  To: Mikko Partio <mpartio@gmail.com>; +Cc: pgsql-admin

Mikko Partio <mpartio@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



^ permalink  raw  reply  [nested|flat] 13+ messages in thread

* Re: could not truncate directory "pg_subtrans": apparent wraparound
@ 2010-05-24 05:46  Mikko Partio <mpartio@gmail.com>
  parent: Tom Lane <tgl@sss.pgh.pa.us>
  0 siblings, 1 reply; 13+ messages in thread

From: Mikko Partio @ 2010-05-24 05:46 UTC (permalink / raw)
  To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: pgsql-admin

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

> Mikko Partio <mpartio@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

^ permalink  raw  reply  [nested|flat] 13+ messages in thread

* Re: could not truncate directory "pg_subtrans": apparent wraparound
@ 2010-05-24 19:55  Simon Riggs <simon@2ndQuadrant.com>
  parent: Mikko Partio <mpartio@gmail.com>
  0 siblings, 1 reply; 13+ messages in thread

From: Simon Riggs @ 2010-05-24 19:55 UTC (permalink / raw)
  To: Mikko Partio <mpartio@gmail.com>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; pgsql-admin

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




^ permalink  raw  reply  [nested|flat] 13+ messages in thread

* Re: could not truncate directory "pg_subtrans": apparent wraparound
@ 2010-05-26 06:01  Mikko Partio <mpartio@gmail.com>
  parent: Simon Riggs <simon@2ndQuadrant.com>
  0 siblings, 1 reply; 13+ messages in thread

From: Mikko Partio @ 2010-05-26 06:01 UTC (permalink / raw)
  To: Simon Riggs <simon@2ndquadrant.com>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; pgsql-admin

On Mon, May 24, 2010 at 10:55 PM, Simon Riggs <simon@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

^ permalink  raw  reply  [nested|flat] 13+ messages in thread

* Re: could not truncate directory "pg_subtrans": apparent wraparound
@ 2010-05-26 06:28  Simon Riggs <simon@2ndQuadrant.com>
  parent: Mikko Partio <mpartio@gmail.com>
  0 siblings, 0 replies; 13+ messages in thread

From: Simon Riggs @ 2010-05-26 06:28 UTC (permalink / raw)
  To: Mikko Partio <mpartio@gmail.com>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; pgsql-admin

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




^ permalink  raw  reply  [nested|flat] 13+ messages in thread

* could not truncate directory "pg_subtrans":  apparent wraparound
@ 2014-10-02 14:03  Holger.Friedrich-Fa-Trivadis@it.nrw.de
  0 siblings, 0 replies; 13+ messages in thread

From: Holger.Friedrich-Fa-Trivadis@it.nrw.de @ 2014-10-02 14:03 UTC (permalink / raw)
  To: pgsql-admin

Hello,

today I saw the following message in the log file of a PostgreSQL 9.1.9 instance:

[2014-10-02 01:19:23.799 CEST : @ from ]LOG:  konnte Verzeichnis »pg_subtrans« nicht leeren: anscheinender Überlauf

which apparently translates as

could not truncate directory "pg_subtrans":  apparent wraparound

Googling this, the most reassuring link seems to be http://database-app.todaysummary.com/wap_q_database-application_16256, which says in several places that the message is harmless, but then goes on to talk about the pg_multixact subdirectory.

Is this message also harmless when it specifically mentions the pg_subtrans subdirectory?  Or should I still be worried?

Some technical info:

PostgreSQL 9.1.9 on x86_64-unknown-linux-gnu, compiled by gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-3), 64-bit

pg_control version number:            903
Catalog version number:               201105231
Database system identifier:           6034043295502253819
Database cluster state:               in archive recovery
pg_control last modified:             Do 02 Okt 2014 13:32:35 CEST
Latest checkpoint location:           14/F3044CD0
Prior checkpoint location:            14/F2A55618
Latest checkpoint's REDO location:    14/F2E31DE8
Latest checkpoint's TimeLineID:       1
Latest checkpoint's NextXID:          0/331367
Latest checkpoint's NextOID:          37926189
Latest checkpoint's NextMultiXactId:  1082
Latest checkpoint's NextMultiOffset:  2210
Latest checkpoint's oldestXID:        1795
Latest checkpoint's oldestXID's DB:   1
Latest checkpoint's oldestActiveXID:  331367
Time of latest checkpoint:            Do 02 Okt 2014 13:20:01 CEST
Minimum recovery ending location:     14/F376B0C8
Backup start location:                0/0
Current wal_level setting:            hot_standby
Current max_connections setting:      1000
Current max_prepared_xacts setting:   0
Current max_locks_per_xact setting:   64
Maximum data alignment:               8
Database block size:                  8192
Blocks per segment of large relation: 131072
WAL block size:                       8192
Bytes per WAL segment:                16777216
Maximum length of identifiers:        64
Maximum columns in an index:          32
Maximum size of a TOAST chunk:        1996
Date/time type storage:               64-bit integers
Float4 argument passing:              by value
Float8 argument passing:              by value

The pg_subtrans subdirectory holds a single file called 0005.

Best regards
Holger Friedrich

^ permalink  raw  reply  [nested|flat] 13+ messages in thread


end of thread, other threads:[~2014-10-02 14:03 UTC | newest]

Thread overview: 13+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2010-05-19 05:40 could not truncate directory "pg_subtrans": apparent wraparound Mikko Partio <mpartio@gmail.com>
2010-05-19 12:21 ` Ray Stell <stellr@cns.vt.edu>
2010-05-20 04:39   ` Mikko Partio <mpartio@gmail.com>
2010-05-20 16:53     ` Alvaro Herrera <alvherre@alvh.no-ip.org>
2010-05-21 05:29       ` Mikko Partio <mpartio@gmail.com>
2010-05-19 19:01 ` Tom Lane <tgl@sss.pgh.pa.us>
2010-05-20 04:32   ` Mikko Partio <mpartio@gmail.com>
2010-05-23 18:02 ` Tom Lane <tgl@sss.pgh.pa.us>
2010-05-24 05:46   ` Mikko Partio <mpartio@gmail.com>
2010-05-24 19:55     ` Simon Riggs <simon@2ndQuadrant.com>
2010-05-26 06:01       ` Mikko Partio <mpartio@gmail.com>
2010-05-26 06:28         ` Simon Riggs <simon@2ndQuadrant.com>
2014-10-02 14:03 could not truncate directory "pg_subtrans":  apparent wraparound Holger.Friedrich-Fa-Trivadis@it.nrw.de

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox