Am 11.06.2010 21:19, schrieb Robert Haas:
> On Fri, Jun 11, 2010 at 2:46 PM, Dimitri Fontaine
>> But of course you don't ever do that. What you do once the restore failed on
>> you is fix the schema and the application before to upgrade.
>
> Presumably, you mean that YOU don't ever do that. What
Robert Haas writes:
> Suppose I have a server running 8.2 and I'm going to wipe it and
> install the latest version of $DISTRIBUTION which bundles 8.4.
[...]
> I'm sure someone will tell me my system administration practices suck,
> but people do these kinds of things, in real life, all the time.
Stephen Frost writes:
> If it's an option w/ a default of "off", then chances are the admin will
> get the failure you're talking about, realize there's an issue, but then
> have a way to actually *fix* the restore without having to hack up
> multi-gigabyte files using vi. If you'd like, you're w
On Fri, Jun 11, 2010 at 2:46 PM, Dimitri Fontaine
wrote:
Eeh, I've had this happen to me on earlier releases, and it didn't
feel like a feature to me. YMMV, of course.
>>>
>>> Would you have preferred later application failure?
>>
>> YES! It's a heck of a lot easier to fix the applicat
Top posting, sorry for that.
--
dim
Le 10 juin 2010 à 03:40, Robert Haas a écrit :
On Wed, Jun 9, 2010 at 9:35 PM, Bruce Momjian
wrote:
Robert Haas wrote:
I think users would rather have the restore fail, and know right
away
they have an issue, than to do the upgrade, and find out lat
Am 10.06.2010 17:23, schrieb Heikki Linnakangas:
> Much easier to do a schema-only dump, edit that, and dump data separately.
I tries this in my very case. Did not work due sequences, triggers and
primary keys. I ended up editing a 500 MB file in vi.
--
Schönen Gruß - Regards
Hartmut Goebel
Dip
Am 10.06.2010 17:01, schrieb Tom Lane:
> Um, I rather doubt that experience level has much of anything to do with
> one's probability of getting blindsided by new SQL syntax.
Please stop expecting the one doing the upgrade has a lot of knowledge
at all. He is just the one pointed out to perform t
Am 10.06.2010 15:48, schrieb Robert Haas:
> Maybe so, but I don't give either method high marks for convenience.
> Suppose I have a server running 8.2 and I'm going to wipe it and
> install the latest version of $DISTRIBUTION which bundles 8.4. What
> our current policy essentially means is that
Am 10.06.2010 03:35, schrieb Bruce Momjian:
> Robert Haas wrote:
>>> I think users would rather have the restore fail, and know right away
>>> they have an issue, than to do the upgrade, and find out later that some
>>> of their application queries fail and they need to run around fixing
>>> them.
Am 10.06.2010 13:46, schrieb Kevin Grittner:
> I have a feeling that many here don't understand how ubiquitous such
> frameworks are.
I got his impression, too. :-(
> Our programmers have no way to get a statement to
> the database from within the application *without* all identifiers
> being qu
On Thu, Jun 10, 2010 at 10:25 AM, Tom Lane wrote:
> Bruce Momjian writes:
>> From a code perspective, the difficulting in adding such a flag is that
>> much of the quoting happens inside the backend, not by pg_dump, and
>> therefore there is significant code change required to add this flag.
>
>
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Actually, I was thinking that the three-file approach is just
> unnecessary complication. What about two files, schema and data,
> with the schema file including a \i for the data at the right place?
> This could be enabled by a single additional switch
> "
Stephen Frost writes:
> Perhaps we should have a 'multi-file' option with a 'base-file-name'
> parameter which then generates:
> pre-data DDL
> data
> post-data DDL
> psql script to run them in order (\i-style)
Actually, I was thinking that the three-file approach is just
unnecessary complicatio
* Stefan Kaltenbrunner (ste...@kaltenbrunner.cc) wrote:
> well that is an argument for providing not only --schema-only and
> --data-only but rather three options one for the table definitions, one
> for the data and one for all the constraints and indexes. So basically
> what pg_dump is curr
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Heikki Linnakangas writes:
> > Much easier to do a schema-only dump, edit that, and dump data separately.
>
> That gets you out of the huge-file-to-edit problem, but the performance
> costs of restoring a separate-data dump are a pretty serious
> disadvant
Tom Lane wrote:
Heikki Linnakangas writes:
On 10/06/10 16:21, Robert Haas wrote:
I do agree that the human readability of pg_dump is an asset in many
situations - I have often dumped out the DDL for particular objects
just to look at it, for example. However, I emphatically do NOT agree
that
Heikki Linnakangas writes:
> On 10/06/10 16:21, Robert Haas wrote:
>> I do agree that the human readability of pg_dump is an asset in many
>> situations - I have often dumped out the DDL for particular objects
>> just to look at it, for example. However, I emphatically do NOT agree
>> that leavin
On 10/06/10 16:21, Robert Haas wrote:
I do agree that the human readability of pg_dump is an asset in many
situations - I have often dumped out the DDL for particular objects
just to look at it, for example. However, I emphatically do NOT agree
that leaving someone with a 500MB dump file (or, fo
Excerpts from Bruce Momjian's message of mié jun 09 21:35:57 -0400 2010:
> Alvaro Herrera wrote:
> > Excerpts from Bruce Momjian's message of mi\xc3\xa9 jun 09 21:10:21 -0400
> > 2010:
> >
> > > I think users would rather have the restore fail, and know right away
> > > they have an issue, than t
Stephen Frost writes:
> To this point, and perhaps to the other regarding VIEW definitions to
> some extent, while the solution would move us from 80% to 90% of "things
> in PG that might cause a restore from an older pg_dump to fail", I think
> another metric we should consider is "% of our user
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > Erm, I don't know that we deal with function-body problems today, even
> > when using the newer version of pg_dump, do we?
>
> Right, any forward-compatibility problems arising inside functions
> are strictly the user's to deal wi
Stephen Frost writes:
> Erm, I don't know that we deal with function-body problems today, even
> when using the newer version of pg_dump, do we?
Right, any forward-compatibility problems arising inside functions
are strictly the user's to deal with, and always have been.
So Stefan's point is tha
Stephen Frost writes:
> We're talking about a quote-everything option, not what quote_ident()
> does today. I don't see why that needs to be done by the backend or why
> pg_dump/pg_restore doesn't have enough info to handle that.
Are you proposing to stick a SQL parser into pg_dump so that it ca
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stefan Kaltenbrunner writes:
> > That is exactly what I think is "to big a promise" - I don't think we
> > can actually guarantee that this will fix the dump/restore issue (well
> > the dump might load but say the 3 lines of plpgsql using dynamic SQL
Bruce,
* Bruce Momjian (br...@momjian.us) wrote:
> > Well, if you dump in custom format, it could be useful to be able to
> > do this on pg_restore time. Not having followed this thread in detail,
> > but would that work? That would be a much more useful option...
>
> I don't think so because muc
* Bruce Momjian (br...@momjian.us) wrote:
> >From a code perspective, the difficulting in adding such a flag is that
> much of the quoting happens inside the backend, not by pg_dump, and
> therefore there is significant code change required to add this flag.
So, that strikes me as the main argumen
Stefan Kaltenbrunner writes:
> That is exactly what I think is "to big a promise" - I don't think we
> can actually guarantee that this will fix the dump/restore issue (well
> the dump might load but say the 3 lines of plpgsql using dynamic SQL
> will still be broken).
Yeah, that's a might
Stephen Frost wrote:
* Magnus Hagander (mag...@hagander.net) wrote:
On Thu, Jun 10, 2010 at 15:35, Stefan Kaltenbrunner
wrote:
that will pretty much defeat the purpose for most use cases i guess because
people will dump with the defaults and only discover the problem after the
fact.
Well, if
Bruce Momjian writes:
> From a code perspective, the difficulting in adding such a flag is that
> much of the quoting happens inside the backend, not by pg_dump, and
> therefore there is significant code change required to add this flag.
Yeah, and not only that, but you'd need the *old* server to
* Magnus Hagander (mag...@hagander.net) wrote:
> On Thu, Jun 10, 2010 at 15:35, Stefan Kaltenbrunner
> wrote:
> > that will pretty much defeat the purpose for most use cases i guess because
> > people will dump with the defaults and only discover the problem after the
> > fact.
>
> Well, if you d
Robert Haas wrote:
On Thu, Jun 10, 2010 at 9:35 AM, Stefan Kaltenbrunner
wrote:
I do agree that the human readability of pg_dump is an asset in many
situations - I have often dumped out the DDL for particular objects
just to look at it, for example. However, I emphatically do NOT agree
that le
Magnus Hagander wrote:
> On Thu, Jun 10, 2010 at 15:35, Stefan Kaltenbrunner
> wrote:
> > Robert Haas wrote:
> >>
> >> On Thu, Jun 10, 2010 at 9:02 AM, Stefan Kaltenbrunner
> >> wrote:
> >>>
> >>> I for myself would be rather annoyed if we started quoting all column
> >>> names
> >>> in our dumps
On Thu, Jun 10, 2010 at 9:35 AM, Stefan Kaltenbrunner
wrote:
>> I do agree that the human readability of pg_dump is an asset in many
>> situations - I have often dumped out the DDL for particular objects
>> just to look at it, for example. However, I emphatically do NOT agree
>> that leaving some
Stefan Kaltenbrunner wrote:
> > I do agree that the human readability of pg_dump is an asset in many
> > situations - I have often dumped out the DDL for particular objects
> > just to look at it, for example. However, I emphatically do NOT agree
> > that leaving someone with a 500MB dump file (or
On Thu, Jun 10, 2010 at 15:35, Stefan Kaltenbrunner
wrote:
> Robert Haas wrote:
>>
>> On Thu, Jun 10, 2010 at 9:02 AM, Stefan Kaltenbrunner
>> wrote:
>>>
>>> I for myself would be rather annoyed if we started quoting all column
>>> names
>>> in our dumps. This is seriously hampering readability a
Robert Haas wrote:
On Thu, Jun 10, 2010 at 9:02 AM, Stefan Kaltenbrunner
wrote:
I for myself would be rather annoyed if we started quoting all column names
in our dumps. This is seriously hampering readability and while it is
already annoying that pg_dump output is slightly different from the o
On Thu, Jun 10, 2010 at 9:02 AM, Stefan Kaltenbrunner
wrote:
> I for myself would be rather annoyed if we started quoting all column names
> in our dumps. This is seriously hampering readability and while it is
> already annoying that pg_dump output is slightly different from the original
> DDL us
Hartmut Goebel wrote:
Am 07.06.2010 02:32, schrieb Robert Haas:
But we will likely add more
keywords at some point in the future, and while providing an output
format that quotes everything won't fix every potential problem, it
might make life easier for some people.
+10
Exactly my point: M
Bruce,
* Bruce Momjian (br...@momjian.us) wrote:
> Robert Haas wrote:
> > > In a way, the fact that the restore fails can be seen as a feature ---
> > > they get the error before the go live on 8.4. ?(Yeah, I am serious.)
> >
> > Eeh, I've had this happen to me on earlier releases, and it didn't
Am 07.06.2010 02:32, schrieb Robert Haas:
> But we will likely add more
> keywords at some point in the future, and while providing an output
> format that quotes everything won't fix every potential problem, it
> might make life easier for some people.
+10
Exactly my point: Make life easier fo
Am 05.06.2010 22:02, schrieb Dimitri Fontaine:
> Alvaro Herrera writes:
>
>> I don't think "dumps must be human-readable" is an argument to reject
>> such a switch, as long as it's off by default. And I haven't seen any
>> other valid argument either, so +1 from me.
>
> Well as Bruce said this o
Am 10.06.2010 03:10, schrieb Bruce Momjian:
> The point is that if WINDOW was not a reserved word in 8.3 but is in
> 8.4, then every reference to a user column of WINDOW in any 8.4
> application will need to be double-quoted, and odds are the user did not
> do that in 8.3.
This argument is like:
Hartmut Goebel wrote:
> re. 1): While this may be true for many applications it is using
> hand-crafted SQL statements, it is plain wrong for all applications
> using some abstraction layer. These layers need to quote column
> names anyway and the application does not need to be changed here
> a
On Wed, Jun 9, 2010 at 9:35 PM, Bruce Momjian wrote:
> Robert Haas wrote:
>> > I think users would rather have the restore fail, and know right away
>> > they have an issue, than to do the upgrade, and find out later that some
>> > of their application queries fail and they need to run around fixi
Alvaro Herrera wrote:
> Excerpts from Bruce Momjian's message of mi?? jun 09 21:10:21 -0400 2010:
>
> > I think users would rather have the restore fail, and know right away
> > they have an issue, than to do the upgrade, and find out later that some
> > of their application queries fail and they
Robert Haas wrote:
> > I think users would rather have the restore fail, and know right away
> > they have an issue, than to do the upgrade, and find out later that some
> > of their application queries fail and they need to run around fixing
> > them. ?(FYI, pg_upgrade would use the new pg_dump an
Excerpts from Bruce Momjian's message of mié jun 09 21:10:21 -0400 2010:
> I think users would rather have the restore fail, and know right away
> they have an issue, than to do the upgrade, and find out later that some
> of their application queries fail and they need to run around fixing
> them.
On Wed, Jun 9, 2010 at 9:10 PM, Bruce Momjian wrote:
> Robert Haas wrote:
>> On Sun, Jun 6, 2010 at 2:53 PM, Dimitri Fontaine
>> wrote:
>> > Robert Haas writes:
>> >>> Well as Bruce said this option won't solve the OP's problem, unless the
>> >>> application he's using for managing the backups
Robert Haas wrote:
> On Sun, Jun 6, 2010 at 2:53 PM, Dimitri Fontaine
> wrote:
> > Robert Haas writes:
> >>> Well as Bruce said this option won't solve the OP's problem, unless the
> >>> application he's using for managing the backups do use the option.
> >>
> >> Well, that's a pretty trivial ch
Robert Haas writes:
> I think as a community we can sometimes be a bit intolerant of people
> who don't do things exactly the right way and get themselves into
> trouble.
Casting aside the sweeping generalizations for a moment ... this is
about how much effort we are willing to put into making up
On Sun, Jun 6, 2010 at 2:53 PM, Dimitri Fontaine wrote:
> Robert Haas writes:
>>> Well as Bruce said this option won't solve the OP's problem, unless the
>>> application he's using for managing the backups do use the option.
>>
>> Well, that's a pretty trivial change to the backup script. +1 fro
Robert Haas writes:
>> Well as Bruce said this option won't solve the OP's problem, unless the
>> application he's using for managing the backups do use the option.
>
> Well, that's a pretty trivial change to the backup script. +1 from me on
> providing a pg_dump option.
The application still ha
On Jun 5, 2010, at 4:02 PM, Dimitri Fontaine
wrote:
Alvaro Herrera writes:
I don't think "dumps must be human-readable" is an argument to reject
such a switch, as long as it's off by default. And I haven't seen
any
other valid argument either, so +1 from me.
Well as Bruce said this opti
Alvaro Herrera writes:
> I don't think "dumps must be human-readable" is an argument to reject
> such a switch, as long as it's off by default. And I haven't seen any
> other valid argument either, so +1 from me.
Well as Bruce said this option won't solve the OP's problem, unless the
application
Excerpts from Kevin Grittner's message of vie jun 04 14:53:17 -0400 2010:
> Same here. I suspect that this is much more commonn than many
> PostgreSQL developers realize; and I think it makes a reasonable
> case for at least an *option* to quote all identifiers emitted by
> pg_dump.
I don't thin
Bernd Helmle writes:
> Out of curiosity, why is this a "bug" now?
It isn't...
> And wouldn't introducing backpatching such behavorial changes to pg_dump
> violate our policy in *not* to change such things in minor releases?
That was just an off-the-cuff idea, it has certainly not become policy
--On 4. Juni 2010 15:19:42 -0400 Bruce Momjian wrote:
That would make the bug go away,
rather than require users to use a special flag (and find out only after
they were doing the reload).
Out of curiosity, why is this a "bug" now? We recommend migration
procedures always to use the pg_dum
David Fetter wrote:
> On Fri, Jun 04, 2010 at 02:59:48PM -0400, Bruce Momjian wrote:
> > Kevin Grittner wrote:
> > > Hartmut Goebel wrote:
> > >
> > > > The application already quotes all column names :-) It's using a
> > > > generic framework which does not (and must not) rely on column
> > > >
David Fetter wrote:
> It seems like something that's doable by pg_dump as a "default
> off" option. TODO for 9.1?
Sounds good to me.
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
On Fri, Jun 04, 2010 at 02:59:48PM -0400, Bruce Momjian wrote:
> Kevin Grittner wrote:
> > Hartmut Goebel wrote:
> >
> > > The application already quotes all column names :-) It's using a
> > > generic framework which does not (and must not) rely on column
> > > names being non-keywords.
> >
>
Kevin Grittner wrote:
> Hartmut Goebel wrote:
>
> > The application already quotes all column names :-) It's using a
> > generic framework which does not (and must not) rely on column
> > names being non-keywords.
>
> Same here. I suspect that this is much more commonn than many
> PostgreSQL
Hartmut Goebel wrote:
> The application already quotes all column names :-) It's using a
> generic framework which does not (and must not) rely on column
> names being non-keywords.
Same here. I suspect that this is much more commonn than many
PostgreSQL developers realize; and I think it mak
Am 04.06.2010 14:57, schrieb Stephen Frost:
> * Hartmut Goebel (h.goe...@goebel-consult.de) wrote:
>> Am 04.06.2010 13:56, schrieb Stephen Frost:
>>> Quoting all column names makes the dump script much more difficult for
>>> human consumption, which is important.
>>
>> I don't agree with you here.
Am 04.06.2010 13:56, schrieb Stephen Frost:
> Quoting all column names makes the dump script much more difficult for
> human consumption, which is important.
I don't agree with you here. But this may be a matter of personal taste.
Esp. I think, functionality is much ore important than a small de
* Hartmut Goebel (h.goe...@goebel-consult.de) wrote:
> Am 04.06.2010 13:56, schrieb Stephen Frost:
> > Quoting all column names makes the dump script much more difficult for
> > human consumption, which is important.
>
> I don't agree with you here. But this may be a matter of personal taste.
>
>
* Hartmut Goebel (h.goe...@goebel-consult.de) wrote:
> Am 03.06.2010 16:15, schrieb Tom Lane:
> > That was considered and rejected long ago. Readability of the dump
> > script is something that we put a nonzero value on.
>
> I assume you mean readability for humans?!
Yes, readability for humans
Am 03.06.2010 20:07, schrieb Tom Lane:
> "Kevin Grittner" writes:
>> Hartmut Goebel wrote:
>>> If upgraded the rpm-packages from 8.3 to 8.4. Then postgres failed
>>> starting (something like "Database version mismatch").
>
>> You need to be running the old server using 8.3 software and while
>>
Am 03.06.2010 16:15, schrieb Tom Lane:
>> Solution: pg_dump should quote *all* column-names, no matter if they are
>> keywords or not.
>
> That was considered and rejected long ago. Readability of the dump
> script is something that we put a nonzero value on.
Sorry, I do not understand this.
I
On Thu, Jun 03, 2010 at 06:04:16PM +0200, Hartmut Goebel wrote:
> If upgraded the rpm-packages from 8.3 to 8.4. Then postgres failed
> starting (something like "Database version mismatch"). So I downgraded
> to 8.3, pg_dump'ed there, upgraded and pg_restore'd.
pg_dump will complain if its version
"Kevin Grittner" writes:
> Hartmut Goebel wrote:
>> If upgraded the rpm-packages from 8.3 to 8.4. Then postgres failed
>> starting (something like "Database version mismatch").
> You need to be running the old server using 8.3 software and while
> using pg_dump from 8.4 software. Does your pac
Hartmut Goebel wrote:
> If upgraded the rpm-packages from 8.3 to 8.4. Then postgres failed
> starting (something like "Database version mismatch").
You need to be running the old server using 8.3 software and while
using pg_dump from 8.4 software. Does your packager provide some
way to instal
Am 03.06.2010 16:16, schrieb Kevin Grittner:
>> 8.4 did not allow accessing the 8.3 database
>
> What do you mean? (What did you try and what happened?)
If upgraded the rpm-packages from 8.3 to 8.4. Then postgres failed
starting (something like "Database version mismatch"). So I downgraded
to
Am 03.06.2010 15:43, schrieb Kevin Grittner:
> Note that the documentation recommends always running pg_dump using
> the executable from the target version, not the source version. Are
> you using the pg_dump executable from 8.4?
I dumped with the executable form 8.3.
8.4 did not allow accessin
>Hartmut Goebel wrote:
> I dumped with the executable form 8.3.
That's not expected to work for an upgrade to 8.4.
> 8.4 did not allow accessing the 8.3 database
What do you mean? (What did you try and what happened?)
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.o
"Hartmut Goebel" writes:
> If a 8.3 table contains a column named "window", the dump can not be
> restored into a 8.4 database. Reasons: a) "window" is a new keyword in 8.4
> b) pg_dump does not quote column names.
This is one of the cases where it's helpful to use the newer version's
pg_dump.
>
"Hartmut Goebel" wrote:
> Description:pg_dump does not quote column names ->
> pg_restore may fail when upgrading
> If a 8.3 table contains a column named "window", the dump can not
> be restored into a 8.4 database. Reasons: a) "window" is a new
> keyword in 8.4 b)
The following bug has been logged online:
Bug reference: 5488
Logged by: Hartmut Goebel
Email address: h.goe...@goebel-consult.de
PostgreSQL version: 8.3 / 8.4
Operating system: all
Description:pg_dump does not quote column names -> pg_restore may
fail when upgrading
77 matches
Mail list logo
