Re: Logging WAL when updating hintbit
От | Heikki Linnakangas |
---|---|
Тема | Re: Logging WAL when updating hintbit |
Дата | |
Msg-id | 52AB1965.5010409@vmware.com обсуждение исходный текст |
Ответ на | Re: Logging WAL when updating hintbit (Sawada Masahiko <sawada.mshk@gmail.com>) |
Ответы |
Re: Logging WAL when updating hintbit
Re: Logging WAL when updating hintbit |
Список | pgsql-hackers |
On 12/13/2013 07:55 AM, Sawada Masahiko wrote: > On Fri, Dec 13, 2013 at 1:51 PM, Dilip kumar <dilip.kumar@huawei.com> wrote: >> On 04 December 2013, Sawada Masahiko Wrote >> >>> I attached the patch which have modified based on Robert suggestion, >>> and fixed typo. >> >> I have reviewed the modified patch and I have some comments.. >> >> 1. Patch need to be rebased (failed applying on head) >> >> 2. crc field should be at end in ControlFileData struct, because for crc calculation, it directly take the offset of crcfield in ControlFileData. >> >> /* CRC of all above ... MUST BE LAST! */ >> pg_crc32 crc; >> + >> + /* Enable logging WAL when updating hint bits */ >> + bool wal_log_hintbits; >> } ControlFileData; >> 3. wal_log_hintbits field should be printed in PrintControlValues function. Actually, no. It's reset anyway like wal_level and some other settings, so it's not an interesting value to print out. Thanks for the review! > I have modified the patch base on your comment, and I attached the v7 patch. Thanks, committed with some minor changes: The amount of extra WAL-logging with wal_log_hintbits=on is almost, but not exactly the same as with checksums enabled. With checksums enabled, visibilitymap_set() creates a full-page image of the heap page, but with wal_log_hintbits=on, it does not. For pg_rewind's purposes, that's correct, but I feel that it would be better if the decision on whether to WAL-log or not was exactly the same in both cases. One reason is that you could then use wal_log_hintbits=on to evaluate how big the impact on WAL volume would be if you had checksums enabled. I committed it that way. OTOH, for pg_rewind's purposes, there's actually no need to take a full page image when a hint bit is set. A small WAL-record indicating that the page was modified would be enough. It's particularly strange to insist that hint bit updates create full-page images, when you have full_page_writes=off so that normal updates don't create them. We're a bit schizophrenic with full page writes also when data checksums are enabled, though. If I'm reading the code correctly, you can turn full_page_writes=off even when data checksums are enabled, which exposes you to torn page problems. Which might be OK under some special circumstances. But you'll still get full-page images of hint bits! I think it's a bit excessive to require wal_level > minimal if you set wal_log_hintbits=on. It's a bit silly to ask for wal_log_hintbits=on without archiving, but I also don't see a big reason to throw an error. It would be annoying, if you want to e.g temporarily set wal_level=minimal when you do a big data load, and re-initialize the standby afterwards. Now you'd also need to remember to turn wal_log_hintbits=off temporarily, and remember to turn it back on afterwards. So I just removed that check. I'm not totally satisfied with the name of the GUC, wal_log_hintbits. The term "hint bits" doesn't mean anything to most people. I couldn't come up with anything better, but if someone has a better suggestion, we can still change it. - Heikki
В списке pgsql-hackers по дате отправления: