Doesn't WAL fail at BLCKSZ = 32k?

I've been looking at the WAL code and trying to figure out what the
"backup block" mechanism is for. It appears that that can attach
up to two disk pages of info to a WAL log record. If there are any
cases where more than one page is really attached to a record, then
WAL will crash and burn with BLCKSZ = 32K, because the record length
field in XLogRecord is only 16 bits: there's not room for 2 * BLCKSZ,
let alone any additional fields.

The define
#define _INTL_MAXLOGRECSZ (3 * MAXLOGRECSZ)
in xlog.c is even more disturbing, if accurate; that'd mean that
BLCKSZ = 16k wouldn't work either.

I don't like the idea of restricting the maximum blocksize, since we
don't yet have a complete implementation of TOAST (cf indexes). This
appears to mean that the format of WAL records will have to change;
either we widen xl_len or arrange for backup blocks to be stored as
separate records. Or perhaps just agree that the backup blocks aren't
counted in xl_len, although that seems a tad klugy.

On the other hand, if there can't really be more than one backup block
per record, there's no issue. Where is this used, and for what?

regards, tom lane