On Wed, Aug 11, 2010 at 11:35 PM, Heikki Linnakangas <heikki.linnakan...@enterprisedb.com> wrote: > On 11/08/10 16:46, Robert Haas wrote: >> >> On Wed, Aug 11, 2010 at 1:17 AM, Fujii Masao<masao.fu...@gmail.com> >> wrote: >>> >>> On Tue, Aug 10, 2010 at 9:30 AM, Robert Haas<robertmh...@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.
And, RelcacheInitFileInval should be initialized with false just in case. >> 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. +1 Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
