Re: [HACKERS] Parallel worker error
От | Amit Kapila |
---|---|
Тема | Re: [HACKERS] Parallel worker error |
Дата | |
Msg-id | CAA4eK1Kt+w5HiXu8+FLbJqgYGc3Fo=CwYOCFNnFOpm+qx6-fvg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Parallel worker error (Robert Haas <robertmhaas@gmail.com>) |
Список | pgsql-hackers |
On Wed, Aug 30, 2017 at 8:49 PM, Robert Haas <robertmhaas@gmail.com> wrote: > On Wed, Aug 30, 2017 at 9:58 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> The problem here is exactly that we cannot transmit the leader's >> state to the worker. You can't blame it on SET ROLE, because >> I didn't do one. > > Hmm, that's a good reason for holding it blameless. In this case, > I'll blame the fact that we allow a role to be dropped while there are > users connected using that role. > The similar could happen with schema as well. For example, even if you have set the schema name in the search_path of session-1, it will still be allowed to drop the schema from another session. Now, we will pass the dropped schema name as part of search_path to the parallel worker. It won't lead to any error because we don't check catalog while setting the value of search_path GUC. I am not sure whether we need to bother about this, but I thought it might help in choosing the approach to fix this problem. -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: