> 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.
I got the point that we cannot reconstruct a consistent database where further operations can be allowed. > 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. The further corruption can only be possible when we replay some wrong WAL by selecting wrong LSN. Do you mean to say that if next-LSN is selected from pages, it will be a better position for starting Replay. On the otherhand if we don't have to replay the WAL and just take the dump, how it will matter what is 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. Yes, that is right but the solution I have purposed in my first mail was not to reset it after getting consistent checkpoint and generating control file values from it. However now I understand that the problem and solution definition should consider that some WAL files are missing. > 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. I will collect all the requirements that can be done in this area from existing mails and think more in it to generate concrete set of requirements that can be helpful to users to over come such situations. Requirements or suggestions from all are most welcome. It can help me to do some useful work for PostgreSQL. With Regards, Amit Kapila. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
