Re: bug in pageinspect's "tuple data" feature
От | Alvaro Herrera |
---|---|
Тема | Re: bug in pageinspect's "tuple data" feature |
Дата | |
Msg-id | 20201124151645.GA11584@alvherre.pgsql обсуждение исходный текст |
Ответ на | Re: bug in pageinspect's "tuple data" feature (Michael Paquier <michael@paquier.xyz>) |
Список | pgsql-hackers |
On 2020-Nov-24, Michael Paquier wrote: > On Mon, Nov 23, 2020 at 09:11:26AM +0200, Heikki Linnakangas wrote: > > On 21/11/2020 21:32, Alvaro Herrera wrote: > >> This is pretty unhelpful; it would be better not to try to print the > >> data instead of dying. With that, at least you can know where the > >> problem is. > >> > >> This was introduced in d6061f83a166 (2015). Proposed patch to fix it > >> (by having the code print a null "data" instead of dying) is attached. > > > > Null seems misleading. Maybe something like "invalid", or print a warning? Good idea, thanks. > How did you get into this state to begin with? The data was corrupted for whatever reason. I don't care why or how, I just need to fix it. If the data isn't corrupted, then I don't use pageinspect in the first place. > get_raw_page() uses ReadBufferExtended() which gives some level of > protection already, so shouldn't it be better to return an ERROR with > ERRCODE_DATA_CORRUPTED and the block involved? What would I gain from doing that? It's even more unhelpful, because it is intentional rather than accidental.
В списке pgsql-hackers по дате отправления: