Re: Hot Standby: Caches and Locks
От | Tom Lane |
---|---|
Тема | Re: Hot Standby: Caches and Locks |
Дата | |
Msg-id | 9246.1225369828@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Hot Standby: Caches and Locks (Simon Riggs <simon@2ndQuadrant.com>) |
Ответы |
Re: Hot Standby: Caches and Locks
|
Список | pgsql-hackers |
Simon Riggs <simon@2ndQuadrant.com> writes: >> We can't augment the commit/abort messages because >> we must cater for non-transactional invalidations also, plus commit >> xlrecs are already complex enough. So we log invalidations prior to >> commit, queue them and then trigger the send at commit (if it >> happens). > Augmenting the commit messages seems like the better approach. It allows > invalidation messages to be fired as they are read off the xlrec. Still > need the additional message type to handle nontransactional > invalidation. There are other messages possibly more complex than this > already. I guess I hadn't been paying attention, but: adding syscache inval traffic to WAL seems like a completely horrid idea, both from the complexity and performance standpoints. What about using the existing syscache logic to re-derive inval information from watching the update operations? regards, tom lane
В списке pgsql-hackers по дате отправления: