[Postgres-xc-general] Postgres 9.2 code merge is done and committed - Issues remaining

[Michael P. <mic...@gm...>]

Hi all,

Well, I am sure you have noticed that I committed the 9.2 merge code :)
The commit message was really huge, so it has been bypassed from the commit
ML.
I have been able to drastically reduce the number of failures and bugs that
have been introduced by the 9.2 merge.
And the number of regression failures I am seeing is down to 6 for 146
tests. The code is now fairly stable even if regressions need to be
polished a bit.
I have not been able to make long test runs yet but stabilization can be
done a bit later.
Features like streaming replication work correctly. I haven't done tests
with cascading yet. However I expect it to work also smoothly.
Some regression tests might need to be reinforced with additional ORDER BY.
But this tunning can come later.

An important thing => Now option -C is used by the binary postgres,
conflicting with out -C to startup coordinator.
In consequence, I changed -C to --coordinator and -X to --datanode. All the
docs are updated. There are no consequences in pg_ctl and related.
A query has been disabled in join.sql (execute foo(true)) because it was
taking too long. Ashutosh is working on improving the join there.

Then, I have spotted 3 remaining issues, 2 minor and 1 major.
So here is the list of all the remaining issues I found and needing a
little bit of effort to be fixed, at least for the 2 first ones:
1) The aggregate test is using some new bytea tests with functions like
decode, that may result in such diffs.
  select string_agg(v, '') from
bytea_test_table;


string_agg


------------

!
\xaaff

  (1 row)
====
  select string_agg(v, '') from
bytea_test_table;


string_agg


------------

!
\xffaa

  (1 row)
It might be possible to order the output but I am still not sure how.
This has been registered as bug 3553035.
2) Failure of test select_views, problem with leaky scenarios
In some tests of select_views permissions to the relation are not set
correctly.
SELECT * FROM my_property_normal WHERE
f_leak(passwd);

ERROR:  permission denied for relation customer
This may be related to some security issues...
This has been registered as bug 3553036
3) Problems with parameters in plpgsql, plancache and rangefuncts
There are multiple errors related to parameters. PREPARE/EXECUTE is working
correctly so this looks to be related to the past parameter problems we saw
before the merge.
- Here is an error in plancache.
  select cache_test(2);
ERROR:  cache lookup failed for type 0
CONTEXT:  SQL statement "insert into t1 values($1)"
PL/pgSQL function cache_test(integer) line 5 at SQL statement
- One in plpgsql:
  select * from PField_v1 where pfname = 'PF0_1' order by slotname;
ERROR:  cache lookup failed for type 0
CONTEXT:  SQL statement "select          * from PSlot where slotname = $1"
PL/pgSQL function pslot_backlink_view(character) line 8 at SQL statement
- One in rangefuncs:
  SELECT * FROM getfoo(1) AS t1;
ERROR:  cache lookup failed for type 0
CONTEXT:  SQL statement "SELECT fooid             FROM foo WHERE fooid =
$1"
PL/pgSQL function getfoo(integer) line 1 at SQL statement
This is registered as issue

By Friday, I am pretty sure that I will be able to fix issue 1. And I will
have a look at issue 2.
I'll also continue polishing the regression tests depending on the diffs I
find in my environments.
The 3rd issue is a little bit more complicated, but as far as i understood
Ashutosh might have a solution for it.

Regards,
-- 
Michael Paquier
http://michael.otacoo.com