Re: Review: Patch to compute Max LSN of Data Pages
От | Amit Kapila |
---|---|
Тема | Re: Review: Patch to compute Max LSN of Data Pages |
Дата | |
Msg-id | 008d01ce7300$0a256460$1e702d20$@kapila@huawei.com обсуждение исходный текст |
Ответ на | Re: Review: Patch to compute Max LSN of Data Pages ('Andres Freund' <andres@2ndquadrant.com>) |
Список | pgsql-hackers |
On Thursday, June 27, 2013 11:26 AM Andres Freund wrote: > On 2013-06-27 11:16:25 +0530, Amit Kapila wrote: > > On Wednesday, June 26, 2013 10:19 PM Fujii Masao wrote: > > > On Wed, Jun 26, 2013 at 8:57 PM, Amit Kapila > <amit.kapila@huawei.com> > > > >> > One more use case for which this utility was done is as > below: > > > >> > It will be used to decide that on new-standby (old-master) > > > whether > > > >> a full > > > >> > backup is needed from > > > >> > New-master(old-standby). > > > >> > The backup is required when the data page in old-master > precedes > > > >> > the last applied LSN in old-standby (i.e., new-master) at > the > > > >> moment > > > >> > of the failover. > > > >> > > > >> That's exactly what I was afraid of. Unless I miss something the > > > tool > > > >> is > > > >> *NOT* sufficient to do this. > > > > > > > > You mean to say if user knows the max LSN of data pages in old- > master > > > and > > > > last applied LSN in new master, he cannot decide whether > > > > Full backup is needed? It should be straightforward decision that > > > skip a > > > > backup if that old-master LSN is less than the new-master (i.e., > last > > > > applied LSN, IOW, timeline switch LSN). > > > > It was proposed as a usecase in this below mail: > > > > http://www.postgresql.org/message-id/CAHGQGwHyd1fY0hF0qKh0-uKDh- > > > gcbYxMOFBYVk > > > > Kh4jzji-FCfg@mail.gmail.com > > > > > > I guess he meant the commit hint bit problem. > > > > True, after reading the thread mentioned by Andres, I got the reason > he was > > pointing why it is not sufficient. > > So can it be useful if database has checksums enabled? > > I think for that usecase its far more useful to work on getting > pg_rewind since that has a chance of working when local WAL has been > applied that hadn't yet shipped to the other side (which is frequently > the case). Aren't the use case for both is bit different Pg_computmaxlsn - by computing max lsn for checksums enabled database, user can made old-master follow new-master if maxlsn suggests that fullbackup is not required. Pg_rewind - a tool to resynchronize old-master and new-master by copying changed blocks from new master. I think more work might be needed in case DDL's happened on old-master after forking of new-master. Although for this case, both have resemblance in terms of avoiding full backup, but I think maxlsn tool can be independently also used. Do you think pg_rewind can be used by default for any checksum enabled database to resynchronize old-master? With Regards, Amit Kapila.
В списке pgsql-hackers по дате отправления: