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
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
>> >
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 =
> >
Benedikt Grundmann writes:
> proddb_testing=# SELECT
> conname,convalidated,conislocal,coninhcount,connoinherit
> proddb_testing-# FROM pg_constraint WHERE conrelid =
> 'js_activity_20110101'::regclass;
>conname | convalidated |
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
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
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
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
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
> >
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
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
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
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
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:
>
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
On 11/27/2015 08:05 AM, Benedikt Grundmann wrote:
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
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
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
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
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.
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
>>>
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
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
> >
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
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
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
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
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
28 matches
Mail list logo