Обсуждение: CF bug fix items
I've been looking over the older items in the CF, specifically those in the "bug fix" category. Six of them are marked "ready for committer" and all of those have a committer named as either author or reviewer. It would be good to get those committed as soon as possible. So Heikki, Michael, Alexander, Simon, Etsuro and Thomas, that means you :-) Pleas claim and commit those if possible, or at least move them forward. In one of those cases, "ConvertRowtypeExpr reference errors from partition-wise join", the patch has been marked Ready for Committer and then Etsuro seems to have changeed his mind. If it's not ready it should be set back to "needs review" or "waiting for author". Two other items in that list have been around for embarrassingly large amounts of time. "Fix the optimization to skip WAL-logging on table created in same transaction" has been in 10 (!) commitfests. It's seen no substantive action since November. It has a bunch of authors and reviewers listed, Surely somebody can move it forward? "Fix a bug that can prevent standby from restarting" has been around for 6 CFs. This appears to be covered by commit 0668719801838aa6a8bda330ff9b3d20097ea844. Can we just closed this one out? If there's more work left to do another CF item could be added. Of the rest that have been around since January, "pg_rewind corrupts control file global/pg_control" discussion stopped in April. Tom had made some comments to which Michael responded. "Temporary tables prevent autovacuum, leading to XID wraparound" discussion stopped in March, with some possible disagreement between Robert and Tom. "Configuring messages language on Windows" has never been reviewed at all. "Produce a crash dump before main() on Windows", discussion stopped in March. "fix constraint exclusion failure for certain partition key types" appears to need some extra attention, especially from people who have a deep knowledge of constraint exclusion. cheers andrew -- Andrew Dunstan https://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Sun, Jun 10, 2018 at 10:41:26AM -0400, Andrew Dunstan wrote: > Six of them are marked "ready for committer" and all of those have a > committer named as either author or reviewer. It would be good to get those > committed as soon as possible. So Heikki, Michael, Alexander, Simon, Etsuro > and Thomas, that means you :-) Pleas claim and commit those if possible, or > at least move them forward. Thanks for beginning this thread and summarizing the situation. > "Fix the optimization to skip WAL-logging on table created in same > transaction" has been in 10 (!) commitfests. It's seen no substantive action > since November. It has a bunch of authors and reviewers listed, Surely > somebody can move it forward? I think that this is a complicated topic, which results in a rather large and invasive patch introducing new logic concepts in order to fix a rather narrow use-case. So I am wondering if it is really something we ought to fix here.. > "Fix a bug that can prevent standby from restarting" has been around for 6 > CFs. This appears to be covered by commit > 0668719801838aa6a8bda330ff9b3d20097ea844. Can we just closed this one out? > If there's more work left to do another CF item could be added. Yes, I have marked it as committed. > Of the rest that have been around since January, > > "pg_rewind corrupts control file global/pg_control" discussion stopped in > April. Tom had made some comments to which Michael responded. Yeah, for this one I can see a bunch of approaches, and each one has unwelcome downsides, so if we were to patch something I think that I would go with the documentation-only patch. Something which could be considered for the future is to extend pg_stat_file so as it returns the umask of a file which could be used as a filter. The good thing is that we use stat() in pg_stat_file() which would return the info about the file a symlink points to. The thing is that we need to look at files which cannot be written locally as well as remotely. So it may be a lot of facility for a small use-case, still that could be an interesting set of two TODO items (one for pg_rewind, one to extend pg_stat_file). > "Produce a crash dump before main() on Windows", discussion stopped in > March. So the commit fest entry is here: https://commitfest.postgresql.org/18/1525/ Noah has committed a portion of things with cbfffee4. Craig, as you already looked at the first patch, perhaps you could check the latest version? Or Noah as you looked at the thread? "Cascaded standby cannot start after a shutdown" which is here is something I already reviewed and proposed a solution for, so I could look at that again: https://commitfest.postgresql.org/18/1516/ "Failure at replay for corrupted 2PC files + reduce window between end-of-recovery record and history file write" is also something worrying me per the way we simply ignore on-disk 2PC files which are corrupted in the data directory. So I could look at this one if there are no objections. The last set of patches is here as well: https://www.postgresql.org/message-id/CAB7nPqT9V6N7Wm7npkqcHf-beLtZ82z2dNG_5cwfBLg%3Dm5PfUw%40mail.gmail.com -- Michael
Вложения
(2018/06/10 23:41), Andrew Dunstan wrote: > I've been looking over the older items in the CF, specifically those in > the "bug fix" category. > > Six of them are marked "ready for committer" and all of those have a > committer named as either author or reviewer. It would be good to get > those committed as soon as possible. So Heikki, Michael, Alexander, > Simon, Etsuro and Thomas, that means you :-) Pleas claim and commit > those if possible, or at least move them forward. Thanks for the summary! > In one of those cases, "ConvertRowtypeExpr reference errors from > partition-wise join", the patch has been marked Ready for Committer and > then Etsuro seems to have changeed his mind. If it's not ready it should > be set back to "needs review" or "waiting for author". Yeah, I don't think the proposed patch is the right way to go, so I'm proposing another solution for that, which I think makes code much simple, but I'd like to hear the opinion from Robert, who is the owner of PWJ. (I marked this as Ready for Committer partly because I wanted to hear the opinion.) Anyway, I think this is an open item for PG11, so I'll add this to that list for PG11. Best regards, Etsuro Fujita
On 06/11/2018 07:08 AM, Etsuro Fujita wrote: > > >> In one of those cases, "ConvertRowtypeExpr reference errors from >> partition-wise join", the patch has been marked Ready for Committer and >> then Etsuro seems to have changeed his mind. If it's not ready it should >> be set back to "needs review" or "waiting for author". > > Yeah, I don't think the proposed patch is the right way to go, so I'm > proposing another solution for that, which I think makes code much > simple, but I'd like to hear the opinion from Robert, who is the owner > of PWJ. (I marked this as Ready for Committer partly because I wanted > to hear the opinion.) I don't think that's the way we should use "Ready for Committer". I suggest you ,move it back to "Needs Review". > > Anyway, I think this is an open item for PG11, so I'll add this to > that list for PG11. Ok, good. cheers andrew -- Andrew Dunstan https://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
(2018/06/11 20:34), Andrew Dunstan wrote: > On 06/11/2018 07:08 AM, Etsuro Fujita wrote: >>> In one of those cases, "ConvertRowtypeExpr reference errors from >>> partition-wise join", the patch has been marked Ready for Committer and >>> then Etsuro seems to have changeed his mind. If it's not ready it should >>> be set back to "needs review" or "waiting for author". >> >> Yeah, I don't think the proposed patch is the right way to go, so I'm >> proposing another solution for that, which I think makes code much >> simple, but I'd like to hear the opinion from Robert, who is the owner >> of PWJ. (I marked this as Ready for Committer partly because I wanted >> to hear the opinion.) > > I don't think that's the way we should use "Ready for Committer". I > suggest you ,move it back to "Needs Review". Done. Best regards, Etsuro Fujita
On 2018-Jun-11, Etsuro Fujita wrote: > (2018/06/11 20:34), Andrew Dunstan wrote: > > On 06/11/2018 07:08 AM, Etsuro Fujita wrote: > > > > In one of those cases, "ConvertRowtypeExpr reference errors from > > > > partition-wise join", the patch has been marked Ready for Committer and > > > > then Etsuro seems to have changeed his mind. If it's not ready it should > > > > be set back to "needs review" or "waiting for author". > > > > > > Yeah, I don't think the proposed patch is the right way to go, so I'm > > > proposing another solution for that, which I think makes code much > > > simple, but I'd like to hear the opinion from Robert, who is the owner > > > of PWJ. (I marked this as Ready for Committer partly because I wanted > > > to hear the opinion.) > > > > I don't think that's the way we should use "Ready for Committer". I > > suggest you ,move it back to "Needs Review". > > Done. Actually, for something that's an open item, there needn't be an entry in the commitfest at all, ISTM. Open items are must-fix for release (unlike older bugs), unless as a community we decide that something is not a bug or that it can go unfixed. So the commitfest entry is unnecessary. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 2018-06-11 13:30:27 +0900, Michael Paquier wrote: > > "Fix the optimization to skip WAL-logging on table created in same > > transaction" has been in 10 (!) commitfests. It's seen no substantive action > > since November. It has a bunch of authors and reviewers listed, Surely > > somebody can move it forward? > > I think that this is a complicated topic, which results in a rather > large and invasive patch introducing new logic concepts in order to fix > a rather narrow use-case. So I am wondering if it is really something > we ought to fix here.. I think we absolutely definitely need to fix it, or remove wal_level=minimal. It's a failure to provide the fundamental guarantees a database should provide. It seems not unreasonable to commit something to v11 and then backpatch a bit later, to manage risk, however. Greetings, Andres Freund
On 06/11/2018 01:11 PM, Andres Freund wrote: > On 2018-06-11 13:30:27 +0900, Michael Paquier wrote: >>> "Fix the optimization to skip WAL-logging on table created in same >>> transaction" has been in 10 (!) commitfests. It's seen no substantive action >>> since November. It has a bunch of authors and reviewers listed, Surely >>> somebody can move it forward? >> I think that this is a complicated topic, which results in a rather >> large and invasive patch introducing new logic concepts in order to fix >> a rather narrow use-case. So I am wondering if it is really something >> we ought to fix here.. > I think we absolutely definitely need to fix it, or remove > wal_level=minimal. It's a failure to provide the fundamental guarantees > a database should provide. It seems not unreasonable to commit something > to v11 and then backpatch a bit later, to manage risk, however. > > What goes into 11 doesn't have the same non-breakage requirements as something on the back branches. This bug report has been around far too long, and I suspect the main reason we've not been bitten by it more is that most people don't run with minimal. cheers andrew -- Andrew Dunstan https://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services