| From: | Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Pluggable Storage - Andres's take |
| Date: | 2018-10-23 06:49:23 |
| Message-ID: | CAJrrPGf2pAv+ZqYXVwgULAKs5U18WB5ZKw3QSL1zy=BntQZCEQ@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, Oct 22, 2018 at 6:16 PM Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>
wrote:
> On Thu, Oct 18, 2018 at 1:04 PM Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>
> wrote:
>
>> On Tue, Oct 9, 2018 at 1:46 PM Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>
>> wrote:
>>
>>>
>>> I also observed the failure of aggregates.sql, will look into it.
>>>
>>
>> The random failure of aggregates.sql is as follows
>>
>> SELECT 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
>> transaction
>> all the records in the aggtest table are deleted and aborted the
>> transaction,
>> I suspect that some visibility checks are having some race conditions
>> that leads
>> to 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, the
>> issue 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 for
> debugging, 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
| Attachment | Content-Type | Size |
|---|---|---|
| 0001-scan-start-offset-fix-during-analyze.patch | application/octet-stream | 1.3 KB |
| 0002-Materialize-all-the-slots-before-they-are-processed-.patch | application/octet-stream | 786 bytes |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | samuel.coulee | 2018-10-23 07:05:23 | None-reentrant function call in signal handler startup_die() |
| Previous Message | Dilip Kumar | 2018-10-23 06:33:15 | Re: Side effect of CVE-2017-7484 fix? |