Re: Updating FSM on recovery
От | Tom Lane |
---|---|
Тема | Re: Updating FSM on recovery |
Дата | |
Msg-id | 11303.1225283814@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Updating FSM on recovery (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>) |
Ответы |
Re: Updating FSM on recovery
|
Список | pgsql-hackers |
Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes: > The FSM would be perfectly happy to just initialize torn or otherwise > damaged pages, so I think we should add yet another mode to ReadBuffer() > to allow that. We could also treat read() errors as merely warnings in > that mode, effectively the same as with zero_damaged_pages=on. > The ReadBuffer() interface is already pretty complex, with all the > different variants. We should probably keep the good old ReadBuffer() > the same, for the sake of simplicity in the callers, but try to reduce > the number of other variatns. Indeed. Did you see the discussion about the similarly-too-complex heap_insert API a couple days ago in connection with bulk-write scenarios? The conclusion there was to try to shift stuff into a bitmask options argument, in hopes that future additions might not require touching every caller. Can we do it similarly here? regards, tom lane
В списке pgsql-hackers по дате отправления: