Re: Questions related to xlog

Qingqing Zhou <zhouqq(at)cs(dot)toronto(dot)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