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@usol.com
