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: | Raw Message | Whole Thread | 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 |