Re: PITR, checkpoint, and local relations

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

> -----Original Message-----
> From: J. R. Nield [mailto:jrnield(at)usol(dot)com]
> Sent: Friday, August 02, 2002 12:27 PM
> To: Tom Lane
> Cc: Bruce Momjian; Richard Tucker; PostgreSQL Hacker
> Subject: Re: [HACKERS] PITR, checkpoint, and local relations
>
>
> On Fri, 2002-08-02 at 10:01, Tom Lane wrote:
> >
> > Just out of curiosity, though, what does it matter? On re-reading your
> > message I think you are dealing with a non problem, or at least the
> > wrong problem. Local relations do not need to be checkpointed, because
> > by definition they were created by a transaction that hasn't committed
> > yet. They must be, and are, checkpointed to disk before the transaction
> > commits; but up till that time, if you have a crash then the entire
> > relation should just go away.
>
> What happens when we have a local file that is created before the
> backup, and it becomes global during the backup?
>
> In order to copy this file, I either need:
>
> 1) A copy of all its blocks at the time backup started (or later), plus
> all log records between then and the end of the backup.
>
> OR
>
> 2) All the log records from the time the local file was created until
> the end of the backup.
>
> In the case of an idle uncommitted transaction that suddenly commits
> during backup, case 2 might be very far back in the log file. In fact,
> the log file might be archived to tape by then.
>
> So I must do case 1, and checkpoint the local relations.
>
>
> This brings up the question: why do I need to bother backing up files
> that were local before the backup started, but became global during the
> backup.
>
> We already know that for the backup to be consistent after we restore
> it, we must play the logs forward to the completion of the backup to
> repair our "fuzzy copies" of the database files. Since the transaction
> that makes the local-file into a global one has committed during our
> backup, its log entries will be played forward as well.
>
> What would happen if a transaction with a local relation commits during
> backup, and there are log entries inserting the catalog tuples into
> pg_class. Should I not apply those on restore? How do I know?
>
> >
> > That mechanism is there already --- perhaps it needs a few tweaks for
> > PITR but I do not see any need for cross-backend flush commands for
> > local relations.
> >
>
> This problem is subtle, and I'm maybe having difficulty explaining it
> properly. Do you understand the issue I'm raising? Have I made some kind
> of blunder, so that this is really not a problem?
>
> --
> J. R. Nield
> jrnield(at)usol(dot)com
>
>
>
>