Re: RecordTransactionCommit() and SharedInvalidationMessages

Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>

From: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Fujii Masao <masao.fujii@gmail.com>, pgsql-hackers@postgresql.org
Date: 2010-08-11T14:35:18Z
Lists: 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