Re: Pluggable Storage - Andres's take

On Tue, Oct 9, 2018 at 1:46 PM Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>
wrote:

> On Wed, Oct 3, 2018 at 3:16 PM Andres Freund <andres(at)anarazel(dot)de> wrote:
>
>> On 2018-09-27 20:03:58 -0700, Andres Freund wrote:
>> > On 2018-09-28 12:21:08 +1000, Haribabu Kommi wrote:
>> > > Here I attached further cleanup patches.
>> > > 1. Re-arrange the GUC variable
>> > > 2. Added a check function hook for default_table_access_method GUC
>> >
>> > Cool.
>> >
>> >
>> > > 3. Added a new hook validate_index. I tried to change the function
>> > > validate_index_heapscan to slotify, but that have many problems as it
>> > > is accessing some internals of the heapscandesc structure and
>> accessing
>> > > the buffer and etc.
>> >
>> > Oops, I also did that locally, in a way. I also made a validate a
>> > callback, as the validation logic is going to be specific to the AMs.
>> > Sorry for not pushing that up earlier. I'll try to do that soon,
>> > there's a fair amount of change.
>>
>> I've pushed an updated version, with a fair amount of pending changes,
>> and I hope all your pending (and not redundant, by our concurrent
>> development), patches merged.
>>
>
> Yes, All the patches are merged.
>
> There's currently 3 regression test failures, that I'll look into
>> tomorrow:
>> - partition_prune shows a few additional Heap Blocks: exact=1 lines. I'm
>> a bit confused as to why, but haven't really investigated yet.
>> - fast_default fails, because I've undone most of 7636e5c60fea83a9f3c,
>> I'll have to redo that in a different way.
>> - I occasionally see failures in aggregates.sql - I've not figured out
>> what's going on there.
>>
>
> 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.

Regards,
Haribabu Kommi