On Tue, Oct 9, 2018 at 1:46 PM Haribabu Kommi <kommi.harib...@gmail.com> wrote:
> On Wed, Oct 3, 2018 at 3:16 PM Andres Freund <and...@anarazel.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