Re: RecordTransactionCommit() and SharedInvalidationMessages

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: RecordTransactionCommit() and SharedInvalidationMessages
Дата
Msg-id AANLkTikM7=t5POHjHBt8KbMTsqGahQuU0N+0+CbUj6B9@mail.gmail.com
обсуждение исходный текст
Ответ на Re: RecordTransactionCommit() and SharedInvalidationMessages  (Fujii Masao <masao.fujii@gmail.com>)
Ответы Re: RecordTransactionCommit() and SharedInvalidationMessages  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Список pgsql-hackers
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.  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.

Other opinions?

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Kevin Grittner"
Дата:
Сообщение: Re: Regression tests versus the buildfarm environment
Следующее
От: Boszormenyi Zoltan
Дата:
Сообщение: Inconsistent ::bit(N) and get_bit()?