On Sat, Dec 1, 2012 at 03:41:15PM -0500, Andrew Dunstan wrote:
On 12/01/2012 02:34 PM, Bruce Momjian wrote:
On Sat, Dec 1, 2012 at 02:31:03PM -0500, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2012-12-01 12:14:37 -0500, Tom Lane wrote:
It could do with some comments
On 11/30/2012 11:10 PM, Tom Lane wrote:
Some of the buildfarm members are failing the pg_upgrade regression test
since commit 12ee6ec71f8754ff3573711032b9b4d5a764ba84. I can duplicate
it here, and the symptom is:
pg_restore: creating TYPE float8range
pg_restore: creating TYPE insenum
On Sat, Dec 1, 2012 at 07:43:17AM -0500, Andrew Dunstan wrote:
On 11/30/2012 11:10 PM, Tom Lane wrote:
Some of the buildfarm members are failing the pg_upgrade regression test
since commit 12ee6ec71f8754ff3573711032b9b4d5a764ba84. I can duplicate
it here, and the symptom is:
pg_restore:
On Sat, Dec 1, 2012 at 10:25:10AM -0500, Bruce Momjian wrote:
On Sat, Dec 1, 2012 at 07:43:17AM -0500, Andrew Dunstan wrote:
On 11/30/2012 11:10 PM, Tom Lane wrote:
Some of the buildfarm members are failing the pg_upgrade regression test
since commit
On Sat, Dec 1, 2012 at 10:41:06AM -0500, Bruce Momjian wrote:
OK, I found the problem, and it isn't good. Our manual clearly says:
ALTER TYPE ... ADD VALUE (the form that adds a new value
to an enum type) cannot be executed inside a transaction block.
This also means it can't
On 2012-12-01 10:55:09 -0500, Bruce Momjian wrote:
On Sat, Dec 1, 2012 at 10:41:06AM -0500, Bruce Momjian wrote:
OK, I found the problem, and it isn't good. Our manual clearly says:
ALTER TYPE ... ADD VALUE (the form that adds a new value
to an enum type) cannot be executed
On 2012-12-01 10:55:09 -0500, Bruce Momjian wrote:
This does make me wonder why pg_restore supports --single-transaction if
it has known failure cases (that are not documented in the pg_restore
manual page, only in the ALTER TYPE manual page). Are users really
going to know if their database
Bruce Momjian br...@momjian.us writes:
This does make me wonder why pg_restore supports --single-transaction if
it has known failure cases (that are not documented in the pg_restore
manual page, only in the ALTER TYPE manual page).
AFAIR, the ADD VALUE path is only taken with --binary-upgrade,
On Sat, Dec 1, 2012 at 10:55:09AM -0500, Bruce Momjian wrote:
Scratch that idea. By definition, no matter how we modify pg_dump or
pg_restore, ALTER TYPE ... ADD VALUE is never going to be able to be run
in a multi-statement transaction, so we have to certainly remove
--single-transction,
On Sat, Dec 1, 2012 at 11:11:31AM -0500, Bruce Momjian wrote:
Shame --- pg_upgrade performance was improving so steadily, I was hoping
to see negative duration times soon. ;-)
Is that the definition of optimism? :-)
--
Bruce Momjian br...@momjian.ushttp://momjian.us
On 2012-12-01 17:03:03 +0100, Andres Freund wrote:
Could we possibly allow adding enum values to a type which was just created in
this transaction? That shouldn't be too hard. At least easier than providing
the capability to pre-assign the next N oids...
The attached patch does just that. Its
On 2012-12-01 17:36:20 +0100, Andres Freund wrote:
On 2012-12-01 17:03:03 +0100, Andres Freund wrote:
Could we possibly allow adding enum values to a type which was just created
in
this transaction? That shouldn't be too hard. At least easier than providing
the capability to pre-assign
Andres Freund and...@2ndquadrant.com writes:
The attached patch does just that. Its *not* ready yet though, as it
will be apparent for everyone who reads it ;)
ISTM this sort of thing ought to be safe enough, though you probably
need to insist both that the pg_type row's xmin be current XID and
On 12/01/2012 11:38 AM, Andres Freund wrote:
On 2012-12-01 17:36:20 +0100, Andres Freund wrote:
On 2012-12-01 17:03:03 +0100, Andres Freund wrote:
Could we possibly allow adding enum values to a type which was just created in
this transaction? That shouldn't be too hard. At least easier than
On Sat, Dec 1, 2012 at 05:36:20PM +0100, Andres Freund wrote:
On 2012-12-01 17:03:03 +0100, Andres Freund wrote:
Could we possibly allow adding enum values to a type which was just created
in
this transaction? That shouldn't be too hard. At least easier than providing
the capability to
Andrew Dunstan and...@dunslane.net writes:
Does this actually get you over the problem identified in the comment?:
* We disallow this in transaction blocks, because we can't cope
* with enum OID values getting into indexes and then having their
* defining pg_enum entries go away.
Why
On 12/01/2012 12:06 PM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
Does this actually get you over the problem identified in the comment?:
* We disallow this in transaction blocks, because we can't cope
* with enum OID values getting into indexes and then having their
On 2012-12-01 12:00:46 -0500, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
The attached patch does just that. Its *not* ready yet though, as it
will be apparent for everyone who reads it ;)
ISTM this sort of thing ought to be safe enough, though you probably
need to insist
On 2012-12-01 12:01:17 -0500, Andrew Dunstan wrote:
On 12/01/2012 11:38 AM, Andres Freund wrote:
On 2012-12-01 17:36:20 +0100, Andres Freund wrote:
On 2012-12-01 17:03:03 +0100, Andres Freund wrote:
Could we possibly allow adding enum values to a type which was just
created in
this
Andres Freund and...@2ndquadrant.com writes:
On 2012-12-01 12:00:46 -0500, Tom Lane wrote:
ISTM this sort of thing ought to be safe enough, though you probably
need to insist both that the pg_type row's xmin be current XID and
that it not be HEAP_UPDATED.
I was concerned about updated rows
On 2012-12-01 12:14:37 -0500, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2012-12-01 12:00:46 -0500, Tom Lane wrote:
ISTM this sort of thing ought to be safe enough, though you probably
need to insist both that the pg_type row's xmin be current XID and
that it not be
On Sat, Dec 1, 2012 at 07:32:48PM +0100, Andres Freund wrote:
On 2012-12-01 12:14:37 -0500, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2012-12-01 12:00:46 -0500, Tom Lane wrote:
ISTM this sort of thing ought to be safe enough, though you probably
need to insist
On 2012-12-01 13:43:44 -0500, Bruce Momjian wrote:
On Sat, Dec 1, 2012 at 07:32:48PM +0100, Andres Freund wrote:
On 2012-12-01 12:14:37 -0500, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2012-12-01 12:00:46 -0500, Tom Lane wrote:
ISTM this sort of thing ought to
Andres Freund and...@2ndquadrant.com writes:
On 2012-12-01 13:43:44 -0500, Bruce Momjian wrote:
I believe this text in alter_type.sgml need updating:
commandALTER TYPE ... ADD VALUE/ (the form that adds a new value to an
enum type) cannot be executed inside a transaction block.
I
Andres Freund and...@2ndquadrant.com writes:
On 2012-12-01 12:14:37 -0500, Tom Lane wrote:
It could do with some comments ;-)
Hehe, yes. Hopefully this version has enough of that.
Hm, maybe too many --- I don't really think it's necessary for utility.c
to provide a redundant explanation of
On Sat, Dec 1, 2012 at 02:31:03PM -0500, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2012-12-01 12:14:37 -0500, Tom Lane wrote:
It could do with some comments ;-)
Hehe, yes. Hopefully this version has enough of that.
Hm, maybe too many --- I don't really think it's
On 2012-12-01 14:31:03 -0500, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2012-12-01 12:14:37 -0500, Tom Lane wrote:
It could do with some comments ;-)
Hehe, yes. Hopefully this version has enough of that.
Hm, maybe too many --- I don't really think it's necessary for
On 12/01/2012 02:34 PM, Bruce Momjian wrote:
On Sat, Dec 1, 2012 at 02:31:03PM -0500, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2012-12-01 12:14:37 -0500, Tom Lane wrote:
It could do with some comments ;-)
Hehe, yes. Hopefully this version has enough of that.
Hm,
Some of the buildfarm members are failing the pg_upgrade regression test
since commit 12ee6ec71f8754ff3573711032b9b4d5a764ba84. I can duplicate
it here, and the symptom is:
pg_restore: creating TYPE float8range
pg_restore: creating TYPE insenum
pg_restore: [archiver (db)] Error while PROCESSING
29 matches
Mail list logo
