Re: RecordTransactionCommit() and SharedInvalidationMessages

On 11/08/10 16:46, Robert Haas wrote:
> On Wed, Aug 11, 2010 at 1:17 AM, Fujii Masao<masao(dot)fujii(at)gmail(dot)com> wrote:
>> On Tue, Aug 10, 2010 at 9:30 AM, Robert Haas<robertmhaas(at)gmail(dot)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