Re: truncating or full vacuuming

From: Viktor Bojović <viktor(dot)bojovic(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: truncating or full vacuuming
Date: 2010-10-20 14:59:25
Message-ID: AANLkTinfCZxpd5GYr+wzDYuEG=N1qz8cZeOCfM4v5ehG@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Wed, Oct 20, 2010 at 4:50 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> =?UTF-8?Q?Viktor_Bojovi=C4=87?= <viktor(dot)bojovic(at)gmail(dot)com> writes:
> > while creating an index on billion records table i have canceled creation
> > because index took me ~70GB of space.
> > When I looked into disk space i saw that space is still occupied , and
> the
> > index doesn't exist.
>
> hmm ... was your version of "cancel" spelled "kill -9" or something like
> that? If so it's unsurprising that temp files would have been left
> behind. Look in the pgsql_tmp subdirectory. It's also possible that
> the partially-filled index files are still there but aren't linked to
> by any live pg_class row. Check for files that don't match any entry in
> the pg_class.relfilenode column. In both cases you'd have to remove any
> such files by hand --- VACUUM is not going to fix this for you.
>
> regards, tom lane
>

i have used Ctrl+C while i was in console.
I entered into that directory you have mentioned, but i have found no files
inside.

postgres(at)zohar:/srv/postgresql/base$ du -h --max-depth=1
4.2M ./1
4.2M ./11510
4.3M ./11511
1.1G ./1044080708
0 ./pgsql_tmp
453G ./1051277744
454G .

--
---------------------------------------
Viktor Bojović
---------------------------------------
Wherever I go, Murphy goes with me

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Grzegorz Jaśkiewicz 2010-10-20 15:02:12 Re: drop view with out cascading the dependents
Previous Message Tom Lane 2010-10-20 14:50:28 Re: truncating or full vacuuming