Re: Changing WAL Header to reduce contention during ReserveXLogInsertLocation()
От | Robert Haas |
---|---|
Тема | Re: Changing WAL Header to reduce contention during ReserveXLogInsertLocation() |
Дата | |
Msg-id | CA+Tgmoa_rikAC7WxNoR5zyCm5QiD=H1-uQ6K-uTb2OJV-9BodQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Changing WAL Header to reduce contention during ReserveXLogInsertLocation() (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Changing WAL Header to reduce contention during ReserveXLogInsertLocation()
|
Список | pgsql-hackers |
On Tue, Mar 27, 2018 at 11:41 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Pavan Deolasee <pavan.deolasee@gmail.com> writes: >> On Tue, Mar 27, 2018 at 7:28 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >>> If you have to search backwards, this breaks it. Full stop. > >> We don't really need to fetch the previous record. We really need to find >> the last checkpoint prior to a given LSN. That can be done by reading WAL >> segments forward. It can be a little slow, but hopefully not a whole lot. > > This is ignoring the possibility of damaged data in between, ie > > A ... B ... CHKPT ... C ... a few zeroed pages ... D ... CHKPT ... E ... F > > If A is the start of the WAL segment, and you ask what's the last > checkpoint before F, you will get the wrong answer. Or, if you're > paranoid and verify that you can follow the chain all the way to F, > you'll fail ... needlessly, and in a case where we previously succeeded. It's hard for me to believe that this case matters very much. If you're trying to run pg_rewind on a system where the WAL segments contain a few zeroed pages, you're probably going to be hosed anyway, if not by this particular thing then by something else. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: