Buffer Management: Can dirty pages be written before transaction commits?

I am in the middle of studying PostgreSQL MVCC approach when I stumbled
upon the two hint bits which marked xmin/xmax to be "in progress",
"committed", or "aborted". I just want to make sure that I got my
understanding right with regards to Postgres' XLOG and Buffer management.

1. When a transaction T updates a tuple X, it creates a new version of the
tuple, and then leave the hint bits unset (xmin/xmax in progress). Let's
say the tuple is located in page P.

2. Buffer manager may evict page P from cache even before transaction T
commits/aborts. However, it must do so only after HEAP_UPDATE is written to
XLOG.

3. When transaction T eventually commits/aborts, we only have to set
appropriate CLOG bits for T, but we never have to touch the hint bits of
the tuples modified by transaction T.

4. Only when another transaction inspects tuple X, it realizes that the
hint bits are unset and needs to inspect CLOG to see the outcome of
xmin/xmax. If there is any change in outcome, the hint bits of tuple X will
be set.

5. So it is actually possible for tuples created by aborted transaction to
appear on disk. However this should pose no problem as they will never be
visible to any transaction, and Vacuum process will eventually get rid of
them.

I am really unsure about point 2, because I couldn't find any definite
statement whether a dirty page could be written before transaction commits.
All it makes clear is that the XLOG record describing the change must be
present on disk before the dirty page, but that does not seem to prohibit
dirty pages to be written before commit time. The consequence is as
described in point 5, the transaction which created the tuple might turn
out to be aborted, and those tuples will be invalid and efforts will be
wasted.

Thanks in advance for your help and clarification.

Prima