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
