Re: Review: Patch to compute Max LSN of Data Pages
От | Amit Kapila |
---|---|
Тема | Re: Review: Patch to compute Max LSN of Data Pages |
Дата | |
Msg-id | CAA4eK1LjD1C5A12s8vPGn8K94-N9HKxGkeJbO-rkEK6sre23EA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Review: Patch to compute Max LSN of Data Pages (Alvaro Herrera <alvherre@2ndquadrant.com>) |
Список | pgsql-hackers |
On Fri, Oct 18, 2013 at 9:24 PM, Alvaro Herrera <alvherre@2ndquadrant.com> wrote: > Robert Haas escribió: > >> A broader complaint I have with this patch is that it almost but >> not-quite solves a problem I've had a few times in the past: namely, >> searching through the data directory for data blocks which have LSNs >> in the future. This has come up a few times for me, and this tool >> would make it easier, because I'd be able to run it and look through >> the output to see which relations have high max-LSN values. However, >> it wouldn't be quite enough, because it'd only tell me about the block >> with the highest LSN in each file, whereas what I'd really want to >> find is every block with an LSN greater than some threshold value. >> Maybe I'm pushing the envelope too much by trying to fit that into the >> framework of this patch, but I can't help thinking we're not going to >> want both pg_computemaxlsn and pg_findlsnsaftersomethreshold that are >> 95% the same code, so maybe we ought to rename the utility to >> something slightly more generic than "pg_computemaxlsn". > > Perhaps not coincidentally, I had a need to do this recently. Perhaps > we should turn the utility into a generic tool to report existing LSNs, > with options to 1) report only the highest one in a given file, 2) > report only those that exceed some threshold. So maybe pg_reportlsn or > pg_extractlsn. How about extending it validate database in more meaningful way and name it as validatedb. With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: