Amit Kapila <amit.kap...@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 -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers