On Fri, Aug 27, 2010 at 11:25 PM, Heikki Linnakangas <heikki.linnakan...@enterprisedb.com> wrote: > Hmm, agreed, seems like an oversight in hot standby. Before that, we didn't > update pg_subtrans during recovery, so there was no point truncating it. But > in hot standby, we do update it, so we need to truncate it too.
Yes. The attached patch changes a restartpoint so that it truncates pg_subtrans when hot standby is enabled. When it's disabled, we need to do nothing because, in that case, pg_subtrans is not updated during recovery and StartupSUBTRANS() is not called before a restartpoint. Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center
*** a/src/backend/access/transam/xlog.c --- b/src/backend/access/transam/xlog.c *************** *** 7706,7715 **** CreateRestartPoint(int flags) } /* ! * Currently, there is no need to truncate pg_subtrans during recovery. If ! * we did do that, we will need to have called StartupSUBTRANS() already ! * and then TruncateSUBTRANS() would go here. */ /* All real work is done, but log before releasing lock. */ if (log_checkpoints) --- 7706,7719 ---- } /* ! * Truncate pg_subtrans if possible. We can throw away all data before ! * the oldest XMIN of any running transaction. No future transaction will ! * attempt to reference any pg_subtrans entry older than that (see Asserts ! * in subtrans.c). When hot standby is disabled, though, we mustn't do ! * this because StartupSUBTRANS hasn't been called yet. */ + if (EnableHotStandby) + TruncateSUBTRANS(GetOldestXmin(true, false)); /* All real work is done, but log before releasing lock. */ if (log_checkpoints)
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers