Re: [HACKERS] Current TODO list - Mailing list pgsql-hackers
From | Ole Gjerde |
---|---|
Subject | Re: [HACKERS] Current TODO list |
Date | |
Msg-id | Pine.LNX.4.05.9905211124110.27066-100000@snowman.icebox.org Whole thread Raw |
In response to | Re: [HACKERS] Current TODO list (Bruce Momjian <maillist@candle.pha.pa.us>) |
Responses |
RE: [HACKERS] Current TODO list
|
List | 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
pgsql-hackers by date: