On 02/11/2014 08:19 PM, Yeb Havinga wrote:
> I compared output of psql -ef of the minirim.sql script posted earlier
> in http://www.postgresql.org/message-id/52f54927.1040...@gmail.com
> between v4 and v7.
>
> Not everything is ok.
> +psql:/home/m/minirim2.sql:409: ERROR: attribute 6 has wrong type
> +DETAIL: Table has type tsrange, but query expects _confidentialitycode.
This looks like an issue with attribute transformations made when
applying security barrier quals.
> +psql:/home/m/minirim2.sql:439: connection to server was lost
That's dying with:
> Program received signal SIGABRT, Aborted.
> 0x0000003f02c359e9 in __GI_raise (sig=sig@entry=6) at
> ../nptl/sysdeps/unix/sysv/linux/raise.c:56
> 56 return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig);
> (gdb) bt
> #0 0x0000003f02c359e9 in __GI_raise (sig=sig@entry=6) at
> ../nptl/sysdeps/unix/sysv/linux/raise.c:56
> #1 0x0000003f02c370f8 in __GI_abort () at abort.c:90
> #2 0x0000000000758d9d in ExceptionalCondition
> (conditionName=conditionName@entry=0x8b7bf0 "!(!bms_is_empty(upper_varnos))",
> errorType=errorType@entry=0x78e89c "FailedAssertion",
> fileName=fileName@entry=0x8b78d7 "subselect.c",
> lineNumber=lineNumber@entry=1394) at assert.c:54
> #3 0x000000000061de2b in convert_EXISTS_sublink_to_join (root=<optimized
> out>, sublink=<optimized out>, under_not=under_not@entry=0 '\000',
> available_rels=0x117d038)
> at subselect.c:1394
> #4 0x000000000061efa9 in pull_up_sublinks_qual_recurse
> (root=root@entry=0x117d058, node=0x117a0f8,
> jtlink1=jtlink1@entry=0x7fff6d97f708,
> available_rels1=available_rels1@entry=0x117d038,
> jtlink2=jtlink2@entry=0x0, available_rels2=available_rels2@entry=0x0) at
> prepjointree.c:391
> #5 0x000000000061f339 in pull_up_sublinks_jointree_recurse
> (root=root@entry=0x117d058, jtnode=0x117a040,
> relids=relids@entry=0x7fff6d97f758) at prepjointree.c:208
> #6 0x000000000062066f in pull_up_sublinks (root=root@entry=0x117d058) at
> prepjointree.c:147
> #7 0x000000000061967e in subquery_planner (glob=0x10c3fb8,
> parse=parse@entry=0x1179af8, parent_root=parent_root@entry=0x1182fd0,
> hasRecursion=hasRecursion@entry=0 '\000',
`
> #8 0x00000000005fc093 in set_subquery_pathlist (root=root@entry=0x1182fd0,
> rel=rel@entry=0x1179370, rti=rti@entry=4, rte=rte@entry=0x1183980) at
> allpaths.c:1209
> #9 0x00000000005fc54e in set_rel_size (root=root@entry=0x1182fd0,
> rel=0x1179370, rti=rti@entry=4, rte=0x1183980) at allpaths.c:265
> #10 0x00000000005fc62e in set_base_rel_sizes (root=root@entry=0x1182fd0) at
> allpaths.c:180
> #11 0x00000000005fd584 in make_one_rel (root=root@entry=0x1182fd0,
> joinlist=joinlist@entry=0x1179560) at allpaths.c:138
> #12 0x000000000061617a in query_planner (root=root@entry=0x1182fd0,
> tlist=tlist@entry=0x11771c8, qp_callback=qp_callback@entry=0x616fd6
> <standard_qp_callback>,
> qp_extra=qp_extra@entry=0x7fff6d97fa00) at planmain.c:236
> #13 0x00000000006182f2 in grouping_planner (root=root@entry=0x1182fd0,
> tuple_fraction=tuple_fraction@entry=0) at planner.c:1280
> #14 0x0000000000619a11 in subquery_planner (glob=glob@entry=0x10c3fb8,
> parse=parse@entry=0x10c3d30, parent_root=parent_root@entry=0x0,
> hasRecursion=hasRecursion@entry=0 '\000', tuple_fraction=0,
> subroot=subroot@entry=0x7fff6d97fb58) at planner.c:574
> #15 0x0000000000619c1f in standard_planner (parse=0x10c3d30, cursorOptions=0,
> boundParams=0x0) at planner.c:211
> #16 0x0000000000619e35 in planner (parse=parse@entry=0x10c3d30,
> cursorOptions=cursorOptions@entry=0, boundParams=boundParams@entry=0x0) at
> planner.c:139
> #17 0x000000000068c64b in pg_plan_query (querytree=0x10c3d30,
> cursorOptions=cursorOptions@entry=0, boundParams=boundParams@entry=0x0) at
> postgres.c:759
> #18 0x000000000068c6d3 in pg_plan_queries (querytrees=<optimized out>,
> cursorOptions=cursorOptions@entry=0, boundParams=boundParams@entry=0x0) at
> postgres.c:818
> #19 0x000000000068c932 in exec_simple_query
> (query_string=query_string@entry=0x10c2d78 "SELECT * FROM hl7.test;") at
> postgres.c:983
> #20 0x000000000068e46e in PostgresMain (argc=<optimized out>,
> argv=argv@entry=0x10cd1f0, dbname=0x10cd058 "regress", username=<optimized
> out>) at postgres.c:4003
> #21 0x00000000006419a7 in BackendRun (port=port@entry=0x10c7e50) at
> postmaster.c:4080
> #22 0x00000000006432c2 in BackendStartup (port=port@entry=0x10c7e50) at
> postmaster.c:3769
> #23 0x0000000000643526 in ServerLoop () at postmaster.c:1580
> #24 0x000000000064467c in PostmasterMain (argc=argc@entry=4,
> argv=argv@entry=0x10a8750) at postmaster.c:1235
> #25 0x00000000005d692c in main (argc=4, argv=0x10a8750) at main.c:205
> (gdb)
It's crashing while pulling up the query over "emp" (hl7.employee) and
"part" (hl7.participation).
Given the simplicity of what the row-security code its self is doing,
I'm wondering if this is a case that isn't handled in updatable s.b.
views. I'll look into it.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
