Re: Segfault when creating partition with a primary key and sql_droptrigger exists
| От | Jonathan S. Katz |
|---|---|
| Тема | Re: Segfault when creating partition with a primary key and sql_droptrigger exists |
| Дата | |
| Msg-id | 4251494e-87ce-7be8-ee33-43e95967a1bf@postgresql.org обсуждение |
| Ответ на | Re: Segfault when creating partition with a primary key and sql_droptrigger exists (Andres Freund <andres@anarazel.de>) |
| Список | pgsql-hackers |
On 10/5/18 3:35 PM, Andres Freund wrote: > Hi, > > On 2018-10-05 15:31:37 -0400, Jonathan S. Katz wrote: >> On 10/4/18 11:37 PM, Tom Lane wrote: >>> "Jonathan S. Katz" <jkatz@postgresql.org> writes: >>>> On 10/4/18 8:34 PM, Michael Paquier wrote: >>>>> I am suggesting to fix the issue after RC1 is released, but before GA. >>> >>>> That approach would mean we would require an RC2, which would further >>>> delay the GA. >>> >>> Not sure about that. Alvaro seems to think there's a generic problem >>> in event trigger processing, which if true, was likely there pre-v11. >>> I don't think that patches that get back-patched further than 11 >>> need to restart the RC clock. >> >> Well, unless we are targeting it for the release? AIUI the RCs are >> should be equivalent to GA[1] (and yes I see the qualifier of "should be"). > > FWIW, I think that's a pretty pointless restriction. We release > bugfixes in minor releases all the time, so there's imo absolutely no > point in having a blanket restriction that a fix that we'd put in a > minor release shouldn't be slipped in between RC and GA. Sounds reasonable to me. Without this getting too off-thread, I'm happy to update language on pgweb to better describe what a release candidate is and how it can differ with GA. Jonathan
Вложения
В списке pgsql-hackers по дате отправления: