On Fri, 2002-08-02 at 13:50, Richard Tucker wrote:
> pg_copy does not handle "local relations" as you would suspect. To find the
> tables and indexes to backup the backend in processing the "ALTER SYSTEM
> BACKUP" statement reads the pg_class table. Any tables in the process of
> coming into existence of course are not visible. If somehow they were then
> the backup would backup up their contents. Any in private memory changes
> would be captured during crash recovery on the copy of the database. So the
> question is: is it possible to read the names of the "local relations" from
> the pg_class table even though there creation has not yet been committed?
> -regards
> richt
>
No, not really. At least not a consistent view.
The way to do this is using the filesystem to discover the relfilnodes,
and there are a couple of ways to deal with the problem of files being
pulled out from under you, but you have to be careful about what the
buffer manager does when a file gets dropped.
The predicate for files we MUST (fuzzy) copy is: File exists at start of backup && File exists at end of backup
Any other file, while it may be copied, doesn't need to be in the backup
because either it will be created and rebuilt during play-forward
recovery, or it will be deleted during play-forward recovery, or both,
assuming those operations are logged. They really must be logged to do
what we want to do.
Also, you can't use the normal relation_open stuff, because local
relations will not have a catalog entry, and it looks like there are
catcache/sinval issues that I haven't completely covered. So you've got
to do 'blind reads' through the buffer manager, which involves a minor
extension to the buffer manager to support this if local relations go
through the shared buffers, or coordinating with the local buffer
manager if they continue to work as they do now, which involves major
changes.
We also have to checkpoint at the start, and flush the log at the end.
--
J. R. Nield
jrnield@usol.com
