From: Osumi, Takamichi/大墨 昂道 <osumi.takamichi@fujitsu.com>
> > case TRANS_STMT_PREPARE:
> > + if (wal_level ==
> > WAL_LEVEL_NONE)
> > + ereport(ERROR,
> > +
> > errmsg("cannot execute PREPARE TRANSACTION when WAL logging
> is
> > disabled"));
> Usually, this safeguard is not needed for PREPARE TRANSACTION.
> But, when an unexpected crash happens, user needs to recreate the cluster
> from the backup and execute the operations that are executed into the crashed
> server again if the user sets wal_level=none.
>
> While 2PC guarantees that after issuing PREPARE TRANSACTION, the
> processing or the contents of the transaction becomes *secure*, setting
> wal_level=none makes the server never start up again if a database crash
> occurs.
> In other words, this safeguard of the new wal_level damages the important
> aspect of PREPARE TRANSACTION's functionality, in my opinion.
>
> I don't think this is what it should be.
>
> Therefore, I don't want users to utilize the PREPARE TRANSACTION still in
> order to prevent that user thinks that they can use PREPARE TRANSACTION
> safely during wal_level=none and execute it.
> Did it make sense ?
PREPARE TRANSACTION is the same as COMMIT in that it persists transaction updates. A crash during wal_level = none
losesboth of them. So, I don't think PREPARE TRANSACTION needs special treatment.
Does PREPARE TRANSACTION complete successfully? I remember Fujii-san said it PANICed if --enable-asserts is used in
configure.
Regards
Takayuki Tsunakawa
