Re: parallel mode and parallel contexts

Поиск
Список
Период
Сортировка
От Simon Riggs
Тема Re: parallel mode and parallel contexts
Дата
Msg-id CA+U5nM+Rwp2NbSBFJP_-vogwYH8k9V8OwZLFFr7odwYvTkzhxg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: parallel mode and parallel contexts  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: parallel mode and parallel contexts  (Simon Riggs <simon@2ndQuadrant.com>)
Re: parallel mode and parallel contexts  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On 6 January 2015 at 21:01, Robert Haas <robertmhaas@gmail.com> wrote:
> On Tue, Jan 6, 2015 at 3:04 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
>> If you can explain it in more detail in comments and README, I may
>> agree. At present, I don't get it and it makes me nervous.
>>
>> The comment says
>> "Only the top frame of the transaction state stack is copied to a parallel
>> worker"
>> but I'm not sure why.
>>
>> Top meaning the current subxact or the main xact?
>> If main, why are do we need XactTopTransactionId
>
> Current subxact.

TopTransactionStateData points to the top-level transaction data, but
XactTopTransactionId points to the current subxact.

So when you say "Only the top frame of the transaction state stack is
copied" you don't mean the top, you mean the bottom (the latest
subxact)? Which then becomes the top in the parallel worker? OK...

> I initially thought of copying the entire TransactionStateData stack,
> but Heikki suggested (via IM) that I do it this way instead.  I
> believe his concern was that it's never valid to commit or roll back
> to a subtransaction that is not at the top of the stack, and if you
> don't copy the stack, you avoid the risk of somehow ending up in that
> state.  Also, you avoid having to invent resource owners for
> (sub)transactions that don't really exist in the current process.  On
> the other hand, you do end up with a few special cases that wouldn't
> exist with the other approach.  Still, I'm pretty happy to have taken
> Heikki's advice: it was certainly simple to implement this way, plus
> hopefully that way at least one person likes what I ended up with.
> :-)
>
> What else needs clarification?

Those comments really belong in a README, not the first visible
comment in xact.c

You need to start with the explanation that parallel workers have a
faked-up xact stack to make it easier to copy and manage. That is
valid because we never change xact state during a worker operation.

I get it now and agree, but please work some more on clarity of
README, comments and variable naming!

-- Simon Riggs                   http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: pg_basebackup fails with long tablespace paths
Следующее
От: Josh Berkus
Дата:
Сообщение: Re: Turning recovery.conf into GUCs