Re: WIP: Avoid creation of the free space map for small tables

On Mon, Feb 4, 2019 at 12:39 AM John Naylor <john(dot)naylor(at)2ndquadrant(dot)com> wrote:
>
> On Sun, Feb 3, 2019 at 2:06 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> >
> > On Thu, Jan 31, 2019 at 6:03 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> > This doesn't get applied cleanly after recent commit 0d1fe9f74e.
> > Attached is a rebased version. I have checked once that the changes
> > done by 0d1fe9f74e don't impact this patch. John, see if you can also
> > once confirm whether the recent commit (0d1fe9f74e) has any impact. I
> > am planning to push this tomorrow morning (IST) unless you or anyone
> > see any problem with this.
>
> Since that commit changes RelationAddExtraBlocks(), which can be
> induces by your pgbench adjustment upthread, I ran make check with
> that adjustment in the pgbench dir 300 times without triggering
> asserts.
>
> I also tried to follow the logic in 0d1fe9f74e, and I believe it will
> be correct without a FSM.
>

I have just pushed it and buildfarm has shown two failures:

https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=dromedary&dt=2019-02-04%2002%3A27%3A26

--- /Users/buildfarm/bf-data/HEAD/pgsql.build/contrib/pageinspect/expected/page.out
2019-02-03 21:27:29.000000000 -0500
+++ /Users/buildfarm/bf-data/HEAD/pgsql.build/contrib/pageinspect/results/page.out
2019-02-03 21:41:32.000000000 -0500
@@ -38,19 +38,19 @@
SELECT * FROM fsm_page_contents(get_raw_page('test_rel_forks', 'fsm', 0));
fsm_page_contents
-------------------
- 0: 39 +
- 1: 39 +
- 3: 39 +
- 7: 39 +
- 15: 39 +
- 31: 39 +
- 63: 39 +
..

This one seems to be FSM test portability issue (due to different page
contents, maybe). Looking into it, John, see if you are around and
have some thoughts on it.

2.
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=dory&dt=2019-02-04%2002%3A30%3A25

select explain_parallel_append('execute ab_q5 (33, 44, 55)');
- explain_parallel_append
--------------------------------------------------------------------------------
- Finalize Aggregate (actual rows=1 loops=1)
- -> Gather (actual rows=3 loops=1)
- Workers Planned: 2
- Workers Launched: 2
- -> Partial Aggregate (actual rows=1 loops=3)
- -> Parallel Append (actual rows=0 loops=N)
- Subplans Removed: 8
- -> Parallel Seq Scan on ab_a1_b1 (never executed)
- Filter: ((b < 4) AND (a = ANY (ARRAY[$1, $2, $3])))
-(9 rows)
-
+ERROR: lost connection to parallel worker
+CONTEXT: PL/pgSQL function explain_parallel_append(text) line 5 at
FOR over EXECUTE statement
-- Test Parallel Append with PARAM_EXEC Params
select explain_parallel_append('select count(*) from ab where (a =
(select 1) or a = (select 3)) and b = 2');
explain_parallel_append

Failure is something like:

2019-02-03 21:44:42.456 EST [2812:327] pg_regress/partition_prune LOG:
statement: select explain_parallel_append('execute ab_q5 (1, 1, 1)');
2019-02-03 21:44:42.493 EST [2812:328] pg_regress/partition_prune LOG:
statement: select explain_parallel_append('execute ab_q5 (2, 3, 3)');
2019-02-03 21:44:42.531 EST [2812:329] pg_regress/partition_prune LOG:
statement: select explain_parallel_append('execute ab_q5 (33, 44,
55)');
2019-02-04 02:44:42.552 GMT [4172] FATAL: could not reattach to
shared memory (key=00000000000001B4, addr=0000000001980000): error
code 487
2019-02-03 21:44:42.555 EST [5116:6] LOG: background worker "parallel
worker" (PID 4172) exited with exit code 1
2019-02-03 21:44:42.560 EST [2812:330] pg_regress/partition_prune
ERROR: lost connection to parallel worker

I don't think this is related to this commit.

--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com