On 4 October 2016 at 09:28, Benedikt Grundmann
wrote:
>
>
> On 4 October 2016 at 08:17, Benedikt Grundmann
> wrote:
>
>>
>> On 3 October 2016 at 21:01, Tom Lane wrote:
>>
>>> Benedikt Grundmann writes:
>>> > proddb_testing=# SELECT
>>> > conname,convalidated,conislocal,coninhcount,connoinherit
On 4 October 2016 at 08:17, Benedikt Grundmann
wrote:
>
> On 3 October 2016 at 21:01, Tom Lane wrote:
>
>> Benedikt Grundmann writes:
>> > proddb_testing=# SELECT
>> > conname,convalidated,conislocal,coninhcount,connoinherit
>> > proddb_testing-# FROM pg_constraint WHERE conrelid =
>> > 'js_act
On 3 October 2016 at 21:01, Tom Lane wrote:
> Benedikt Grundmann writes:
> > proddb_testing=# SELECT
> > conname,convalidated,conislocal,coninhcount,connoinherit
> > proddb_testing-# FROM pg_constraint WHERE conrelid =
> > 'js_activity_20110101'::regclass;
> >conname
Benedikt Grundmann writes:
> proddb_testing=# SELECT
> conname,convalidated,conislocal,coninhcount,connoinherit
> proddb_testing-# FROM pg_constraint WHERE conrelid =
> 'js_activity_20110101'::regclass;
>conname | convalidated | conislocal |
> coninhcount | co
On 3 October 2016 at 15:54, Tom Lane wrote:
> Benedikt Grundmann writes:
> > And it looks like now I'm back to the error that stopped me last time:
> > pg_restore: [archiver (db)] Error from TOC entry 8425; 2606 416548282
> CHECK
> > CONSTRAINT seqno_not_null postgres_prod
> > pg_restore: [archi
Benedikt Grundmann writes:
> And it looks like now I'm back to the error that stopped me last time:
> pg_restore: [archiver (db)] Error from TOC entry 8425; 2606 416548282 CHECK
> CONSTRAINT seqno_not_null postgres_prod
> pg_restore: [archiver (db)] could not execute query: ERROR: constraint
> "s
On 3 October 2016 at 15:30, Tom Lane wrote:
> Benedikt Grundmann writes:
> > On 3 October 2016 at 14:12, Tom Lane wrote:
> >> You're going to need to manually drop that operator from the source
> >> database, as "=>" isn't a legal operator name anymore. This appears
> >> to be left over from a
Benedikt Grundmann writes:
> On 3 October 2016 at 14:12, Tom Lane wrote:
>> You're going to need to manually drop that operator from the source
>> database, as "=>" isn't a legal operator name anymore. This appears
>> to be left over from a pre-9.0 version of hstore.
> Thanks for the quick repl
On 3 October 2016 at 14:12, Tom Lane wrote:
> Benedikt Grundmann writes:
> > I just tried this again. This time from 9.2.17 to 9.5.4 and pg_upgrade
> > chokes with this:
> >
> > [root@igm-dbc-001 upgrade-logs]# tail pg_upgrade_dump_16416.log
> > pg_restore: [archiver (db)] could not execute que
Benedikt Grundmann writes:
> I just tried this again. This time from 9.2.17 to 9.5.4 and pg_upgrade
> chokes with this:
>
> [root@igm-dbc-001 upgrade-logs]# tail pg_upgrade_dump_16416.log
> pg_restore: [archiver (db)] could not execute query: ERROR: syntax error
> at or near "=>"
> LINE 1: CREA
On 30 November 2015 at 17:01, Bruce Momjian wrote:
> On Mon, Nov 30, 2015 at 04:51:15PM +, Benedikt Grundmann wrote:
> > Are you able to compile from 9.4 git head and test that? It seems
> > dumping inheriting constraints from parents has not worked properly
> for
> > some time.
On Mon, Nov 30, 2015 at 04:51:15PM +, Benedikt Grundmann wrote:
> Are you able to compile from 9.4 git head and test that? It seems
> dumping inheriting constraints from parents has not worked properly for
> some time.
>
>
> Do I need to get the latest/head 9.2 or the latest/head
On Mon, Nov 30, 2015 at 4:29 PM, Bruce Momjian wrote:
> On Mon, Nov 30, 2015 at 08:08:50AM +, Benedikt Grundmann wrote:
> >
> >
> > On Sat, Nov 28, 2015 at 2:39 AM, Adrian Klaver <
> adrian.kla...@aklaver.com>
> > wrote:
> >
> > On 11/27/2015 06:07 PM, Tom Lane wrote:
> > > Adrian Kla
On Mon, Nov 30, 2015 at 08:08:50AM +, Benedikt Grundmann wrote:
>
>
> On Sat, Nov 28, 2015 at 2:39 AM, Adrian Klaver
> wrote:
>
> On 11/27/2015 06:07 PM, Tom Lane wrote:
> > Adrian Klaver writes:
> >> On 11/27/2015 08:15 AM, Bruce Momjian wrote:
> >>> My guess is you are sh
On Sat, Nov 28, 2015 at 2:39 AM, Adrian Klaver
wrote:
> On 11/27/2015 06:07 PM, Tom Lane wrote:
> > Adrian Klaver writes:
> >> On 11/27/2015 08:15 AM, Bruce Momjian wrote:
> >>> My guess is you are sharing the constraint name "seqno_not_null" with
> >>> multiple tables. I think you are going to
On 11/27/2015 06:07 PM, Tom Lane wrote:
> Adrian Klaver writes:
>> On 11/27/2015 08:15 AM, Bruce Momjian wrote:
>>> My guess is you are sharing the constraint name "seqno_not_null" with
>>> multiple tables. I think you are going to have to dig into the system
>>> tables to see where that is refer
Adrian Klaver writes:
> On 11/27/2015 08:15 AM, Bruce Momjian wrote:
>> My guess is you are sharing the constraint name "seqno_not_null" with
>> multiple tables. I think you are going to have to dig into the system
>> tables to see where that is referenced and fix it.
> In the post below the OP
On 11/27/2015 08:15 AM, Bruce Momjian wrote:
> On Fri, Nov 27, 2015 at 04:05:46PM +, Benedikt Grundmann wrote:
>> > [as-proddb@nyc-dbc-001 upgrade-logs]$ tail pg_upgrade_dump_16416.log
>> > pg_restore: creating CHECK CONSTRAINT seqno_not_null
>> > pg_restore: creating CHECK CONST
On 11/27/2015 08:05 AM, Benedikt Grundmann wrote:
On Fri, Nov 27, 2015 at 4:04 PM, Bruce Momjian mailto:br...@momjian.us>> wrote:
On Fri, Nov 27, 2015 at 09:38:54AM +, Benedikt Grundmann wrote:
> That worked (I also swapped the password columns so that I don't have to
change
>
On Fri, Nov 27, 2015 at 04:05:46PM +, Benedikt Grundmann wrote:
> > [as-proddb@nyc-dbc-001 upgrade-logs]$ tail pg_upgrade_dump_16416.log
> > pg_restore: creating CHECK CONSTRAINT seqno_not_null
> > pg_restore: creating CHECK CONSTRAINT seqno_not_null
> > pg_restore: [archiver (d
On Fri, Nov 27, 2015 at 4:04 PM, Bruce Momjian wrote:
> On Fri, Nov 27, 2015 at 09:38:54AM +, Benedikt Grundmann wrote:
> > That worked (I also swapped the password columns so that I don't have to
> change
> > pgpass entries). But I then ran into a different problem a little later
> on. I
>
On Fri, Nov 27, 2015 at 09:38:54AM +, Benedikt Grundmann wrote:
> That worked (I also swapped the password columns so that I don't have to
> change
> pgpass entries). But I then ran into a different problem a little later on.
> I
> thought I quickly mention it here in case somebody can poin
On Wed, Nov 25, 2015 at 2:43 PM, Bruce Momjian wrote:
> On Wed, Nov 25, 2015 at 08:04:49AM +, Benedikt Grundmann wrote:
> > You can see the 9.5 requirements in the pg_upgrade function
> > check_is_install_user(). You might as well just honor what that
> > requires as you will eve
On Wed, Nov 25, 2015 at 08:04:49AM +, Benedikt Grundmann wrote:
> You can see the 9.5 requirements in the pg_upgrade function
> check_is_install_user(). You might as well just honor what that
> requires as you will eventually be moving to 9.5.
>
>
> Thanks I'll try this in one of
On Tue, Nov 24, 2015 at 8:04 PM, Bruce Momjian wrote:
> On Mon, Nov 23, 2015 at 11:12:25AM +, Benedikt Grundmann wrote:
> > I got this error trying to upgrade one of our database clusters (happily
> in
> > testing) from 9.2 to 9.4:
> >
> > Old and new cluster install users have different valu
On Mon, Nov 23, 2015 at 11:12:25AM +, Benedikt Grundmann wrote:
> I got this error trying to upgrade one of our database clusters (happily in
> testing) from 9.2 to 9.4:
>
> Old and new cluster install users have different values for pg_authid.oid
>
> Important background here is that we used
On 11/23/15 5:12 AM, Benedikt Grundmann wrote:
So I would love to know what the recommended way to go forward is.
Ideally it avoids using the old postgres unix
and database user (we want to completely get rid of it eventually, but
if I have to do some additional one off work this
time to get past
I got this error trying to upgrade one of our database clusters (happily in
testing) from 9.2 to 9.4:
Old and new cluster install users have different values for pg_authid.oid
Important background here is that we used to run the database as the
postgres unix user, but recently we had changed it t
28 matches
Mail list logo
