Re: Parallel scan with SubTransGetTopmostTransaction assert coredump
От | Robert Haas |
---|---|
Тема | Re: Parallel scan with SubTransGetTopmostTransaction assert coredump |
Дата | |
Msg-id | CA+TgmoYxFna9y-gDQjcmnN6=CXwC1CkGToZjbXZgWQFKHKGaHA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Parallel scan with SubTransGetTopmostTransaction assert coredump (Greg Nancarrow <gregn4422@gmail.com>) |
Ответы |
Re: Parallel scan with SubTransGetTopmostTransaction assert coredump
|
Список | pgsql-hackers |
On Wed, Aug 11, 2021 at 8:32 AM Greg Nancarrow <gregn4422@gmail.com> wrote: > This is explained by the TransactionSnapshot being a later snapshot in > this case. > So this is why it seems to be wrong to call GetTransactionSnapshot() > in InitializeParallelDSM() and use a separate, potentially later, > snapshot than that used in the execution state for the query. Thanks for the research. I agree with your logic here, but: 1. Then why doesn't the approach I proposed fix it? 2. Consider the case where the toplevel query is something like SELECT complexfunc() FROM generate_series(1,10) g -- in a case like this, I think complexfunc() can cause snapshots to be taken internally. For example suppose we end up inside exec_eval_simple_expr, or SPI_cursor_open_internal, in either case with read_only = false. Here we're going to again call GetTransactionSnapshot() and then execute a query which may use parallelism. -- Robert Haas EDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: