Re: Hot Backup with rsync fails at pg_clog if under load
От | Simon Riggs |
---|---|
Тема | Re: Hot Backup with rsync fails at pg_clog if under load |
Дата | |
Msg-id | CA+U5nMKx-N5Qmn6FwpvSoLhTqDp70U+tWJ59=t=--KUH3uhP7g@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Hot Backup with rsync fails at pg_clog if under load (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Hot Backup with rsync fails at pg_clog if under load
|
Список | pgsql-hackers |
On Thu, Oct 27, 2011 at 4:36 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.com> writes: >> On Wed, Oct 26, 2011 at 12:16 PM, Simon Riggs <simon@2ndquadrant.com> wrote: >>> This fixes both the subtrans and clog bugs in one patch. > >> I don't see the point of changing StartupCLOG() to be an empty >> function and adding a new function TrimCLOG() that does everything >> StartupCLOG() used to do. > > +1 ... I found that overly cute also. It would have been even easier to move StartupCLOG() later, but then we'd need a big comment explaining why CLOG starts up at one point and subtrans starts up at another point, since that is very confusing way of doing things. I wrote it that way first and it definitely looks strange. It's much easier to understand that StartupCLOG() is actually a no-op and that we need to trim the clog at the end of recovery in all cases. The patch isn't meant to be cute, just a better of way of expressing what needs to be done, so I think the patch should stay that way. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: