On Fri, Mar 11, 2016 at 2:35 PM, Kartyshov Ivan <i.kartys...@postgrespro.ru> wrote: > You wrote "If you care about the oldest record available you should look for > the first LSN position of the oldest segment, no?" > Yes I do it exactly this way.
Your patch does that: + XLogRecPtr result; + + XLogSegNoOffsetToRecPtr(XLogGetLastRemovedSegno()+1, 1, result); + return result; So basically it returns the first possible LSN position of the last segment present in pg_xlog. That's not true, this LSN position is not the LSN of the oldest record, you are missing the header at the beginning of the segment. + if (RecoveryInProgress()) + ereport(ERROR, + (errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE), + errmsg("recovery is in progress"), + errhint("WAL control functions cannot be executed during recovery."))); I also don't get why this restriction is necessary. Segments get recycled and removed as well at recovery. In short, I finally understood why I was intuitively in meh-state with this patch. If we want to have a SQL representation of what is in shared memory for XLogCtlData, I think that this patch is too much limited. Things like lastSegSwitchTime would be useful as well, at least in my view some of them are interesting for debugging purposes. If you have the last segment name removed returned as text at SQL level, you could then compile the LSN position you'd wish to have for your stuff. -- Michael -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers