RE: Disable WAL logging to speed up data loading - Mailing list pgsql-hackers

From osumi.takamichi@fujitsu.com
Subject RE: Disable WAL logging to speed up data loading
Date
Msg-id OSBPR01MB48883072D368C336F640A063EDFB0@OSBPR01MB4888.jpnprd01.prod.outlook.com
Whole thread Raw
In response to RE: Disable WAL logging to speed up data loading  ("tsunakawa.takay@fujitsu.com" <tsunakawa.takay@fujitsu.com>)
Responses Re: Disable WAL logging to speed up data loading  (Masahiko Sawada <sawada.mshk@gmail.com>)
List pgsql-hackers
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.

Best,
    Takamichi Osumi


Attachment

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: "as quickly as possible" (was: remove spurious CREATE INDEX CONCURRENTLY wait)
Next
From: Kyotaro Horiguchi
Date:
Subject: Re: Strange behavior with polygon and NaN