Re: POC PATCH: copy from ... exceptions to: (was Re: VLDB Features)
От | jian he |
---|---|
Тема | Re: POC PATCH: copy from ... exceptions to: (was Re: VLDB Features) |
Дата | |
Msg-id | CACJufxFY2pL7SMOsu4ViwmoxRTLK3rroTuhNRbhcB9wPr+x_3A@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: POC PATCH: copy from ... exceptions to: (was Re: VLDB Features) (vignesh C <vignesh21@gmail.com>) |
Ответы |
Re: POC PATCH: copy from ... exceptions to: (was Re: VLDB Features)
|
Список | pgsql-hackers |
On Fri, Jan 5, 2024 at 12:05 AM vignesh C <vignesh21@gmail.com> wrote: > > On Thu, 28 Dec 2023 at 09:27, jian he <jian.universality@gmail.com> wrote: > > > > On Wed, Dec 20, 2023 at 8:27 PM Masahiko Sawada <sawada.mshk@gmail.com> wrote: > > > > > > > > > Why do we need to use SPI? I think we can form heap tuples and insert > > > them to the error table. Creating the error table also doesn't need to > > > use SPI. > > > > > Thanks for pointing it out. I figured out how to form heap tuples and > > insert them to the error table. > > but I don't know how to create the error table without using SPI. > > Please pointer it out. > > > > > > > > > > copy_errors one per schema. > > > > foo.copy_errors will be owned by the schema: foo owner. > > > > > > It seems that the error table is created when the SAVE_ERROR is used > > > for the first time. It probably blocks concurrent COPY FROM commands > > > with SAVE_ERROR option to different tables if the error table is not > > > created yet. > > > > > I don't know how to solve this problem.... Maybe we can document this. > > but it will block the COPY FROM immediately. > > > > > > > > > > if you can insert to a table in that specific schema let's say foo, > > > > then you will get privilege to INSERT/DELETE/SELECT > > > > to foo.copy_errors. > > > > If you are not a superuser, you are only allowed to do > > > > INSERT/DELETE/SELECT on foo.copy_errors rows where USERID = > > > > current_user::regrole::oid. > > > > This is done via row level security. > > > > > > I don't think it works. If the user is dropped, the user's oid could > > > be reused for a different user. > > > > > > > You are right. > > so I changed, now the schema owner will be the error table owner. > > every error table tuple inserts, > > I switch to schema owner, do the insert, then switch back to the > > COPY_FROM operation user. > > now everyone (except superuser) will need explicit grant to access the > > error table. > > There are some compilation issues reported at [1] for the patch: > [04:04:26.288] copyfromparse.c: In function ‘NextCopyFrom’: > [04:04:26.288] copyfromparse.c:1126:25: error: ‘copy_errors_tupDesc’ > may be used uninitialized in this function > [-Werror=maybe-uninitialized] > [04:04:26.288] 1126 | copy_errors_tup = heap_form_tuple(copy_errors_tupDesc, > [04:04:26.288] | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > [04:04:26.288] 1127 | t_values, > [04:04:26.288] | ~~~~~~~~~ > [04:04:26.288] 1128 | t_isnull); > [04:04:26.288] | ~~~~~~~~~ > [04:04:26.288] copyfromparse.c:1160:4: error: ‘copy_errorsrel’ may be > used uninitialized in this function [-Werror=maybe-uninitialized] > [04:04:26.288] 1160 | table_close(copy_errorsrel, RowExclusiveLock); > [04:04:26.288] | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > [1] - https://cirrus-ci.com/task/4785221183209472 > I fixed this issue, and also improved the doc. Other implementations have not changed.
Вложения
В списке pgsql-hackers по дате отправления: