Amit Kapila <amit.kapila@huawei.com> writes:
>> I'm almost inclined to suggest that we not get next-LSN from WAL, but
>> by scanning all the pages in the main data store and computing the max
>> observed LSN. This is clearly not very attractive from a performance
>> standpoint, but it would avoid the obvious failure mode where you lost
>> some recent WAL segments along with pg_control.
> According to my analysis, this will have some problem.
I think you're missing the point. There is no possible way to guarantee
database consistency after applying pg_resetxlog, unless the database
had been cleanly shut down beforehand. The reset will lose the xlog
information that was needed to restore consistency. So arguing from
examples that demonstrate this is rather pointless. Rather, the value
of pg_resetxlog is to be able to start the database at all so that info
can be extracted from it. What we are looking for is not perfection,
because that's impossible, but just to not make a bad situation worse.
The reason I'm concerned about selecting a next-LSN that's certainly
beyond every LSN in the database is that not doing so could result in
introducing further corruption, which would be entirely avoidable with
more care in choosing the next-LSN.
> Pg_resetxlog -
> It will generate the next-LSN point as 109 which when used for recovery will generate inconsistent database.
> However if we would have relied on WAL, it would have got next-LSN as 107.
Umm ... the entire point of pg_resetxlog is to throw away WAL. Not to
rely on it.
It's conceivable that there would be some use in a tool that searches
the available WAL files for the latest checkpoint record and recreates a
pg_control file pointing at that checkpoint, without zapping the WAL
files. This would be much different in purpose and usage from
pg_resetxlog, though.
regards, tom lane