Re: [HACKERS] Parallel Index Scans - Mailing list pgsql-hackers
| From | tushar |
|---|---|
| Subject | Re: [HACKERS] Parallel Index Scans |
| Date | |
| Msg-id | 3e507d1d-9fdf-3ec6-7ac1-1f1af34a15d0@enterprisedb.com Whole thread Raw |
| In response to | Re: [HACKERS] Parallel Index Scans (tushar <tushar.ahuja@enterprisedb.com>) |
| Responses |
Re: [HACKERS] Parallel Index Scans
|
| List | pgsql-hackers |
On 12/22/2016 01:35 PM, tushar wrote:
> On 12/22/2016 09:49 AM, Amit Kapila wrote:
>> I think you can focus on the handling of array scan keys for testing.
>> In general, one of my colleagues has shown interest in testing this
>> patch and I think he has tested as well but never posted his findings.
>> I will request him to share his findings and what kind of tests he has
>> done, if any.
> Sure, We (Prabhat and I) have done some testing for this feature
> internally but never published the test-scripts on this forum. PFA the
> sql scripts ( along with the expected .out files) we have used for
> testing for your ready reference.
>
> In addition we had generated the LCOV (code coverage) report and
> compared the files which are changed for the "Parallel index scan" patch.
> You can see the numbers for "with patch" V/s "Without patch" (.pdf
> file is attached)
>
In addition to that, we run the sqlsmith against PG v10+PIS (parallel
index scan) patches and found a crash but that is coming on plain PG
v10 (without applying any patches) as well
postgres=# select 70 as c0, pg_catalog.has_server_privilege( cast(ref_0.indexdef as
text), cast(cast(coalesce((select name from pg_catalog.pg_settings
limit 1 offset 16) , null) as text) as text)) as c1, pg_catalog.pg_export_snapshot() as
c2, ref_0.indexdef as c3, ref_0.indexname as c4 from pg_catalog.pg_indexes as ref_0
where (ref_0.tablespace = ref_0.tablespace) or (46 = 22) limit 103;
TRAP: FailedAssertion("!(keylen < 64)", File: "hashfunc.c", Line: 139)
server closed the connection unexpectedly This probably means the server terminated abnormally before or while
processingthe request.
The connection to the server was lost. Attempting reset: 2016-12-23
11:19:50.627 IST [2314] LOG: server process (PID 2322) was terminated
by signal 6: Aborted
2016-12-23 11:19:50.627 IST [2314] DETAIL: Failed process was running:
select 70 as c0, pg_catalog.has_server_privilege( cast(ref_0.indexdef as
text), cast(cast(coalesce((select name from
pg_catalog.pg_settings limit 1 offset 16) , null) as text) as text)) as c1,
pg_catalog.pg_export_snapshot()as c2, ref_0.indexdef as c3, ref_0.indexname as c4
from pg_catalog.pg_indexes as ref_0 where (ref_0.tablespace = ref_0.tablespace)
or(46 = 22) limit 103;
2016-12-23 11:19:50.627 IST [2314] LOG: terminating any other active
server processes
2016-12-23 11:19:50.627 IST [2319] WARNING: terminating connection
because of crash of another server process
2016-12-23 11:19:50.627 IST [2319] DETAIL: The postmaster has commanded
this server process to roll back the current transaction and exit,
because another server process exited abnormally and possibly corrupted
shared memory.
2016-12-23 11:19:50.627 IST [2319] HINT: In a moment you should be able
to reconnect to the database and repeat your command.
2016-12-23 11:19:50.629 IST [2323] FATAL: the database system is in
recovery mode
Failed.
!> 2016-12-23 11:19:50.629 IST [2314] LOG: all server processes
terminated; reinitializing
2016-12-23 11:19:50.658 IST [2324] LOG: database system was
interrupted; last known up at 2016-12-23 11:19:47 IST
2016-12-23 11:19:50.810 IST [2324] LOG: database system was not
properly shut down; automatic recovery in progress
2016-12-23 11:19:50.812 IST [2324] LOG: invalid record length at
0/155E408: wanted 24, got 0
2016-12-23 11:19:50.812 IST [2324] LOG: redo is not required
2016-12-23 11:19:50.819 IST [2324] LOG: MultiXact member wraparound
protections are now enabled
2016-12-23 11:19:50.822 IST [2314] LOG: database system is ready to
accept connections
2016-12-23 11:19:50.822 IST [2328] LOG: autovacuum launcher started
--
regards,tushar
pgsql-hackers by date: