Обсуждение: Questions related to xlog

I have several questions in understanding xlog code:

(1)
In RecordTransactionCommit():
* (If it made no transaction-controlled XLOG entries, its XID appears* nowhere in permanent storage

We have this in XLogInsert():
/* Insert record header */record->xl_xid = GetCurrentTransactionIdIfAny();

So in some situations (i.e., this transaction was already assigned an
XID), XLOG_NO_TRAN entries' XID does show up in permante storage?

(2)
In smgrcreate():
 * Make a non-transactional XLOG entry showing the file creation.  It's * non-transactional because we should replay it
whetherthe transaction * commits or not
 
lsn = XLogInsert(... XLOG_NO_TRAN ...);

Do we replay *all* xlogs no matter it commits or not? AFAICS, the only
usage of marking xlog non transaction-controlled is not to move
MyLastRecPtr pointer (so possiblly reduce some work at transaction
prepare/commit/abort point), and other usage?

(3)
Also in smgrcreate():
*  ...; the WAL sequence will tell whether to drop the file.*/
void
smgrcreate(SMgrRelation reln, bool isTemp, bool isRedo)

Seems nobody is reponsible to remove the smgrcreate()'d file if only
XLOG_SMGR_CREATE entry is flushed and system crash?

Regards,
Qingqing

Qingqing Zhou <zhouqq@cs.toronto.edu> writes:
> (1)
> In RecordTransactionCommit():
>     * (If it made no transaction-controlled XLOG entries, its XID appears
>     * nowhere in permanent storage

> We have this in XLogInsert():
>     /* Insert record header */
>     record->xl_xid = GetCurrentTransactionIdIfAny();

> So in some situations (i.e., this transaction was already assigned an
> XID), XLOG_NO_TRAN entries' XID does show up in permante storage?

I believe that the remark about "permanent storage" applies to the
database tables, not to the XLOG entries themselves (which are not
at all permanent, being open to recycling after the next checkpoint).

> (2)
> Do we replay *all* xlogs no matter it commits or not? AFAICS, the only
> usage of marking xlog non transaction-controlled is not to move
> MyLastRecPtr pointer (so possiblly reduce some work at transaction
> prepare/commit/abort point), and other usage?

Yeah, the non-transaction-controlled distinction is really not very
useful.  I believe Vadim put it in originally because he wanted to go to
a REDO/UNDO approach, in which it would've been important to tell the
difference, but we never did that (and probably never will).  I've
preserved the distinction because it seemed worthwhile from the
standpoint of documentation and logical clarity, but if you see a reason
to get rid of it, I won't argue hard for it.

> (3)
> Seems nobody is reponsible to remove the smgrcreate()'d file if only
> XLOG_SMGR_CREATE entry is flushed and system crash?

Yeah, the system is not set up to remove unreferenced files in such
cases.  Bruce put up a proposed patch to fix this awhile back, but
I objected on the grounds that automatically removing files is too
dangerous.  The data in them might be valuable enough to merit manual
recovery measures of some sort.  The risk of wasting disk space seems
less bad than the risk of throwing away useful data.
        regards, tom lane

On Fri, 23 Dec 2005, Tom Lane wrote:

>
> Yeah, the non-transaction-controlled distinction is really not very
> useful.  I believe Vadim put it in originally because he wanted to go to
> a REDO/UNDO approach, in which it would've been important to tell the
> difference, but we never did that (and probably never will).  I've
> preserved the distinction because it seemed worthwhile from the
> standpoint of documentation and logical clarity, but if you see a reason
> to get rid of it, I won't argue hard for it.
>

No strong reasons to remove them, though the comments are kind of
confusing.

Regards,
Qingqing