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 wri
On 2013-03-29 19:03:05 -0400, Tom Lane wrote:
> Andres Freund 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
>
On Fri, Mar 29, 2013 at 07:03:05PM -0400, Tom Lane wrote:
> Andres Freund 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 JO
Andres Freund 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 to collect regular tab
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 writes:
> > > Should I just patch pg_upgrade to remove the "indisvalid", skip
> > > "indisvalid" indexes, and backpatch it? Users should be using the
> > > version of p
Bruce Momjian 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. Previously pg_upgrade
On Thu, Mar 28, 2013 at 05:27:28PM -0400, Tom Lane wrote:
> Bruce Momjian 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 where
> >
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
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 wrote:
> > > Pg_upgrade displays file names during copy and database names during
> > > dump/restore. Andrew Dunstan identified three bugs:
> > >
> > > * lon
On Thu, Dec 6, 2012 at 12:43:53PM -0500, Robert Haas wrote:
> On Wed, Dec 5, 2012 at 10:04 PM, 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
Robert Haas escribió:
> On Wed, Dec 5, 2012 at 10:04 PM, 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
> > ofte
On Wed, Dec 5, 2012 at 10:04 PM, 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 name
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 http://momjian.us
EnterpriseDB http://enterpri
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 http://momjian.us
EnterpriseDB
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 (pgsql-hackers@postgresq
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 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
> > > >
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
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 vari
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\postgr
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
> Windo
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?
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 versi
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 generate
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
binary_upgrade.set_next_hea
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 a
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 bit
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 tha
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
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 at
\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 wel
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
m
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
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.
>
>
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
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'
> 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
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. "postgres" is not t
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. "postgres" is not the hard wired name of the bo
Robert Haas wrote:
> On Sat, May 7, 2011 at 9:50 AM, Robert Haas wrote:
> > On Sat, May 7, 2011 at 8:56 AM, Bruce Momjian 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
On Sat, May 7, 2011 at 9:50 AM, Robert Haas wrote:
> On Sat, May 7, 2011 at 8:56 AM, Bruce Momjian 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 prompt
On Sat, May 7, 2011 at 8:56 AM, Bruce Momjian 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.
It strikes m
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 http://momjian.us
EnterpriseDB
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 no
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 http://momjian.us
Enter
Tom Lane wrote:
> Bruce Momjian 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 it returns
Bruce Momjian 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 mailing list (pgs
I have applied the attached patch to fix pg_upgrade file descriptor
leaks in error paths.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
diff --git a/contrib/pg_upgrade/check.c b/co
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 http://momjian.
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 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
52 matches
Mail list logo
