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

Re: database question

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Scott Marlowe" <scott(dot)marlowe(at)gmail(dot)com>
Cc: john(dot)crawford(at)sirsidynix(dot)com, pgsql-general(at)postgresql(dot)org
Subject: Re: database question
Date: 2008-09-29 23:31:32
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-general
"Scott Marlowe" <scott(dot)marlowe(at)gmail(dot)com> writes:
> On Mon, Sep 29, 2008 at 8:21 AM,  <john(dot)crawford(at)sirsidynix(dot)com> wrote:
>> -rw------- 1 postgres root     1073741824 Sep 29 15:15 2613.77
>> -rw------- 1 postgres root     1073741824 Sep 29 15:15 2613.83
>> What are these files and why have they suddenly started to be created
>> and why so large?

> PostgreSQL automatically splits table files into 1G chunks so it can
> run on OSes with file size limits.  These are part of the table
> identified by the oid 2613.  You can find it by looking in pg_class.

Actually relfilenode, not oid, is the thing to look at.  But a table
with such a small relfilenode number must be a system catalog, and a
quick look shows that in any recent PG version it's pg_largeobject.

So the answer is you've got something that's gone hog-wild on creating
large objects and not deleting them; or maybe the application *is*
deleting them but pg_largeobject isn't getting vacuumed.

			regards, tom lane

In response to


pgsql-general by date

Next:From: Tom LaneDate: 2008-09-29 23:36:36
Subject: Re: Counting unique rows as an aggregate.
Previous:From: Tom LaneDate: 2008-09-29 23:26:43
Subject: Re: Can't cast from char to integer...

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