Re: Summary and Plan for Hot Standby
От | Heikki Linnakangas |
---|---|
Тема | Re: Summary and Plan for Hot Standby |
Дата | |
Msg-id | 4B00604D.1020702@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: Summary and Plan for Hot Standby (Simon Riggs <simon@2ndQuadrant.com>) |
Список | pgsql-hackers |
Simon Riggs wrote: > On Sun, 2009-11-15 at 21:20 +0200, Heikki Linnakangas wrote: >> Simon Riggs wrote: >>> On Sun, 2009-11-15 at 20:30 +0200, Heikki Linnakangas wrote: >>> >>>> The LSN doesn't help there, because when an itemid is marked as dead, >>>> the LSN is not updated. >>> I was thinking we could update the index block LSN without writing WAL >>> using the LSN of the heap block that leads to the killed tuple. >> That can be before the cleanup record we write before we start the index >> vacuum. > > Oh well. Strike 1. > > But the technique sounds OK, we just need to get the LSN of a HeapInfo > record from somewhere, say, index metapage. Sounds like we need to do > something similar with the xid. I'm thinking that we should address the general issue, not just with vacuum-related deletion records. For the vacuum-related deletion records, we can just leave the code as it is. I think we talked about various approaches about a year ago when we first realized that killed index tuples are a problem, though I don't think we carved out a full solution. We could for example stored the xmax (or xmin if it was inserted by an aborted transaction) of the killed tuple in the b-tree page header whenever we mark an index tuple as dead. We could then include that in the WAL record. The trick is how to make that crash-safe. (but this whole thing is certainly something we can defer until later) -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: