:39 PM, David G Johnston <
david.g.johns...@gmail.com> wrote:
> Robert Nix wrote
> > I'm experiencing a problem with queries apparently not using the check
> > constraints of my partition tables (tried constraint_exclusion =partition
> > and =on with same result
, Sep 18, 2014 at 9:22 PM, Jov wrote:
>
> Jov
> blog: http:amutu.com/blog <http://amutu.com/blog>
>
> 2014-09-19 2:44 GMT+08:00 Robert Nix :
>
>> I'm experiencing a problem with queries apparently not using the check
>> constraints of my partition tables (
I'm experiencing a problem with queries apparently not using the check
constraints of my partition tables (tried constraint_exclusion =partition
and =on with same results) and explain isn't sufficient to diagnose the
issue because the value for the check constraint in the query comes from a
join co
>
> If you do the dump using 9.1's pg_dump without --binary-upgrade, and then
> load that dump file into a new empty 9.1 server, then does it crash if you
> take a dump against *that* server?
>
I'll give it a try.
If so, would you be allowed to post that dump file?
>
I will not be able to provid
> What happens if you manually run the pg_dump command quoted above against
> a running 9.1 server, outside of the context of pg_upgrade? (Your port
> will be probably be different from 50432)
>
> If that still crashes, What if you drop the --binary-upgrade option? The
> --format=custom option?
>
Running a pg_upgrade task is causing Segmentation fault:
command: "/usr/lib/postgresql/9.3/bin/pg_dump" --host "/var/lib/postgresql"
--port 50432 --username "postgres" --schema-only --quote-all-identifiers
--binary-upgrade --format=custom --file="pg_upgrade_dump_6064585.custom"
"u" >> "pg_upgrade
I narrowed the issue down to trying to select from a view being created in
the same extension, like so:
create or replace view av as select 1 as a;
create table ax as select * from av;
Even just selecting from the view after creating it causes the error so
it's the access to the view that's the i
