Re: Sudden FTS-related error from parallel worker in 9.6

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

In response to

Browse pgsql-bugs by date

  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