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 (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
