Re: RecordTransactionCommit() and SharedInvalidationMessages
От | Heikki Linnakangas |
---|---|
Тема | Re: RecordTransactionCommit() and SharedInvalidationMessages |
Дата | |
Msg-id | 4C62B526.2000103@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: RecordTransactionCommit() and SharedInvalidationMessages (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: RecordTransactionCommit() and SharedInvalidationMessages
|
Список | pgsql-hackers |
On 11/08/10 16:46, Robert Haas wrote: > On Wed, Aug 11, 2010 at 1:17 AM, Fujii Masao<masao.fujii@gmail.com> wrote: >> On Tue, Aug 10, 2010 at 9:30 AM, Robert Haas<robertmhaas@gmail.com> wrote: >>> It appears to me that RecordTransactionCommit() only needs to WAL-log >>> shared invalidation messages when wal_level is hot_standby, but I >>> don't see a guard to prevent it from doing it in all cases. >> >> Perhaps right. During not hot standby, there is no backend which the >> startup process should send invalidation message to in the standby. >> So, ISTM we don't need to log invalidation message when wal_level is >> not hot_standby. > > The fix looks pretty simple (see attached), although I don't have any > clear idea how to test it. Should use XLogStandbyInfoActive() macro, for the sake of consistency. > I guess the question is whether we should > back-patch this to 9.0. It isn't technically necessary for > correctness, but the whole point of introducing the wal_level GUC was > to insulate people not running Hot Standby from possible bugs in the > Hot Standby code, as well as to avoid unnecessary WAL bloat, so on > balance I'm inclined to think we should go ahead and back-patch it. +1 for backpatching. Keeping the branches closer to each other makes backporting any future fixes easier too. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: