Re: [HACKERS] WAL logging problem in 9.4.3? - Mailing list pgsql-hackers
From | Robert Haas |
---|---|
Subject | Re: [HACKERS] WAL logging problem in 9.4.3? |
Date | |
Msg-id | CA+TgmoZHsEN9c=mphT_7jg3AANDzWaz4AKD2kMkRRpcNtaWebg@mail.gmail.com Whole thread Raw |
In response to | Re: [HACKERS] WAL logging problem in 9.4.3? (Noah Misch <noah@leadboat.com>) |
Responses |
Re: [HACKERS] WAL logging problem in 9.4.3?
|
List | pgsql-hackers |
On Wed, Apr 1, 2020 at 11:51 PM Noah Misch <noah@leadboat.com> wrote: > I've translated the non-vote comments into estimated votes of -0.3, -0.6, > -0.4, +0.5, and -0.3. Hence, I revoke the plan to back-patch. FWIW, I also think that it would be better not to back-patch. The risk of back-patching is that this will break things, whereas the risk of not back-patching is that we will harm people who are affected by this bug for a longer period of time than would otherwise be the case. Because this patch is complex, the risk of breaking things seems higher than normal. On the other hand, the number of users adversely affected by the bug appears to be relatively low. Taken together, these factors persuade me that we should not back-patch at this time. It is possible that in the future things may look different. In the happy event that this patch causes no more problems following commit, while at the same time we have more complaints about the underlying problem, we can make a decision to back-patch at a later time. This brings me to another point: because this patch changes the WAL format, a straight revert will be impossible once a release has occurred. Therefore, if we hold off on back-patching for now and later decide that we erred, we can proceed at that time and it will probably not be much harder than it would be to do it now. On the other hand, if we decide to back-patch now and later decide that we have erred, we will have additional engineering work to do to cater to people who have already installed the version containing the back-patched fix and now need to upgrade again. Perhaps the WAL format changes are simple enough that this isn't likely to be a huge issue even if it happens, but it does seem better to avoid the chance that it might. A further factor is that releases which break WAL compatibility are undesirable, and should only be undertaken when necessary. Last but not least, I would like to join with others in expressing my thanks to you for your hard work on this problem. While the process of developing a fix has not been without bumps, few people would have had the time, patience, diligence, and skill to take this effort as far as you have. Kyotaro Horiguchi and others likewise deserve credit for all of the many hours that they have put into this work. The entire PostgreSQL community owes all of you a debt of gratitude, and you have my thanks. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
pgsql-hackers by date: