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. > ​

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

If I ask this question without mention the PG version I upgrade from and to, and don't mention the operating system, and don't mention replication, would the standard answer be: Use pg_upgrade! I have looked through https://www.postgresql.org/docs/9.6/static/pgupgrade.html but it seems more comp

[GENERAL] pg_upgrade fails right after printing "Running in verbose mode"

Hello. Lately we upgraded pg version in our app to 9.6.1 from 9.2. However one of the customers reported, that upgrade process failed on Windows Server 2008 R2. Our installer's logs showed that pg_upgrade returned -1073741515 which translates to 0xC135, which in turn means binary is missing s

Re: [DOCS] [GENERAL] pg_upgrade --link on Windows

On Tue, Jun 13, 2017 at 04:07:48PM -0400, Bruce Momjian wrote: > On Fri, Jun 9, 2017 at 07:55:55AM -0700, Adrian Klaver wrote: > 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,

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

[GENERAL] pg_upgrade --link on Windows

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 old data dir cannot be removed. With hard-links to file, we can get r

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

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

Hi I am trying to upgrade an exisitng Postgresql cluster from 9.1 to 9.5 on FreeBSD. pg_upgrade fails with the following error: [Verbose Output: http://pastebin.com/YhR8vD03] == $ /usr/local/bin/pg_upgrade -k -d /usr/local/pgsql/data91 -D /usr/local/pgsql/data --old-bindir=/var/tmp/pgbin.SPOsRj4

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

[GENERAL] Re[2]: [GENERAL] pg_upgrade 9.0 to 9.6

John, thanks! Your approach significantly reduces the number of checks. >Вторник, 13 декабря 2016, 13:34 +03:00 от John R Pierce : > >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 i

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

[GENERAL] pg_upgrade 9.0 to 9.6

Hi all, We've tested upgrading from postgresql 9.0.x to 9.6.1 on the test environment and everything passed fluently. But there are concerns about the production environments upgrade because of notes to some interim updates that recommends reindex and/or vacuuming to exclude data corruption, ind

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

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

Hi all.   (I tried raising this on -hackers but got "this is not supported"-answer, which is quite dissatisfactory..)   I have an issue with pg_upgrade upgrading 9.5 to 9.6. (my system is Ubuntu-16.04 and packages from http://apt.postgresql.org/)   In short pg_upgra

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: [HACKERS] [GENERAL] pg_upgrade from 9.5 to 9.6 fails with "invalid argument"

Alvaro Herrera writes: > Moreover I think getErrorText() as a whole is misconceived and should be > removed altogether (why pstrdup the string?). Indeed. I think bouncing the error back to the caller is misguided to start with, seeing that the caller is just going to do pg_fatal anyway. We shou

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

Tom Lane wrote: > 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

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

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

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 the upgrade goes through. One thing I noticed

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

[GENERAL] pg_upgrade with an extension name change

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" on 9.5, which is true. Is there a standard way of handling this sit

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

[GENERAL] pg_upgrade error regarding hstore operator

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_restore: [archiver (db)] Error while PROCESSING TOC: pg_res

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

[GENERAL] pg_upgrade 9.5.1: pg_upgrade_support missing

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\PostgreSQL\9.5\bin" - > d "C:\Program Files\PostgreSQL\9.4\data"

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

"partial" data constraint - trigger or CONSTRAINT ? was: [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: > 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

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

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

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

[GENERAL] pg_upgrade on Windows

hi guys, I am having issues with pg_upgrade on Windows. I have posted a question on StackOverflow -- at http://stackoverflow.com/questions/34664236/pg-upgrade-on-windows-cannot-write-to-log-file-pg-upgrade-internal-log -- copied below for convenience: I'm trying to run pg_upgrade on Windows

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

[GENERAL] pg_upgrade problem

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 troublesome lines. -- Role memberships

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

  1   2   3   4   >