Re: Pluggable Storage - Andres's take - Mailing list pgsql-hackers

From Haribabu Kommi
Subject Re: Pluggable Storage - Andres's take
Date
Msg-id CAJrrPGf2pAv+ZqYXVwgULAKs5U18WB5ZKw3QSL1zy=BntQZCEQ@mail.gmail.com
Whole thread Raw
In response to Re: Pluggable Storage - Andres's take  (Haribabu Kommi <kommi.haribabu@gmail.com>)
Responses Re: Pluggable Storage - Andres's take  (Haribabu Kommi <kommi.haribabu@gmail.com>)
List 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 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

pgsql-hackers by date:

Previous
From: Dilip Kumar
Date:
Subject: Re: Side effect of CVE-2017-7484 fix?
Next
From: "samuel.coulee"
Date:
Subject: None-reentrant function call in signal handler startup_die()