On 2013-03-29 19:03:05 -0400, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
Those columns cannot be NULL, so using IS DISTINCT FROM seems a bit
clumsy.
That was what I started to write, too, but actually I think the IS
DISTINCT is correct and the RIGHT JOIN should be a LEFT
OK, patch applied and backpatched as far back as pg_upgrade exists in
git.
---
On Fri, Mar 29, 2013 at 11:35:13PM -0400, Bruce Momjian wrote:
On Fri, Mar 29, 2013 at 07:03:05PM -0400, Tom Lane wrote:
Andres Freund
On Thu, Mar 28, 2013 at 05:27:28PM -0400, Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
Should I just patch pg_upgrade to remove the indisvalid, skip
indisvalid indexes, and backpatch it? Users should be using the
version of pg_upgrade to match new pg_dump. Is there any case
Bruce Momjian br...@momjian.us writes:
Attached is a patch that implements the suggested pg_upgrade changes of
not copying invalid indexes now that pg_dump doesn't dump them. This
should be backpatched back to 8.4 to match pg_dump. It might require
release note updates; not sure.
On 2013-03-29 16:57:06 -0400, Bruce Momjian wrote:
On Thu, Mar 28, 2013 at 05:27:28PM -0400, Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
Should I just patch pg_upgrade to remove the indisvalid, skip
indisvalid indexes, and backpatch it? Users should be using the
version of
Andres Freund and...@2ndquadrant.com writes:
Those columns cannot be NULL, so using IS DISTINCT FROM seems a bit
clumsy.
That was what I started to write, too, but actually I think the IS
DISTINCT is correct and the RIGHT JOIN should be a LEFT JOIN. Note
that the query appears to be intended
On Fri, Mar 29, 2013 at 07:03:05PM -0400, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
Those columns cannot be NULL, so using IS DISTINCT FROM seems a bit
clumsy.
That was what I started to write, too, but actually I think the IS
DISTINCT is correct and the RIGHT JOIN
On Wed, Dec 5, 2012 at 10:04:53PM -0500, Bruce Momjian wrote:
Pg_upgrade displays file names during copy and database names during
dump/restore. Andrew Dunstan identified three bugs:
* long file names were being truncated to 60 _leading_ characters, which
often do not change for long file
On Wed, Dec 5, 2012 at 10:04 PM, Bruce Momjian br...@momjian.us wrote:
Pg_upgrade displays file names during copy and database names during
dump/restore. Andrew Dunstan identified three bugs:
* long file names were being truncated to 60 _leading_ characters, which
often do not change for
Robert Haas escribió:
On Wed, Dec 5, 2012 at 10:04 PM, Bruce Momjian br...@momjian.us wrote:
Pg_upgrade displays file names during copy and database names during
dump/restore. Andrew Dunstan identified three bugs:
* long file names were being truncated to 60 _leading_ characters, which
On Thu, Dec 6, 2012 at 12:43:53PM -0500, Robert Haas wrote:
On Wed, Dec 5, 2012 at 10:04 PM, Bruce Momjian br...@momjian.us wrote:
Pg_upgrade displays file names during copy and database names during
dump/restore. Andrew Dunstan identified three bugs:
* long file names were being
On Thu, Dec 6, 2012 at 02:53:44PM -0300, Alvaro Herrera wrote:
Robert Haas escribió:
On Wed, Dec 5, 2012 at 10:04 PM, Bruce Momjian br...@momjian.us wrote:
Pg_upgrade displays file names during copy and database names during
dump/restore. Andrew Dunstan identified three bugs:
*
Pg_upgrade displays file names during copy and database names during
dump/restore. Andrew Dunstan identified three bugs:
* long file names were being truncated to 60 _leading_ characters, which
often do not change for long file names
* file names were truncated to 60 characters in log files
An EntpriseDB testing report indicated that pg_upgrade crashes if it
can't write into the current directory. This only happens in 9.2 and
head, so I have applied the attached patch to fix it.
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB
I have applied the attached patch to git head to fix the new SQL tablespace
location function usage in pg_upgrade to properly check cluster version
numbers, and a fix missing table alias.
I found this problem during testing.
--
Bruce Momjian br...@momjian.ushttp://momjian.us
OK, works now with the recent update.
Thanks
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/fix-for-pg-upgrade-tp3411128p5059777.html
Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.
--
Sent via pgsql-hackers mailing list
Great, thanks!
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/fix-for-pg-upgrade-tp3411128p4856336.html
Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
Alvaro Herrera wrote:
Excerpts from Bruce Momjian's message of miC3A9 sep 28 13:48:28 -0300
2011:
Bruce Momjian wrote:
OK, so it fails for all tables and you are using the newest version.
Thanks for all your work. I am now guessing that pg_upgrade 9.1.X is
just broken on
Here are all generated log files.
I just removed all other DBs except gnucash (which includes the accounts
table), but the issue also emerges with other DBs.
Upgraded the 9.1 instance to the new build (9.1.1.) as well but this
apparently did not change anything.
PG versions are (including
panam wrote:
Here are all generated log files.
I just removed all other DBs except gnucash (which includes the accounts
table), but the issue also emerges with other DBs.
Upgraded the 9.1 instance to the new build (9.1.1.) as well but this
apparently did not change anything.
PG versions
Bruce Momjian wrote:
OK, so it fails for all tables and you are using the newest version.
Thanks for all your work. I am now guessing that pg_upgrade 9.1.X is
just broken on Windows.
Perhaps the variables set by pg_upgrade_support.so are not being passed
into the server variables? I
Hi Bruce,
here is the file you asked for:
http://postgresql.1045698.n5.nabble.com/file/n4850735/pg_upgrade_logfile.txt
pg_upgrade_logfile.txt
I guess you are not addressing me here, right?
The server will need to
be started with -b and this will disable autovacuum. Can someone on
Windows
panam wrote:
Hi Bruce,
here is the file you asked for:
http://postgresql.1045698.n5.nabble.com/file/n4850735/pg_upgrade_logfile.txt
pg_upgrade_logfile.txt
OK, I see it using -b to pg_ctl:
C:\Program Files\PostgreSQL\9.1\bin/pg_ctl -w -l nul -D
D:\applications\postgres\9.1 -o
Excerpts from Bruce Momjian's message of mié sep 28 13:48:28 -0300 2011:
Bruce Momjian wrote:
OK, so it fails for all tables and you are using the newest version.
Thanks for all your work. I am now guessing that pg_upgrade 9.1.X is
just broken on Windows.
Perhaps the variables set
Alvaro Herrera wrote:
Excerpts from Bruce Momjian's message of mi?? sep 28 13:48:28 -0300 2011:
Bruce Momjian wrote:
OK, so it fails for all tables and you are using the newest version.
Thanks for all your work. I am now guessing that pg_upgrade 9.1.X is
just broken on Windows.
Hi Bruce,
here is the whole dump (old DB):
http://postgresql.1045698.n5.nabble.com/file/n4844725/dump.txt dump.txt
Regards,
panam
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/fix-for-pg-upgrade-tp3411128p4844725.html
Sent from the PostgreSQL - hackers mailing list
panam wrote:
Hi Bruce,
here is the whole dump (old DB):
http://postgresql.1045698.n5.nabble.com/file/n4844725/dump.txt dump.txt
Wow, that is interesting. I see this in the dump output:
-- For binary upgrade, must preserve relfilenodes
SELECT
panam wrote:
Hi Bruce,
on the old DB I've got 465783 as oid whereas on the new one it is 16505.
is not in the dump file (old db), even 16385 (i guess this is a typo here)
or 16505 are not.
The only line in which 465783 could be found is
I need to see the lines after this.
Is that
Hi Bruce,
on the old DB I've got 465783 as oid whereas on the new one it is 16505.
is not in the dump file (old db), even 16385 (i guess this is a typo here)
or 16505 are not.
The only line in which 465783 could be found is
Is that enough information or should I send the whole dump? That's a
OK, i started once again:
I hope the following is the correct way of querying the table corresponding
to a relid:
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/fix-for-pg-upgrade-tp3411128p4838427.html
Sent from the PostgreSQL - hackers mailing list archive
panam wrote:
OK, i started once again:
I hope the following is the correct way of querying the table corresponding
to a relid:
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/fix-for-pg-upgrade-tp3411128p4838427.html
Yes, that is very close to
\panam wrote:
Hi, just tried to upgrade from 9.0 to 9.1 and got this error during
pg_upgrade :
Mismatch of relation id: database xyz, old relid 465783, new relid 16494
It seems, I get this error on every table as I got it on another table
(which I did not need and deleted) before as well.
Hi, just tried to upgrade from 9.0 to 9.1 and got this error during
pg_upgrade :
Mismatch of relation id: database xyz, old relid 465783, new relid 16494
It seems, I get this error on every table as I got it on another table
(which I did not need and deleted) before as well. Schmemas seem to be
The attached, applied patch checks that the pg_upgrade user specified is
a super-user. It also reports the error message when the post-pg_ctl
connection fails.
This was prompted by a private bug report from EnterpriseDB.
--
Bruce Momjian br...@momjian.ushttp://momjian.us
On Sat, May 7, 2011 at 8:56 AM, Bruce Momjian br...@momjian.us wrote:
The attached, applied patch checks that the pg_upgrade user specified is
a super-user. It also reports the error message when the post-pg_ctl
connection fails.
This was prompted by a private bug report from EnterpriseDB.
On Sat, May 7, 2011 at 9:50 AM, Robert Haas robertmh...@gmail.com wrote:
On Sat, May 7, 2011 at 8:56 AM, Bruce Momjian br...@momjian.us wrote:
The attached, applied patch checks that the pg_upgrade user specified is
a super-user. It also reports the error message when the post-pg_ctl
Robert Haas wrote:
On Sat, May 7, 2011 at 9:50 AM, Robert Haas robertmh...@gmail.com wrote:
On Sat, May 7, 2011 at 8:56 AM, Bruce Momjian br...@momjian.us wrote:
The attached, applied patch checks that the pg_upgrade user specified is
a super-user. ?It also reports the error message when
Bruce Momjian br...@momjian.us writes:
One question I have is why we even bother to allow the database username
to be specified? Shouldn't we just hard-code that to 'postgres'?
Only if you want to render pg_upgrade unusable by a significant fraction
of people. postgres is not the hard wired
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
One question I have is why we even bother to allow the database username
to be specified? Shouldn't we just hard-code that to 'postgres'?
Only if you want to render pg_upgrade unusable by a significant fraction
of people. postgres
Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian writes:
One question I have is why we even bother to allow the database
username to be specified? Shouldn't we just hard-code that to
'postgres'?
Only if you want to render pg_upgrade unusable by a significant
fraction of people.
On lör, 2011-05-07 at 13:50 -0400, Bruce Momjian wrote:
I was really wondering if I should be using that hard-coded name,
rather than allowing the user to supply it. They have to compile in a
different name, and I assume that name is accessible somewhere.
postgres is not compiled in. It's
Kevin Grittner wrote:
Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian writes:
One question I have is why we even bother to allow the database
username to be specified? Shouldn't we just hard-code that to
'postgres'?
Only if you want to render pg_upgrade unusable by a
Peter Eisentraut wrote:
On l?r, 2011-05-07 at 13:50 -0400, Bruce Momjian wrote:
I was really wondering if I should be using that hard-coded name,
rather than allowing the user to supply it. They have to compile in a
different name, and I assume that name is accessible somewhere.
On 05/07/2011 06:48 PM, Bruce Momjian wrote:
postgres is not compiled in. It's whatever user you run initdb under.
In particular, in the regression tests, it is probably not postgres.
Thanks. I get confused because the 'postgres' database is hardcoded in,
but not the username. Not sure why
The attached, applied patch adds a check to throw a pg_upgrade error
during the check phase, rather than during the post-check upgrade phase.
Specifically, if someone removes the 'postgres' database from the old
cluster and the new cluster has a 'postgres' database, the number of
databases will
The attached patches fixes a pg_upgrade crash in 9.0 caused by a new
cluster database that doesn't exist in the old cluster; instead throw
an error. This was reported to me by EnterpriseDB testing staff. This
bug does not exist in git head.
--
Bruce Momjian br...@momjian.us
I have applied the attached patch to fix pg_upgrade file descriptor
leaks in error paths.
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
diff --git
Bruce Momjian br...@momjian.us writes:
I have applied the attached patch to fix pg_upgrade file descriptor
leaks in error paths.
It seems rather pointless to spend code closing descriptors immediately
before a fatal exit.
regards, tom lane
--
Sent via pgsql-hackers
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
I have applied the attached patch to fix pg_upgrade file descriptor
leaks in error paths.
It seems rather pointless to spend code closing descriptors immediately
before a fatal exit.
Well, it is not before a fatal but rather before
I got a report from someone using pg_upgrade coming from PG 8.3 ---
turns out we didn't rename toast tables to match the new relfilenode in
pre-8.4, so the attached applied patch avoids the check for these cases.
This check is new in pg_upgrade for 9.1.
--
Bruce Momjian br...@momjian.us
Patch applied.
I did not backpatch to 9.0 because you can't migrate from 9.0 to 9.0
with the same catversion (because of tablespace conflict), and a pre-9.0
migration to 9.0 has not large object permissions to migrate. In
summary, it didn't seem worth the risk, and was hard to test.
Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
Tom Lane wrote:
That isn't going to work. At least not unless you start trying to force
roles to have the same OIDs in the new installation.
If so I can use the CREATE ROLE ... SYSID clause when doing a
52 matches
Mail list logo
