Resent-From: POSTGRES mailing list <postman@postgres.Berkeley.EDU>
Resent-Message-Id: <199505161927.MAA15377@nobozo.CS.Berkeley.EDU>
Sender: owner-postman@postgres.Berkeley.EDU
From: Jolly Chen <jolly@postgres.Berkeley.EDU>
Message-Id: <199505161924.MAA04324@arcadia.CS.Berkeley.EDU>
To: Kacper Nowicki <Kacper.Nowicki@fuw.edu.pl>
cc: postgres@postgres.Berkeley.EDU
Subject: Re: pg_time 
In-reply-to: Your message of "Tue, 16 May 1995 12:18:34 +0200."
             <Pine.SUN.3.91.950516114227.2987E-100000@ccfs1> 
Date: Tue, 16 May 1995 12:24:20 -0700
Resent-To: postgres-redist@postgres.Berkeley.EDU
Resent-Date: Tue, 16 May 95 12:27:00 -0700
Resent-XMts: smtp


> 
> Hi,
> 
> I have enormously large pg_time table in postgres/data directory.
> I think that this problem was reported previously at this list. I 
> remember that someone adviced to make a hole in this file (with lseek).
> Am I right ?
> 
> Does anybody have a tool to do this ?
> Do you know where I can cut it (left last one instance, last 1000, etc.)
> Is there the same problem in Postgres95 ?
> 
> Thanks in advance,
> Kacper


Alas, although this issue has come up a couple of time, we still don't
have a good solution for this.  Here's the piece of email floating around
last time this issue came up.  Are there any volunteers to write a tool
for this? 

- Jolly Chen


------- Forwarded Message

 From:  Mike Olson <mao@illustra.com>
 To:  aoki@postgres.Berkeley.EDU (Paul M. Aoki)
 Subject:  Re: how to clean up pg_log, pg_time and pg_variable? 
 Date:  Mon, 06 Jun 94 10:41:54 -0700

 aoki@postgres.Berkeley.EDU (Paul M. Aoki) writes:
 
 > with respect to the other two, pg_log grows at 2 bits (.25 bytes) per
 > transaction and pg_time grows at 4 bytes per transaction.
 > 
 >	...
 > 
 > it would be a bad idea to remove them or truncate them.
 
 here's something i always planned to do but never did.
 
 once an entire installation has been vacuumed beyond some time t, you
 can remove all the log and time records prior to t from the files.
 you create a new file, lseek to the position of the first xid after
 t, and then start copying all the records after t to the new file.
 
 the unix file system will not allocate blocks for the zero-filled
 pages before the first records copied, so the files logically continue
 to grow but they are physically much smaller.
 
 you don't even need to know postgres internals to do this if you are
 willing to shut down the installation when you run the program.  of
 course, this is a good length of stout rope.
 
 					mike
 

------- End of Forwarded Message

==============================================================================
   To add/remove yourself to/from the POSTGRES mailing list: send mail with 
   the subject line ADD or DEL to "postgres-request@postgres.Berkeley.EDU".
   If this fails, send mail to "post_questions@postgres.Berkeley.EDU" and
   a human will deal with it.  DO NOT post to the "postgres" mailing list.
==============================================================================
              URL: http://s2k-ftp.CS.Berkeley.EDU:8000/postgres/