From: | Karsten Hilbert <Karsten(dot)Hilbert(at)gmx(dot)net> |
---|---|
To: | pgsql-general <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: pg_upgrade 9.4 -> 9.5 with pg_trgm fails for me |
Date: | 2016-01-08 16:52:14 |
Message-ID: | 20160108165214.GR22446@hermes.hilbert.loc |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Again, as the list software doesn't like "config" at the
start of a line.
Karsten
On Fri, Jan 08, 2016 at 05:34:00PM +0100, Karsten Hilbert wrote:
> > > (For what it's worth, I have also tried the --method=dump way
> > > of using Debian's pg_upgradecluster which internally uses a
> > > dump/restore cycle rather than calling pg_upgrade. That
> > > failed due to ordering problems with table data vs table
> > > constraints.)
> >
> > That seems like an independent bug. Can you provide specifics?
>
> Attached the log of
>
> pg_upgradecluster -v 9.5 9.4 main &> pg-upgrade-9_4-9_5-dump_restore.log
>
> and here is the function that leads to the schema having a
> dependancy on table data:
>
> create or replace function gm.account_is_dbowner_or_staff(_account name)
> returns boolean
> language plpgsql
> as '
> DECLARE
> _is_owner boolean;
> BEGIN
> -- is _account member of current db group ?
> -- PERFORM 1 FROM pg_auth_members
> -- WHERE
> -- roleid = (SELECT oid FROM pg_roles WHERE rolname = current_database())
> -- AND
> -- member = (SELECT oid FROM pg_roles WHERE rolname = _account)
> -- ;
> -- IF FOUND THEN
> -- -- should catch people on staff, gm-dbo, and postgres
> -- RETURN TRUE;
> -- END IF;
>
> -- postgres
> IF _account = ''postgres'' THEN
> RETURN TRUE;
> END IF;
>
> -- on staff list
> PERFORM 1 FROM dem.staff WHERE db_user = _account;
> IF FOUND THEN
> RETURN TRUE;
> END IF;
>
> -- owner
> SELECT pg_catalog.pg_get_userbyid(datdba) = _account INTO STRICT _is_owner FROM pg_catalog.pg_database WHERE datname = current_database();
> IF _is_owner IS TRUE THEN
> RETURN TRUE;
> END IF;
>
> -- neither
> RAISE EXCEPTION
> ''gm.account_is_dbowner_or_staff(NAME): <%> is neither database owner, nor <postgres>, nor on staff'', _account
> USING ERRCODE = ''integrity_constraint_violation''
> ;
> RETURN FALSE;
> END;';
>
> The function is used on audit tables:
>
> alter table audit.audit_fields
> drop constraint if exists
> audit_audit_fields_sane_modified_by cascade;
>
> alter table audit.audit_fields
> add constraint audit_audit_fields_sane_modified_by check
> (gm.account_is_dbowner_or_staff(modified_by) IS TRUE)
> ;
>
> Karsten
> --
> GPG key ID E4071346 @ eu.pool.sks-keyservers.net
> E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
--
GPG key ID E4071346 @ eu.pool.sks-keyservers.net
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
Attachment | Content-Type | Size |
---|---|---|
pg-upgrade-9_4-9_5-dump_restore.log | text/plain | 6.9 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2016-01-08 17:38:47 | Re: pg_upgrade 9.4 -> 9.5 with pg_trgm fails for me |
Previous Message | Karsten Hilbert | 2016-01-08 16:37:40 | Re: pg_upgrade 9.4 -> 9.5 with pg_trgm fails for me |