Re: RecordTransactionCommit() and SharedInvalidationMessages - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: RecordTransactionCommit() and SharedInvalidationMessages
Date
Msg-id 4C62B526.2000103@enterprisedb.com
Whole thread Raw
In response to Re: RecordTransactionCommit() and SharedInvalidationMessages  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: RecordTransactionCommit() and SharedInvalidationMessages
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: string_to_array with an empty input string
Next
From: Tom Lane
Date:
Subject: Re: string_to_array with an empty input string