>  [mailto:pgsql-general-owner@postgresql.org] On Behalf Of Tom Lane
> The current thought is to add some sort of hook that allows a 
> user-defined action to be taken at the point where a WAL file 
> would normally get recycled.  Presumably this action would 
> involve copying the WAL file to someplace else (eg a tape), 
> after which it could get recycled.  If you've got any 
> thoughts on exactly how to manage this, let's take up a 
> discussion on pgsql-hackers.


In practice it is quite OK just to have parameters like those:

	-Are database WAL logs recycable or not, i.e. accumulates.

	-location where to put(location's path, possibly more than one
location) those accumulating logs
	-is the location mandatory or not
	-log file name format: date/time/log sequence number

What's quite good to have are system catalog views for WAL logs:

	log_history view: listing every log produced together with it's
sequence number, physical path - logs are assumed to have sequence numbers.
This view can recycle after N days based on some parameter.
	
	From that view or from another it would be good to find out the last
applied WAL log when recovering.

	What for are those views: they can be used to delete (yes, cleaning
after yourself is the issue) unneccesary logs (the recycling of log_history
view can/must be based on that criteria). 

	More: this view would allow to figure out what logs to backup after
baseline backup (it is assumed that one may tell which WAL log is the
current/last from this view or another one). Vice versa, this view or another
one can be used to find out what WAL logs are applied during recovery andwhat
are still needed compared to the original database.
	

	And a SQL command to complete a current WAL log (switch to a new) is
handy.



Brgds, Laimis




 

	

Thu, 22 Jan 2004 17:56:02 -0000
<lnd@hnit.is>
Re: [GENERAL] tablespaces a priority for 7.5? 