Re: [HACKERS] Current TODO list

From: Ole Gjerde <gjerde(at)icebox(dot)org>
To: Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us>
Cc: Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [HACKERS] Current TODO list
Date: 1999-05-21 16:36:55
Message-ID: Pine.LNX.4.05.9905211124110.27066-100000@snowman.icebox.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, 20 May 1999, Bruce Momjian wrote:
> > For example,the following code is not changed by the patch.
> > if (FileTruncate(v->mdfd_vfd, nblocks * BLCKSZ) < 0)
> > return -1;
> > It never truncate segmented files and there may be cases the
> > original file increases its size(ftruncate() increases the size of
> > target file if the requested size is longer than the actual size).

I agree. I have rewritten my patch, but I need to test it some more.

> > But my anxiety is the use of unlink()(FileNameUnlink()).
> > Unlink() is very dangerous.
> > Unlink() never remove the target file immediately.and even the
> > truncating process doesn't close the files by the patch and so
> > unlinked files are still alive for all processes which have already
> > opened the files.

I don't think unlink() is a problem. That other backends have the files
open shouldn't matter. Whenever they close it(should be pretty quick),
the files would be removed..

I'll try to get the patch out later today.

On another note, I've had some other problems with vacuuming my databases.
(All before patch :)
Sometimes the backend would crash while doing a vacuum analyze. It would
do this repeatedly if I ran it again. Then if I ran a regular vacuum, and
then again a vacuum analyze it would work fine. Very weird...

Now I have a bit of a bigger problem. I just did a pg_upgrade to a newer
CVS version. Most of my tables seems fine and vacuum worked fine on most
of them.
But on the only 2 tables that I have changed lately I'm getting vacuum
"errors". Both tables are very small(shotgun table file is 1.4MB).
If I keep running vacuum(over and over) the number of deleted tuples will
eventually go to 0 and it will look normal. It does take a few vacuum
runs however, so something really weird is going on here.

shotgun=> vacuum verbose analyze shotgun;
NOTICE: --Relation shotgun--
NOTICE: Pages 334: Changed 0, Reapped 5, Empty 0, New 0; Tup 22414: Vac
3, Keep/VTL 11708/10895, Crash 0, UnUsed 49, MinLen 64, MaxLen 159;
Re-using: Free/Avail. Space 6556/492; EndEmpty/Avail. Pages 0/3. Elapsed
0/0 sec.
NOTICE: Index shotgun_index_keyword: Pages 180; Tuples 22274: Deleted 3.
Elapsed 0/0 sec.
NOTICE: Index shotgun_index_keyword: NUMBER OF INDEX' TUPLES (22274) IS
NOT THE SAME AS HEAP' (22414)
NOTICE: Index shotgun_index_email: Pages 222; Tuples 22274: Deleted 3.
Elapsed 0/1 sec.
NOTICE: Index shotgun_index_email: NUMBER OF INDEX' TUPLES (22274) IS NOT
THE SAME AS HEAP' (22414)
NOTICE: Index shotgun_id_key: Pages 91; Tuples 22414: Deleted 3. Elapsed
0/0 sec.
NOTICE: Rel shotgun: Pages: 334 --> 334; Tuple(s) moved: 2. Elapsed 0/0
sec.
NOTICE: Index shotgun_index_keyword: Pages 180; Tuples 22275: Deleted 1.
Elapsed 0/0 sec.
NOTICE: Index shotgun_index_keyword: NUMBER OF INDEX' TUPLES (22275) IS
NOT THE SAME AS HEAP' (22414)
NOTICE: Index shotgun_index_email: Pages 222; Tuples 22275: Deleted 1.
Elapsed 0/0 sec.
NOTICE: Index shotgun_index_email: NUMBER OF INDEX' TUPLES (22275) IS NOT
THE SAME AS HEAP' (22414)
NOTICE: Index shotgun_id_key: Pages 91; Tuples 22415: Deleted 1. Elapsed
0/0 sec.
NOTICE: Index shotgun_id_key: NUMBER OF INDEX' TUPLES (22415) IS NOT THE
SAME AS HEAP' (22414)
VACUUM

Thanks,
Ole Gjerde

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Ole Gjerde 1999-05-21 17:38:37 Doesn't compile
Previous Message Bruce Momjian 1999-05-21 15:46:05 Re: [HACKERS] Broken select on regular expression !!!