On Tue, Nov 24, 2020 at 11:19 AM osumi.takamichi@fujitsu.com
<osumi.takamichi@fujitsu.com> wrote:
>
> Hi
>
> On Monday, Nov 23, 2020 12:17 PM Tsunakawa, Takayuki <tsunakawa.takay@fujitsu.com> wrote:
> > PREPARE TRANSACTION is the same as COMMIT in that it persists
> > transaction updates. A crash during wal_level = none loses both of them.
> > So, I don't think PREPARE TRANSACTION needs special treatment.
> Yeah, I got it. That makes sense.
> Attached is the one I removed the special treatment.
>
>
> > Does PREPARE TRANSACTION complete successfully? I remember
> > Fujii-san said it PANICed if --enable-asserts is used in configure.
> Yes. That assertion failure Fujii-San reported in the past
> was solved by having rmid != RM_XACT_ID in XLogInsert()
> to add WAL generation for transaction completes.
> That I missed the condition was the cause but fine now.
>
> Plus, PREPARE TRANSACTION and COMMIT PREPARED
> works successfully at present when no happening occurs.
>
Thank you for updating the patch.
- (errmsg("WAL was generated with wal_level=minimal,
data may be missing"),
+ (errmsg("WAL was generated with wal_level<=minimal,
data may be missing"),
errhint("This happens if you temporarily set
wal_level=minimal without taking a new base backup.")));
'wal_level=minimal' in errhint also needs to be changed to 'wal_level<=minimal'?
While testing the patch on some workload, I realized that
XLOG_FPI_FOR_HINT record could still be emitted even when wal_level =
none. IIUC that WAL record is not necessary during wal_level = none
since the server cannot be the primary server and the server crash
ends up requiring to restore the whole database.
Regards,
--
Masahiko Sawada
EnterpriseDB: https://www.enterprisedb.com/
