| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
| Cc: | David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>, Nikolay Samokhvalov <samokhvalov(at)gmail(dot)com>, PostgreSQL mailing lists <pgsql-bugs(at)postgresql(dot)org> |
| Subject: | Re: Sudden FTS-related error from parallel worker in 9.6 |
| Date: | 2016-10-11 13:07:45 |
| Message-ID: | 22111.1476191265@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> writes:
> On Mon, Oct 10, 2016 at 9:10 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> So I guess the question is why in the world are we doing that inside
>> a transaction.
> I think that is required for some of the parameters like
> "session_authorization". If user has set this for leader backend and
> we want it to be reflected in worker backend, then without starting
> transaction it won't allow (refer check_session_authorization()).
Well, we're going to need to fix that. Using a transaction here is
basically a bad idea IMO, and the current complaint shows that it
creates its own set of problems. Pointing at check_session_authorization
is no argument why it should be that way.
Without having consumed any caffeine, I'd wonder whether looking at
the "source" parameter would help resolve matters.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Grigory Smolkin | 2016-10-11 14:08:05 | Re: parallel plan in insert query |
| Previous Message | Tom Lane | 2016-10-11 13:00:52 | Re: parallel plan in insert query |