Karsten Hilbert writes:
> Just a crazy thought:
> If I create a foreign key from *.*.modified_by towards
> dem.staff.db_user but then DISABLE that FK -- would that still
> cue in pg_dump to order the tables appropriately ?
Hmm, probably. Sounds like a kluge but ...
regar
Adrian Klaver writes:
> On 01/08/2016 01:26 PM, Tom Lane wrote:
>> No, it's just a bug. Although apparently not many people do that, or
>> we'd have heard complaints before.
> That dredged up a memory from way back:
> http://www.postgresql.org/message-id/200411251906.43881.akla...@comcast.net
>
On Fri, Jan 08, 2016 at 12:53:24PM -0500, Tom Lane wrote:
> Hm. So, by having installed this function as a check constraint, you have
> created a data dependency that pg_dump has no way to know about. It's
> going to load the tables in some order that's chosen without regard to the
> need for de
On Fri, Jan 08, 2016 at 04:26:25PM -0500, Tom Lane wrote:
> Karsten Hilbert writes:
> > On Fri, Jan 08, 2016 at 04:03:51PM -0500, Tom Lane wrote:
> >> BTW, the one-liner fix that I'd had in mind when I wrote that does indeed
> >> fix this particular problem, but after studying the code I realized
On Fri, Jan 08, 2016 at 12:53:24PM -0500, Tom Lane wrote:
> In general, embedding lookups of other tables into CHECK constraints
> is going to cause you all kinds of grief quite aside from pg_dump
> not understanding it, because the backend doesn't really understand it
> either. If the other tabl
On 01/08/2016 01:26 PM, Tom Lane wrote:
> Karsten Hilbert writes:
>> On Fri, Jan 08, 2016 at 04:03:51PM -0500, Tom Lane wrote:
>>> BTW, the one-liner fix that I'd had in mind when I wrote that does indeed
>>> fix this particular problem, but after studying the code I realized that
>>> there's a wh
Karsten Hilbert writes:
> On Fri, Jan 08, 2016 at 04:03:51PM -0500, Tom Lane wrote:
>> BTW, the one-liner fix that I'd had in mind when I wrote that does indeed
>> fix this particular problem, but after studying the code I realized that
>> there's a whole bunch of related problems; for instance I
On Fri, Jan 08, 2016 at 04:03:51PM -0500, Tom Lane wrote:
> BTW, the one-liner fix that I'd had in mind when I wrote that does indeed
> fix this particular problem, but after studying the code I realized that
> there's a whole bunch of related problems; for instance I believe
> pg_upgrade would lo
Karsten Hilbert writes:
> On Fri, Jan 08, 2016 at 12:38:47PM -0500, Tom Lane wrote:
>> After digging through this, I figured out the problem: you'd installed
>> pg_trgm into the pg_catalog schema, whereas when I was testing I'd just
>> dropped it into the public schema. That confuses pg_dump into
On Fri, Jan 08, 2016 at 12:38:47PM -0500, Tom Lane wrote:
> After digging through this, I figured out the problem: you'd installed
> pg_trgm into the pg_catalog schema, whereas when I was testing I'd just
> dropped it into the public schema. That confuses pg_dump into not
> emitting the shell typ
On Fri, Jan 08, 2016 at 12:38:47PM -0500, Tom Lane wrote:
>>> dumps of your 9.4 installation's databases. If you'd be willing to send
>>> those to me off-list, maybe I could figure out what's happening.
>
>> The list stalled the attachment so here as PM.
>
> Well, you shouldn't have tried to se
On Fri, Jan 08, 2016 at 12:53:24PM -0500, Tom Lane wrote:
> >> and here is the function that leads to the schema having a
> >> dependancy on table data:
>
> Hm. So, by having installed this function as a check constraint, you have
> created a data dependency that pg_dump has no way to know about
On Fri, Jan 08, 2016 at 10:45:27AM -0500, Tom Lane 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 da
Karsten Hilbert writes:
>> and here is the function that leads to the schema having a
>> dependancy on table data:
Hm. So, by having installed this function as a check constraint, you have
created a data dependency that pg_dump has no way to know about. It's
going to load the tables in some ord
Karsten Hilbert writes:
> On Fri, Jan 08, 2016 at 11:23:21AM -0500, Tom Lane wrote:
>> A suggestion is to run the pg_upgrade with -r switch, which will leave a
>> litter of files in your working directory. Some of them will be named
>> like pg_upgrade_dump_NNN.custom and should be custom-format,
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/res
I wrote:
> A suggestion is to run the pg_upgrade with -r switch, which will leave a
> litter of files in your working directory. Some of them will be named
> like pg_upgrade_dump_NNN.custom and should be custom-format, schema-only
> dumps of your 9.4 installation's databases. If you'd be willing
Karsten Hilbert writes:
> On Fri, Jan 08, 2016 at 11:12:09AM -0500, Tom Lane wrote:
>> Hm. I just tried running a pg_upgrade here on a 9.4 database containing
>> pg_trgm 1.1, and didn't see any particular problem, so there's some
>> additional factor needed to cause your result. Hard to tell wha
On Fri, Jan 08, 2016 at 11:12:09AM -0500, Tom Lane wrote:
> > Sure:
> > (pg_trgm,1.1,"text similarity measurement and index searching based on
> > trigrams")
>
> Hm. I just tried running a pg_upgrade here on a 9.4 database containing
> pg_trgm 1.1, and didn't see any particular problem, so
Karsten Hilbert writes:
> On Fri, Jan 08, 2016 at 10:45:27AM -0500, Tom Lane wrote:
>> Just for completeness, can you tell us which pg_trgm version (1.0
>> or 1.1) is installed in the 9.4 database?
> Sure:
> (pg_trgm,1.1,"text similarity measurement and index searching based on
> trigrams"
On Fri, Jan 08, 2016 at 10:45:27AM -0500, Tom Lane wrote:
> Karsten Hilbert writes:
> > [ pg_upgrade failed on pg_trgm ]
>
> Just for completeness, can you tell us which pg_trgm version (1.0
> or 1.1) is installed in the 9.4 database?
Sure:
(pg_trgm,1.1,"text similarity measurement and
On Fri, Jan 08, 2016 at 10:45:27AM -0500, Tom Lane wrote:
> Karsten Hilbert writes:
> > (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 ord
On 01/08/2016 07:41 AM, Karsten Hilbert wrote:
On Fri, Jan 08, 2016 at 07:18:24AM -0800, Adrian Klaver wrote:
http://www.postgresql.org/docs/9.5/interactive/pgupgrade.html
"If an error occurs while restoring the database schema, pg_upgrade will
exit and you will have to revert to the old clust
Karsten Hilbert writes:
> [ pg_upgrade failed on pg_trgm ]
Just for completeness, can you tell us which pg_trgm version (1.0
or 1.1) is installed in the 9.4 database?
> (For what it's worth, I have also tried the --method=dump way
> of using Debian's pg_upgradecluster which internally uses a
>
On Fri, Jan 08, 2016 at 07:41:09AM -0800, Adrian Klaver wrote:
> >>I thought --method=dump was the default, so this:
> >>
> >>pg_upgradecluster -v 9.5 9.4 main
> >>
> >>was using that?
> >
> >True enough. I did specify the "-m upgrade" though, as
> >witnessed by the log snippet.
>
> Alright then.
On Fri, Jan 08, 2016 at 07:41:09AM -0800, Adrian Klaver wrote:
> >On Fri, Jan 08, 2016 at 07:18:24AM -0800, Adrian Klaver wrote:
> >
> >>I thought --method=dump was the default, so this:
> >>
> >>pg_upgradecluster -v 9.5 9.4 main
> >>
> >>was using that?
> >
> >True enough. I did specify the "-m u
On 01/08/2016 07:28 AM, Karsten Hilbert wrote:
Ccing list
On Fri, Jan 08, 2016 at 07:18:24AM -0800, Adrian Klaver wrote:
I thought --method=dump was the default, so this:
pg_upgradecluster -v 9.5 9.4 main
was using that?
True enough. I did specify the "-m upgrade" though, as
witnessed by th
On Fri, Jan 08, 2016 at 07:18:24AM -0800, Adrian Klaver wrote:
> http://www.postgresql.org/docs/9.5/interactive/pgupgrade.html
>
> "If an error occurs while restoring the database schema, pg_upgrade will
> exit and you will have to revert to the old cluster as outlined in step 16
> below.
Thanks
On 01/08/2016 03:45 AM, Karsten Hilbert wrote:
Hi,
I have attempted a pg_upgrade on Debian using the Debian
wrapper scripts like so:
pg_upgradecluster -v 9.5 9.4 main
(meaning to upgrade a cluster named "main" from 9.4 to 9.5)
which resulted in this:
-
On Fri, Jan 08, 2016 at 12:45:29PM +0100, Karsten Hilbert wrote:
> pg_restore: erstelle EXTENSION „pg_trgm“
> pg_restore: erstelle COMMENT „EXTENSION "pg_trgm"“
> pg_restore: erstelle FUNCTION „pg_catalog.gtrgm_in("cstring")“
> pg_restore: [Archivierer (DB)] Fehler in Phase
On Fri, Jan 08, 2016 at 12:45:29PM +0100, Karsten Hilbert wrote:
> pg_restore: erstelle EXTENSION „pg_trgm“
> pg_restore: erstelle COMMENT „EXTENSION "pg_trgm"“
> pg_restore: erstelle FUNCTION „pg_catalog.gtrgm_in("cstring")“
> pg_restore: [Archivierer (DB)] Fehler in Phase
Hi,
I have attempted a pg_upgrade on Debian using the Debian
wrapper scripts like so:
pg_upgradecluster -v 9.5 9.4 main
(meaning to upgrade a cluster named "main" from 9.4 to 9.5)
which resulted in this:
-
32 matches
Mail list logo
