Re: Parallel INSERT (INTO ... SELECT ...)
От | Amit Kapila |
---|---|
Тема | Re: Parallel INSERT (INTO ... SELECT ...) |
Дата | |
Msg-id | CAA4eK1LdtPK_hzmYxPVENT4i5A-a5QNng7Dk=B1L=2=h4v1z3w@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Parallel INSERT (INTO ... SELECT ...) (Greg Nancarrow <gregn4422@gmail.com>) |
Ответы |
Re: Parallel INSERT (INTO ... SELECT ...)
|
Список | pgsql-hackers |
On Mon, Jan 18, 2021 at 3:50 PM Greg Nancarrow <gregn4422@gmail.com> wrote: > > On Mon, Jan 18, 2021 at 8:10 PM Amit Kapila <amit.kapila16@gmail.com> wrote: > > > > > >It is not clear why the above two are shouldn't happen cases and if so > > > >why we want to treat them as unsafe. Ideally, there should be an > > > >Assert if these can't happen but it is difficult to decide without > > > >knowing why you have considered them unsafe? > > > > > > The checks being done here for "should never happen" cases are THE > > > SAME as other parts of the Postgres code. > > > For example, search Postgres code for "null conbin" and you'll find 6 > > > other places in the Postgres code which actually ERROR out if conbin > > > (binary representation of the constraint) in a pg_constraint tuple is > > > found to be null. > > > The cases that you point out in the patch used to also error out in > > > the same way, but Vignesh suggested changing them to just return > > > parallel-unsafe instead of erroring-out, which I agree with. > > > > > > > You have not raised a WARNING for the second case. > > The same checks in current Postgres code also don't raise a WARNING > for that case, so I'm just being consistent with existing Postgres > code (which itself isn't consistent for those two cases). > Search for the string "too few entries in indexprs list" and you will find a lot of places in code raising ERROR for the same condition. -- With Regards, Amit Kapila.
В списке pgsql-hackers по дате отправления: