Re: Pluggable Storage - Andres's take
От | Haribabu Kommi |
---|---|
Тема | Re: Pluggable Storage - Andres's take |
Дата | |
Msg-id | CAJrrPGf2pAv+ZqYXVwgULAKs5U18WB5ZKw3QSL1zy=BntQZCEQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Pluggable Storage - Andres's take (Haribabu Kommi <kommi.haribabu@gmail.com>) |
Ответы |
Re: Pluggable Storage - Andres's take
|
Список | pgsql-hackers |
On Mon, Oct 22, 2018 at 6:16 PM Haribabu Kommi <kommi.haribabu@gmail.com> wrote:
On Thu, Oct 18, 2018 at 1:04 PM Haribabu Kommi <kommi.haribabu@gmail.com> wrote:On Tue, Oct 9, 2018 at 1:46 PM Haribabu Kommi <kommi.haribabu@gmail.com> wrote:I also observed the failure of aggregates.sql, will look into it.The random failure of aggregates.sql is as followsSELECT avg(a) AS avg_32 FROM aggtest WHERE a < 100;! avg_32! ---------------------! 32.6666666666666667(1 row)-- In 7.1, avg(float4) is computed using float8 arithmetic.--- 8,16 ----(1 row)SELECT avg(a) AS avg_32 FROM aggtest WHERE a < 100;! avg_32! --------!(1 row)Same NULL result for another aggregate query on column b.The aggtest table is accessed by two tests that are running in parallel.i.e aggregates.sql and transactions.sql, In transactions.sql, inside a transactionall the records in the aggtest table are deleted and aborted the transaction,I suspect that some visibility checks are having some race conditions that leadsto no records on the table aggtest, thus it returns NULL result.If I try the scenario manually by opening a transaction and deleting the records, theissue is not occurring.I am yet to find the cause for this problem.I am not yet able to generate a test case where the above issue can occur easily fordebugging, it is happening randomly. I will try to add some logs to find out the problem.
I am able to generate the simple test and found the problem. The issue with the following
SQL.
SELECT *
INTO TABLE xacttest
FROM aggtest;
During the processing of the above query, the tuple that is selected from the aggtest is
sent to the intorel_receive() function, and the same tuple is used for the insert, because
of this reason, the tuple xmin is updated and it leads to failure of selecting the data from
another query. I fixed this issue by materializing the slot.
During the above test run, I found another issue during analyze, that is trying to access
the invalid offset data. Attached a fix patch.
Regards,
Haribabu Kommi
Fujitsu Australia
Вложения
В списке pgsql-hackers по дате отправления: