Re: [GENERAL] pg_upgrade?: Upgrade method from/to any version on random OS?

On Wed, Sep 27, 2017 at 12:48 PM, Hans Schou wrote: > I have looked through > https://www.postgresql.org/docs/9.6/static/pgupgrade.html > but it seems more complicated than necessary. > ​[perform dump/restore]​ It went very good but took 100 minutes - where we had downtime - not so > good. > ​

Re: [GENERAL] pg_upgrade --link on Windows

On Wed, Jun 14, 2017 at 09:59:04AM +0200, Klaus P. Pieper wrote: > > -Ursprüngliche Nachricht- > > > > I apologize for not being smarter on this thread. When I helped with the > > Windows port, I was told Windows didn't have hard links for use by > tablespace > > directories, so I got it

Re: [GENERAL] pg_upgrade --link on Windows

> -Ursprüngliche Nachricht- > > I apologize for not being smarter on this thread. When I helped with the > Windows port, I was told Windows didn't have hard links for use by tablespace > directories, so I got it into my head that Windows didn't have hard links. > Therefore, when I was wri

Re: [GENERAL] pg_upgrade --link on Windows

On Fri, Jun 9, 2017 at 07:55:55AM -0700, Adrian Klaver wrote: > On 06/09/2017 07:39 AM, Arnaud L. wrote: > >See this page for more details : > >http://cects.com/overview-to-understanding-hard-links-junction-points-and-symbolic-links-in-windows/ > > > > > >Under "Hard Link (Linking for individual f

Re: [GENERAL] pg_upgrade --link on Windows

On Fri, 9 Jun 2017 07:24:03 -0700, Adrian Klaver wrote: >https://msdn.microsoft.com/en-us/library/windows/desktop/aa365006(v=vs.85).aspx > >Seems to me the difference is hard links point to file, junctions to >directories. You can make either hard links or symlinks to files. Junctions are dis

Re: [GENERAL] pg_upgrade --link on Windows

On Fri, 9 Jun 2017 10:07:24 -0400, Bruce Momjian wrote: >On Fri, Jun 9, 2017 at 12:00:56PM +0200, Arnaud L. wrote: >> Hi >> >> The pg_upgrade documentation for PostgreSQL 9.6 states that --link will use >> junction points on Windows. >> Shouldn't it rather user hard-links ? >> If I'm not mistak

Re: [GENERAL] pg_upgrade --link on Windows

Le 9/06/2017 à 17:02, Arnaud L. a écrit : Le 9/06/2017 à 16:55, Adrian Klaver a écrit : On 06/09/2017 07:39 AM, Arnaud L. wrote: So maybe pg_upgrade uses hard-links (i.e. to files), and only the documentation is wrong by calling them junctions (i.e. soft links to files) ? Looks that way. In

Re: [GENERAL] pg_upgrade --link on Windows

Le 9/06/2017 à 16:55, Adrian Klaver a écrit : On 06/09/2017 07:39 AM, Arnaud L. wrote: So maybe pg_upgrade uses hard-links (i.e. to files), and only the documentation is wrong by calling them junctions (i.e. soft links to files) ? Looks that way. In file.c in ~/src/bin/pg_upgrade I see: #ifd

Re: [GENERAL] pg_upgrade --link on Windows

On 06/09/2017 07:39 AM, Arnaud L. wrote: Le 9/06/2017 à 16:07, Bruce Momjian a écrit : I was told junction points on Windows were hard links and no one has ever complained about not being able to remove them. Sorry, I think my explanation was not very clear. You can remove the link, but the po

Re: [GENERAL] pg_upgrade --link on Windows

Le 9/06/2017 à 16:07, Bruce Momjian a écrit : I was told junction points on Windows were hard links and no one has ever complained about not being able to remove them. Sorry, I think my explanation was not very clear. You can remove the link, but the point is to remove the target (i.e. the old

Re: [GENERAL] pg_upgrade --link on Windows

On 06/09/2017 07:07 AM, Bruce Momjian wrote: On Fri, Jun 9, 2017 at 12:00:56PM +0200, Arnaud L. wrote: Hi The pg_upgrade documentation for PostgreSQL 9.6 states that --link will use junction points on Windows. Shouldn't it rather user hard-links ? If I'm not mistaken, with junction points (i.e

Re: [GENERAL] pg_upgrade --link on Windows

On Fri, Jun 9, 2017 at 12:00:56PM +0200, Arnaud L. wrote: > Hi > > The pg_upgrade documentation for PostgreSQL 9.6 states that --link will use > junction points on Windows. > Shouldn't it rather user hard-links ? > If I'm not mistaken, with junction points (i.e. soft-links to directories), > the

Re: [GENERAL] pg_upgrade error on FreeBSD (9.1 -> 9.5)

On Sat, Jan 21, 2017 at 9:53 PM, Tom Lane wrote: > Amitabh Kant writes: > > command: "/var/tmp/pgbin.SPOsRj4D/bin/pg_ctl" -w -l > "pg_upgrade_server.log" > > -D "/usr/local/pgsql/data91" -o "-p 50432 -b -c listen_addresses='' -c > > unix_socket_permissions=0700 -c unix_socket_directory='/usr/ >

Re: [GENERAL] pg_upgrade error on FreeBSD (9.1 -> 9.5)

Amitabh Kant writes: > command: "/var/tmp/pgbin.SPOsRj4D/bin/pg_ctl" -w -l "pg_upgrade_server.log" > -D "/usr/local/pgsql/data91" -o "-p 50432 -b -c listen_addresses='' -c > unix_socket_permissions=0700 -c unix_socket_directory='/usr/local/pgsql'" Note the unix_socket_directory parameter, which

Re: [GENERAL] pg_upgrade 9.0 to 9.6

Mikhail schrieb am 13.12.2016 um 10:57: > Should i check all the production environments for the problems, > mentioned in all interim versions release notes, is it enough only to > check the last minor upgrade release note (9.6 --> 9.6.1) or there is > another quick way to check if i should apply s

Re: [GENERAL] pg_upgrade 9.0 to 9.6

On 12/13/2016 1:57 AM, Mikhail wrote: Should i check all the production environments for the problems, mentioned in all interim versions release notes, is it enough only to check the last minor upgrade release note (9.6 --> 9.6.1) or there is another quick way to check if i should apply some ad

Re: [GENERAL] pg_upgrade not able to cope with pg_largeobject being in a different tablespace

On Thu, Oct 13, 2016 at 04:35:35PM +0200, Andreas Joseph Krogh wrote: > På torsdag 13. oktober 2016 kl. 16:09:34, skrev Bruce Momjian > >: > > On Thu, Oct 13, 2016 at 10:14:08AM +0200, Andreas Joseph Krogh wrote: > > I would assume that having pg_largeobject in a separate tablespace is >

Re: [GENERAL] pg_upgrade not able to cope with pg_largeobject being in a different tablespace

På tirsdag 18. oktober 2016 kl. 12:39:03, skrev Magnus Hagander < mag...@hagander.net >:     On Thu, Oct 13, 2016 at 7:35 AM, Andreas Joseph Krogh mailto:andr...@visena.com>> wrote: På torsdag 13. oktober 2016 kl. 16:09:34, skrev Bruce Momjian mailto:br...@momjian.us>>:

Re: [GENERAL] pg_upgrade not able to cope with pg_largeobject being in a different tablespace

On Thu, Oct 13, 2016 at 7:35 AM, Andreas Joseph Krogh wrote: > På torsdag 13. oktober 2016 kl. 16:09:34, skrev Bruce Momjian < > br...@momjian.us>: > > On Thu, Oct 13, 2016 at 10:14:08AM +0200, Andreas Joseph Krogh wrote: > > I would assume that having pg_largeobject in a separate tablespace is >

Re: [GENERAL] pg_upgrade not able to cope with pg_largeobject being in a different tablespace

På torsdag 13. oktober 2016 kl. 16:09:34, skrev Bruce Momjian mailto:br...@momjian.us>>: On Thu, Oct 13, 2016 at 10:14:08AM +0200, Andreas Joseph Krogh wrote: > I would assume that having pg_largeobject in a separate tablespace is more and > more common these days, having real-cheap SAN vs. fast

Re: [GENERAL] pg_upgrade not able to cope with pg_largeobject being in a different tablespace

On Thu, Oct 13, 2016 at 10:14:08AM +0200, Andreas Joseph Krogh wrote: > I would assume that having pg_largeobject in a separate tablespace is more and > more common these days, having real-cheap SAN vs. fast-SSD for normal tables/ > indexes/wal. So common that no one has ever asked for this featur

Re: [GENERAL] pg_upgrade from 9.5 to 9.6 fails with "invalid argument"

On Fri, Sep 30, 2016 at 6:40 PM, Thomas Kellerer wrote: > Tom Lane schrieb am 29.09.2016 um 23:10: >> Thomas Kellerer writes: >>> for some reason pg_upgrade failed on Windows 10 for me, with an error >>> message that one specifc _vm file couldn't be copied. >> >> Hmm ... a _vm file would go thro

Re: [GENERAL] pg_upgrade from 9.5 to 9.6 fails with "invalid argument"

Tom Lane schrieb am 29.09.2016 um 23:10: > Thomas Kellerer writes: >> for some reason pg_upgrade failed on Windows 10 for me, with an error >> message that one specifc _vm file couldn't be copied. > > Hmm ... a _vm file would go through rewriteVisibilityMap(), which is new > code for 9.6 and has

Re: [GENERAL] pg_upgrade from 9.5 to 9.6 fails with "invalid argument"

Thomas Kellerer writes: > for some reason pg_upgrade failed on Windows 10 for me, with an error message > that one specifc _vm file couldn't be copied. Hmm ... a _vm file would go through rewriteVisibilityMap(), which is new code for 9.6 and hasn't really gotten that much testing. Its error rep

Re: [GENERAL] pg_upgrade from 9.5 to 9.6 fails with "invalid argument"

Adrian Klaver schrieb am 29.09.2016 um 22:55: After running a "vacuum full" on the table in question the upgrade goes through. Assuming you did that on old cluster? Yes, correct. I did that on the 9.5 cluster Where both clusters installed the same way? Yes. I always download the ZIP Arch

Re: [GENERAL] pg_upgrade from 9.5 to 9.6 fails with "invalid argument"

On 09/29/2016 12:50 PM, Thomas Kellerer wrote: Hello, for some reason pg_upgrade failed on Windows 10 for me, with an error message that one specifc _vm file couldn't be copied. When I try to copy that file manually everything works fine. After running a "vacuum full" on the table in question

Re: [GENERAL] pg_upgrade error regarding hstore operator

parihaaraka writes: > I have the same issue after pg_upgrade from 9.3 to 9.5. > pg_dump generates excess commands like > CREATE OPERATOR FAMILY bit_ops USING gin; > ... > while all of this is done during CREATE EXTENSION This is fixed in the latest round of minor releases, but not in a way th

Re: [GENERAL] pg_upgrade error regarding hstore operator

Hello, All I have the same issue after pg_upgrade from 9.3 to 9.5. pg_dump generates excess commands like CREATE OPERATOR FAMILY bit_ops USING gin; ... while all of this is done during CREATE EXTENSION (i have only btree_gin and plpgsql installed) -- View this message in context: http://pos

Re: [GENERAL] pg_upgrade with an extension name change

On Fri, Apr 8, 2016 at 12:15:27PM -0700, Christophe Pettus wrote: > I'm attempting to upgrade a database from 9.2 to 9.5 using pg_upgrade. > The 9.2 database has the "orafunc" extension installed, which appears > to have changed names to "orafce". pg_upgrade complains that it can't > find "orafunc"

Re: [GENERAL] pg_upgrade error regarding hstore operator

om text[] to hstore function akeys(hstore) function avals(hstore) function defined(hstore,text) function delete(hstore,hstore) function delete(hstore,text) function delete(hstore,text[]) function each(hstore) function exist(hstore,text) function exists_all(hstore,text[]) function exists

Re: [GENERAL] pg_upgrade error regarding hstore operator

"Feld, Michael (IMS)" writes: > Thanks for the reply Tom. template1 is definitely empty and does not contain > any hstore objects. I did a little debugging and placed the below SQL before > and after the hstore creation in the file produced by the pg_dump and > determined that these operator ob

Re: [GENERAL] pg_upgrade error regarding hstore operator

al Message- From: Tom Lane [mailto:t...@sss.pgh.pa.us] Sent: Wednesday, April 06, 2016 7:01 PM To: Feld, Michael (IMS) Cc: pgsql-general@postgresql.org Subject: Re: [GENERAL] pg_upgrade error regarding hstore operator "Feld, Michael (IMS)" writes: > Thanks for the assist Tom. That wo

Re: [GENERAL] pg_upgrade error regarding hstore operator

"Feld, Michael (IMS)" writes: > Thanks for the assist Tom. That worked for us. Noticing a different > issue following the pg_upgrade. If we take a pg_dump of a database on > this upgraded instance with the hstore extension and try to pg_restore > it back up to the same instance we get the followin

Re: [GENERAL] pg_upgrade error regarding hstore operator

it did not. Thanks for any help you can offer. -Original Message- From: Tom Lane [mailto:t...@sss.pgh.pa.us] Sent: Tuesday, March 08, 2016 6:22 PM To: Feld, Michael (IMS) Cc: pgsql-general@postgresql.org Subject: Re: [GENERAL] pg_upgrade error regarding hstore operator "Feld, Michael

Re: [GENERAL] pg_upgrade error regarding hstore operator

"Feld, Michael (IMS)" writes: > I am attempting to upgrade my organization's database cluster from > 9.1.19 to 9.5.1 using the pg_upgrade utility. That's kind of a big jump :-( ... you missed the versions where => was deprecated as an operator name. > I tried dropping the operator before doing t

Re: [GENERAL] pg_upgrade error regarding hstore operator

On 03/08/2016 10:27 AM, Feld, Michael (IMS) wrote: I am attempting to upgrade my organization's database cluster from 9.1.19 to 9.5.1 using the pg_upgrade utility. After some processing, the tool bails out with the following error in the log: pg_restore: creating OPERATOR "public.=>" pg_restor

Re: [GENERAL] pg_upgrade 9.5.1: pg_upgrade_support missing

Hello, I tried to delete all binary_upgrade schematas using this: $ psql -tc "SELECT datname FROM pg_database" -U postgres -p 5433 | xargs -I {} psql -d {} -U postgres -p 5433 -tc "drop schema if exists binary_upgrade cascade;" But got this: output is not a tty So I got the dblist from pgadmin

Re: [GENERAL] pg_upgrade 9.5.1: pg_upgrade_support missing

schoetbi schoetbi writes: > i tried to migrate a database cluster from pg 9.4.1 to 9.5.1 with > pg_upgrade. I got the follwing error: >> Could not load library "$libdir/pg_upgrade_support" Hmm, pg_upgrade_support isn't a separate library anymore; it's been merged into core. I would not have exp

Re: [GENERAL] pg_upgrade 9.5.1: pg_upgrade_support missing

On 03/02/2016 01:42 AM, schoetbi schoetbi wrote: Hello, i tried to migrate a database cluster from pg 9.4.1 to 9.5.1 with pg_upgrade. I got the follwing error: c:\Temp>"C:\Program Files\PostgreSQL\9.5\bin\pg_upgrade" -b "C:\Program Files\PostgreSQL\9.4\bin" -B "C:\Program Files\Post

Re: [GENERAL] pg_upgrade 9.4 -> 9.5 with pg_trgm fails for me

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

Re: [GENERAL] pg_upgrade 9.4 -> 9.5 with pg_trgm fails for me

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 >

Re: [GENERAL] pg_upgrade 9.4 -> 9.5 with pg_trgm fails for me

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

SOLVED: Re: [GENERAL] pg_upgrade 9.4 -> 9.5 with pg_trgm fails for me

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

Re: [GENERAL] pg_upgrade 9.4 -> 9.5 with pg_trgm fails for me

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

Re: [GENERAL] pg_upgrade 9.4 -> 9.5 with pg_trgm fails for me

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

Re: [GENERAL] pg_upgrade 9.4 -> 9.5 with pg_trgm fails for me

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

Re: [GENERAL] pg_upgrade 9.4 -> 9.5 with pg_trgm fails for me

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

Re: [GENERAL] pg_upgrade 9.4 -> 9.5 with pg_trgm fails for me

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

Re: [GENERAL] pg_upgrade 9.4 -> 9.5 with pg_trgm fails for me

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

Re: [GENERAL] pg_upgrade 9.4 -> 9.5 with pg_trgm fails for me

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

Re: [GENERAL] pg_upgrade 9.4 -> 9.5 with pg_trgm fails for me

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

Re: [GENERAL] pg_upgrade 9.4 -> 9.5 with pg_trgm fails for me

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

Re: [GENERAL] pg_upgrade 9.4 -> 9.5 with pg_trgm fails for me

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,

Re: [GENERAL] pg_upgrade 9.4 -> 9.5 with pg_trgm fails for me

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

Re: [GENERAL] pg_upgrade 9.4 -> 9.5 with pg_trgm fails for me

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

Re: [GENERAL] pg_upgrade 9.4 -> 9.5 with pg_trgm fails for me

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

Re: [GENERAL] pg_upgrade 9.4 -> 9.5 with pg_trgm fails for me

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

Re: [GENERAL] pg_upgrade 9.4 -> 9.5 with pg_trgm fails for me

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"

Re: [GENERAL] pg_upgrade 9.4 -> 9.5 with pg_trgm fails for me

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

Re: [GENERAL] pg_upgrade 9.4 -> 9.5 with pg_trgm fails for me

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

Re: [GENERAL] pg_upgrade 9.4 -> 9.5 with pg_trgm fails for me

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

Re: [GENERAL] pg_upgrade 9.4 -> 9.5 with pg_trgm fails for me

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 >

Re: [GENERAL] pg_upgrade 9.4 -> 9.5 with pg_trgm fails for me

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.

Re: [GENERAL] pg_upgrade 9.4 -> 9.5 with pg_trgm fails for me

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

Re: [GENERAL] pg_upgrade 9.4 -> 9.5 with pg_trgm fails for me

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

Re: [GENERAL] pg_upgrade 9.4 -> 9.5 with pg_trgm fails for me

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

Re: [GENERAL] pg_upgrade 9.4 -> 9.5 with pg_trgm fails for me

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: -

Re: [GENERAL] pg_upgrade 9.4 -> 9.5 with pg_trgm fails for me

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

Re: [GENERAL] pg_upgrade 9.4 -> 9.5 with pg_trgm fails for me

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

Re: [GENERAL] pg_upgrade on Windows

On 1/7/2016 12:32 PM, Igal @ Lucee.org wrote: I'm trying to run pg_upgrade on Windows, but I'm getting the error: cannot write to log file pg_upgrade_internal.log Failure, exiting I saw a similar question for Linux at23216734

Re: [GENERAL] pg_upgrade problem

Yup, that looks like the problem. Doing: postgres=# SELECT * FROM pg_auth_members postgres-# WHERE roleid NOT IN (SELECT oid FROM pg_authid); Yields, 11 Rows, so for sure someone must have been messing around. Thanks. On Tue, Jun 16, 2015 at 11:58 AM, Jerry Sievers wrote: > Melvin Davidson wr

Re: [GENERAL] pg_upgrade problem

Melvin Davidson writes: > Using pg_upgrade in 9.4 CentOS release 6.6 (Final) (from PostgreSQL 9.1.15) > it fails when GRANTING permits to roles. > > Checking pg_upgrade_dump_globals.sql, I see the point of failure is caused by > the -- Role memberships section. > > In there I see the following

Re: [GENERAL] pg_upgrade failing from 9.3 to 9.4 because "template0" already exists

On Fri, May 15, 2015 at 10:51:15AM -0400, Bruce Momjian wrote: > On Fri, May 15, 2015 at 10:49:43AM -0400, Stephen Frost wrote: > > Bruce, > > > > * Bruce Momjian (br...@momjian.us) wrote: > > > On Mon, Mar 9, 2015 at 12:43:05PM -0400, Bruce Momjian wrote: > > > > On Fri, Mar 6, 2015 at 06:10:15

Re: [GENERAL] pg_upgrade failing from 9.3 to 9.4 because "template0" already exists

On Fri, May 15, 2015 at 10:49:43AM -0400, Stephen Frost wrote: > Bruce, > > * Bruce Momjian (br...@momjian.us) wrote: > > On Mon, Mar 9, 2015 at 12:43:05PM -0400, Bruce Momjian wrote: > > > On Fri, Mar 6, 2015 at 06:10:15PM -0500, Stephen Frost wrote: > > > > The first is required or anyone who

Re: [GENERAL] pg_upgrade failing from 9.3 to 9.4 because "template0" already exists

Bruce, * Bruce Momjian (br...@momjian.us) wrote: > On Mon, Mar 9, 2015 at 12:43:05PM -0400, Bruce Momjian wrote: > > On Fri, Mar 6, 2015 at 06:10:15PM -0500, Stephen Frost wrote: > > > The first is required or anyone who has done that will get the funny > > > error that started this thread and t

Re: [GENERAL] pg_upgrade failing from 9.3 to 9.4 because "template0" already exists

On Mon, Mar 9, 2015 at 12:43:05PM -0400, Bruce Momjian wrote: > On Fri, Mar 6, 2015 at 06:10:15PM -0500, Stephen Frost wrote: > > Technically, there haven't been any complaints about either pg_dumpall's > > behavior in this regard, or pg_upgrade's, but pg_upgrade's post-upgrade > > scripts would

Re: [GENERAL] pg_upgrade failing from 9.3 to 9.4 because "template0" already exists

On Mon, Mar 9, 2015 at 12:43:05PM -0400, Bruce Momjian wrote: > On Fri, Mar 6, 2015 at 06:10:15PM -0500, Stephen Frost wrote: > > Technically, there haven't been any complaints about either pg_dumpall's > > behavior in this regard, or pg_upgrade's, but pg_upgrade's post-upgrade > > scripts would

Re: [GENERAL] pg_upgrade failing from 9.3 to 9.4 because "template0" already exists

On Fri, Mar 6, 2015 at 06:10:15PM -0500, Stephen Frost wrote: > Technically, there haven't been any complaints about either pg_dumpall's > behavior in this regard, or pg_upgrade's, but pg_upgrade's post-upgrade > scripts would happily remove any databases which were marked as > 'datallowconn = fal

Re: [GENERAL] pg_upgrade failing from 9.3 to 9.4 because "template0" already exists

Stephen Frost writes: > * Tom Lane (t...@sss.pgh.pa.us) wrote: > >> Stephen Frost writes: >> > * Tom Lane (t...@sss.pgh.pa.us) wrote: >> >> Perhaps pg_upgrade should deliberately ignore template0 regardless of >> >> datallowconn? And/or we should hard-wire that into pg_dumpall? >> >> > My thin

Re: [GENERAL] pg_upgrade failing from 9.3 to 9.4 because "template0" already exists

* Tom Lane (t...@sss.pgh.pa.us) wrote: > Stephen Frost writes: > > * Tom Lane (t...@sss.pgh.pa.us) wrote: > >> Perhaps pg_upgrade should deliberately ignore template0 regardless of > >> datallowconn? And/or we should hard-wire that into pg_dumpall? > > > My thinking would be that pg_dumpall shou

Re: [GENERAL] pg_upgrade failing from 9.3 to 9.4 because "template0" already exists

Stephen Frost writes: > * Tom Lane (t...@sss.pgh.pa.us) wrote: >> Perhaps pg_upgrade should deliberately ignore template0 regardless of >> datallowconn? And/or we should hard-wire that into pg_dumpall? > My thinking would be that pg_dumpall should be hard-wired for template0 > (just like it is f

Re: [GENERAL] pg_upgrade failing from 9.3 to 9.4 because "template0" already exists

* Tom Lane (t...@sss.pgh.pa.us) wrote: > Stephen Frost writes: > > * Matt Landry (lelnet.m...@gmail.com) wrote: > >> postgres=# select datname, datallowconn from pg_database ; > >> datname | datallowconn > >> ---+-- > >> template1 | t > >> template0 | t > >> postgres | t > >>

Re: [GENERAL] pg_upgrade failing from 9.3 to 9.4 because "template0" already exists

Stephen Frost writes: > * Matt Landry (lelnet.m...@gmail.com) wrote: >> postgres=# select datname, datallowconn from pg_database ; >> datname | datallowconn >> ---+-- >> template1 | t >> template0 | t >> postgres | t >> reporting | t >> (4 rows) > Right, as I mentioned, temp

Re: [GENERAL] pg_upgrade failing from 9.3 to 9.4 because "template0" already exists

On 03/06/2015 02:43 PM, Stephen Frost wrote: Right, as I mentioned, template0 shouldn't have datallowconn as 'true'. That's why it's being included in the pg_dumpall. On your test setup, run (as superuser): update pg_database set datallowconn = false where datname = 'template0'; Then re-run th

Re: [GENERAL] pg_upgrade failing from 9.3 to 9.4 because "template0" already exists

Matt, * Matt Landry (lelnet.m...@gmail.com) wrote: > postgres=# select datname, datallowconn from pg_database ; > datname | datallowconn > ---+-- > template1 | t > template0 | t > postgres | t > reporting | t > (4 rows) Right, as I mentioned, template0 shouldn't have d

Re: [GENERAL] pg_upgrade failing from 9.3 to 9.4 because "template0" already exists

On 03/06/2015 01:55 PM, Adrian Klaver wrote: So on the original cluster, log in using psql and do \l and post the results here. Thanks. [...] Meant to add to previous post, to check with issue that Stephen mentioned do: select datname, datallowconn from pg_database ; postgres=# \l

Re: [GENERAL] pg_upgrade failing from 9.3 to 9.4 because "template0" already exists

On 03/06/2015 11:22 AM, Matt Landry wrote: On 03/06/2015 12:37 PM, Adrian Klaver wrote: Agreed, I am just trying to figure out how you get: CREATE DATABASE "template0" WITH TEMPLATE = template0 .. Seems to be a snake eating its tail:) Yes. It does. And it's pretty obvious why having this wou

Re: [GENERAL] pg_upgrade failing from 9.3 to 9.4 because "template0" already exists

On 03/06/2015 11:22 AM, Matt Landry wrote: On 03/06/2015 12:37 PM, Adrian Klaver wrote: Agreed, I am just trying to figure out how you get: CREATE DATABASE "template0" WITH TEMPLATE = template0 .. Seems to be a snake eating its tail:) Yes. It does. And it's pretty obvious why having this wou

Re: [GENERAL] pg_upgrade failing from 9.3 to 9.4 because "template0" already exists

On 03/06/2015 12:37 PM, Adrian Klaver wrote: Agreed, I am just trying to figure out how you get: CREATE DATABASE "template0" WITH TEMPLATE = template0 .. Seems to be a snake eating its tail:) Yes. It does. And it's pretty obvious why having this would be a problem...not quite so obvious how

Re: [GENERAL] pg_upgrade failing from 9.3 to 9.4 because "template0" already exists

On 03/06/2015 10:35 AM, Stephen Frost wrote: Adrian, * Adrian Klaver (adrian.kla...@aklaver.com) wrote: On 03/06/2015 10:11 AM, Matt Landry wrote: Attempting to upgrade a large (>3TB) postgressql database from 9.3 to 9.4 on Ubuntu 14.04 LTS, but the process fails fairly early on. The error mes

Re: [GENERAL] pg_upgrade failing from 9.3 to 9.4 because "template0" already exists

Adrian, * Adrian Klaver (adrian.kla...@aklaver.com) wrote: > On 03/06/2015 10:11 AM, Matt Landry wrote: > >Attempting to upgrade a large (>3TB) postgressql database from 9.3 to > >9.4 on Ubuntu 14.04 LTS, but the process fails fairly early on. The > >error message instructs me to look at the last

Re: [GENERAL] pg_upgrade failing from 9.3 to 9.4 because "template0" already exists

Matt, In your existing environment, do you have template0 set to allow connections (datallowconn)? That's not a good idea in general, but I suspect that's why pg_dumpall is including it based on a quick look at the code. Thanks! * Matt Landry (lelnet.m...@gmail.com) wrote: > Attempting to upgra

Re: [GENERAL] pg_upgrade failing from 9.3 to 9.4 because "template0" already exists

On 03/06/2015 10:11 AM, Matt Landry wrote: Attempting to upgrade a large (>3TB) postgressql database from 9.3 to 9.4 on Ubuntu 14.04 LTS, but the process fails fairly early on. The error message instructs me to look at the last few lines of pg_upgrade_utility.log for more info, and the last two l

Re: [GENERAL] pg_upgrade could not connect to server

On Thu, Jan 22, 2015 at 07:13:40PM -0800, Igal @ getRailo.org wrote: > ok, I resolved this by giving Full Permissions to the data directory.  > > I don't understand why this problem occurred in the first place.  probably > something in the process that creates the Data directory. > > thank you al

Re: [GENERAL] pg_upgrade could not connect to server

On Thu, Jan 22, 2015 at 05:46:08PM -0800, Igal @ getRailo.org wrote: > so when I try to run pg_ctl start I get this now: > > c:\Program Files\PostgreSQL\9.3\bin>pg_ctl --pgdata=E:\PGSQLData start > server starting > > c:\Program Files\PostgreSQL\9.3\bin>2015-01-22 17:25:22 PST PANIC:  could not >

Re: [GENERAL] pg_upgrade could not connect to server

ok, I resolved this by giving Full Permissions to the data directory. I don't understand why this problem occurred in the first place. probably something in the process that creates the Data directory. thank you all for your help. Igal On 1/22/2015 5:46 PM, Igal @ getRailo.org wrote: > so w

Re: [GENERAL] pg_upgrade could not connect to server

so when I try to run pg_ctl start I get this now: c:\Program Files\PostgreSQL\9.3\bin>pg_ctl --pgdata=E:\PGSQLData start server starting c:\Program Files\PostgreSQL\9.3\bin>2015-01-22 17:25:22 PST *PANIC: could not open control file "global/pg_control": Permission denied* so looks like that is

Re: [GENERAL] pg_upgrade could not connect to server

same result :( C:\Windows\system32>"C:\Program Files\PostgreSQL\9.3\bin/pg_ctl" -w -l "c:\pg_upgrade_ctl.log" -D "E:\PGSQLData" -o "-p 50432 -b " start waiting for server to startAccess is denied. stopped waiting pg_ctl: could not start server Examine the log output. can't find any log o

Re: [GENERAL] pg_upgrade could not connect to server

runas administrator https://msdn.microsoft.com/en-us/library/bb385791.aspx "The new security model does not grant administrative privileges at all times. Even administrators run under standard privileges when they perform non-administrative tasks that do not require elevated privileges…"

Re: [GENERAL] pg_upgrade could not connect to server

maybe we can isolate the issue by breaking it into steps. this seems to cause the problem: C:\Program Files\PostgreSQL\9.4\bin>"C:\Program Files\PostgreSQL\9.3\bin/pg_ctl" -w -l "pg_upgrade_ctl.log" -D "E:\PGSQLData" -o "-p 50432 -b " start waiting for server to startAccess is denied. st

  1   2   3   4   >