Re: Bug in new buffer freelist code
От | Jan Wieck |
---|---|
Тема | Re: Bug in new buffer freelist code |
Дата | |
Msg-id | 3FE8E5B3.4050803@Yahoo.com обсуждение исходный текст |
Ответ на | Re: Bug in new buffer freelist code (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Bug in new buffer freelist code
|
Список | pgsql-hackers |
Tom Lane wrote: > Jan Wieck <JanWieck@Yahoo.com> writes: >> It seems to me that buffers that are thrown away via >> StrategyInvalidateBuffer() do not get their relnode and blocknum cleaned >> out. > > Mmmm. They definitely should be; if you look at the prior version of > buf_table.c, BufTableDelete did this: > > /* > * Clear the buffer's tag. This doesn't matter for the hash table, > * since the buffer is already removed from it, but it ensures that > * sequential searches through the buffer table won't think the buffer > * is still valid for its old page. > */ > buf->tag.rnode.relNode = InvalidOid; > buf->tag.rnode.tblNode = InvalidOid; > > I see you removed that from the current version, but the equivalent > thing needs to be done someplace. Is StrategyInvalidateBuffer the > right place? Yeah, looks like ... but I actually want to have a clean reproduction of the error before I attempt to fix it. Will look at it deeper. > > BTW, it kinda looks like the BM_DELETED flag bit is useless now? I think so, together with the BM_FREE which was redundant anyway. Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck@Yahoo.com #
В списке pgsql-hackers по дате отправления: