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

Reply via email to