Re: [PATCHES] ADD/DROPS INHERIT (actually INHERIT / NO INHERIT)
Tom Lane said: Jeremy Drake [EMAIL PROTECTED] writes: On Sun, 2 Jul 2006, Tom Lane wrote: Nah, it was a false alarm: I was looking at the first post-patch report, http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=mongoosedt=2006-07-02%2003:30:01 but apparently mongoose had managed to pick up a partially-updated snapshot. The later reports (including mongoose's own next try an hour later) were all OK. As the keeper of mongoose, is there anything I should do to prevent it from picking up a partially-updated snapshot? Or is this just a race condition that's bound to happen now and then? Well, it's certainly not *your* problem to fix. I suspect that this risk is inherent in CVS --- although there might also be something involved about our primary-vs-mirror CVS setup. Does anyone know exactly how the mirroring is done and whether it makes any attempt to ensure a consistent copy? Since CVS updates are not atomic, it's hard to see how mirroring could be, unless you did something like disallow updates, mirror, allow updates. I suspect such a cure would be worse than the disease. This is such a rare event that I don't think it's worth the trouble. Buildfarm members are doing 200 builds a day or more, and I can't recall having seen this before. cheers andrew ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] ADD/DROPS INHERIT (actually INHERIT / NO INHERIT)
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Tom Lane wrote: So this patch was by no stretch of the imagination ready to apply, but you did it anyway. Right. What is your next question? Perhaps why is the buildfarm failing would be appropriate. Yes, that is appropriate, though it seems Neil's cleanup of the patch has fixed it now. I see only a single stats failure and an initdb failure in the buildfarm, neither of which I assume are related to the patch. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] ADD/DROPS INHERIT (actually INHERIT / NO INHERIT)
On Sun, 2 Jul 2006, Tom Lane wrote: Nah, it was a false alarm: I was looking at the first post-patch report, http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=mongoosedt=2006-07-02%2003:30:01 but apparently mongoose had managed to pick up a partially-updated snapshot. The later reports (including mongoose's own next try an hour later) were all OK. As the keeper of mongoose, is there anything I should do to prevent it from picking up a partially-updated snapshot? Or is this just a race condition that's bound to happen now and then? ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] ADD/DROPS INHERIT (actually INHERIT / NO INHERIT)
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Tom Lane wrote: Perhaps why is the buildfarm failing would be appropriate. Yes, that is appropriate, though it seems Neil's cleanup of the patch has fixed it now. I see only a single stats failure and an initdb failure in the buildfarm, neither of which I assume are related to the patch. Nah, it was a false alarm: I was looking at the first post-patch report, http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=mongoosedt=2006-07-02%2003:30:01 but apparently mongoose had managed to pick up a partially-updated snapshot. The later reports (including mongoose's own next try an hour later) were all OK. Sorry for the noise. Thanks for keeping an eye on that buildfarm. I often forget to look myself. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] ADD/DROPS INHERIT (actually INHERIT / NO INHERIT)
Jeremy Drake [EMAIL PROTECTED] writes: On Sun, 2 Jul 2006, Tom Lane wrote: Nah, it was a false alarm: I was looking at the first post-patch report, http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=mongoosedt=2006-07-02%2003:30:01 but apparently mongoose had managed to pick up a partially-updated snapshot. The later reports (including mongoose's own next try an hour later) were all OK. As the keeper of mongoose, is there anything I should do to prevent it from picking up a partially-updated snapshot? Or is this just a race condition that's bound to happen now and then? Well, it's certainly not *your* problem to fix. I suspect that this risk is inherent in CVS --- although there might also be something involved about our primary-vs-mirror CVS setup. Does anyone know exactly how the mirroring is done and whether it makes any attempt to ensure a consistent copy? regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] ADD/DROPS INHERIT (actually INHERIT / NO INHERIT)
Bruce Momjian [EMAIL PROTECTED] writes: I ran pgindent on the tablecmds.c block of code, and cleaned up some boolean assignments. There are a few XXX comments still in the code so someone should look at those questions and either modify the code or remove the comments. So this patch was by no stretch of the imagination ready to apply, but you did it anyway. regards, tom lane ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] ADD/DROPS INHERIT (actually INHERIT / NO INHERIT)
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: I ran pgindent on the tablecmds.c block of code, and cleaned up some boolean assignments. There are a few XXX comments still in the code so someone should look at those questions and either modify the code or remove the comments. So this patch was by no stretch of the imagination ready to apply, but you did it anyway. Right. What is your next question? -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] ADD/DROPS INHERIT (actually INHERIT / NO INHERIT)
Bruce Momjian [EMAIL PROTECTED] writes: Tom Lane wrote: So this patch was by no stretch of the imagination ready to apply, but you did it anyway. Right. What is your next question? Perhaps why is the buildfarm failing would be appropriate. regards, tom lane ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[PATCHES] ADD/DROPS INHERIT (actually INHERIT / NO INHERIT)
I cleaned up the code and added some more documentation.
I think I've addressed all the concerns raised so far. Please tell me if I've
missed anything.
There were a few tangentially related issues that have come up that I think
are TODOs. I'm likely to tackle one or two of these next so I'm interested in
hearing feedback on them as well.
. Constraints currently do not know anything about inheritance. Tom suggested
adding a coninhcount and conislocal like attributes have to track their
inheritance status.
. Foreign key constraints currently do not get copied to new children (and
therefore my code doesn't verify them). I don't think it would be hard to
add them and treat them like CHECK constraints.
. No constraints at all are copied to tables defined with LIKE. That makes it
hard to use LIKE to define new partitions. The standard defines LIKE and
specifically says it does not copy constraints. But the standard already has
an option called INCLUDING DEFAULTS; we could always define a non-standard
extension LIKE table INCLUDING CONSTRAINTS that gives the user the option to
request a copy including constraints.
. Personally, I think the whole attislocal thing is bunk. The decision about
whether to drop a column from children tables or not is something that
should be up to the user and trying to DWIM based on whether there was ever
a local definition or the column was acquired purely through inheritance is
hardly ever going to match up with user expectations.
. And of course there's the whole unique and primary key constraint issue. I
think to get any traction at all on this you have a prerequisite of a real
partitioned table implementation where the system knows what the partition
key is so it can recognize when it's a leading part of an index key.
Index: doc/src/sgml/ddl.sgml
===
RCS file: /projects/cvsroot/pgsql/doc/src/sgml/ddl.sgml,v
retrieving revision 1.57
diff -c -p -c -r1.57 ddl.sgml
*** doc/src/sgml/ddl.sgml 30 Apr 2006 21:15:32 - 1.57
--- doc/src/sgml/ddl.sgml 13 Jun 2006 22:39:25 -
*** VALUES ('New York', NULL, NULL, 'NY');
*** 2061,2087
/para
para
!Table inheritance can currently only be defined using the xref
!linkend=sql-createtable endterm=sql-createtable-title
!statement. The related statement commandCREATE TABLE AS/command does
!not allow inheritance to be specified. There
!is no way to add an inheritance link to make an existing table into
!a child table. Similarly, there is no way to remove an inheritance
!link from a child table once it has been defined, other than by dropping
!the table completely. A parent table cannot be dropped
!while any of its children remain. If you wish to remove a table and
!all of its descendants, one easy way is to drop the parent table with
!the literalCASCADE/literal option.
/para
para
xref linkend=sql-altertable endterm=sql-altertable-title will
!propagate any changes in column data definitions and check
!constraints down the inheritance hierarchy. Again, dropping
!columns or constraints on parent tables is only possible when using
!the literalCASCADE/literal option. commandALTER
!TABLE/command follows the same rules for duplicate column merging
!and rejection that apply during commandCREATE TABLE/command.
/para
sect2 id=ddl-inherit-caveats
--- 2061,2108
/para
para
!Table inheritance can be defined using the xref linkend=sql-createtable
!endterm=sql-createtable-title statement using the
!commandINHERITS/command keyword. However the related statement
!commandCREATE TABLE AS/command does not allow inheritance to be
!specified.
! /para
!
! para
!Alternatively a table which is already defined in a compatible way can have
!a new parent added with xref linkend=sql-altertable
!endterm=sql-altertable-title using the commandINHERIT/command
!subform. To do this the new child table must already include columns with
!the same name and type as the columns of the parent. It must also include
!check constraints with the same name and check expression as those of the
!parent. Similarly an inheritance link can be removed from a child using the
!commandALTER TABLE/command using the commandNO INHERIT/command
!subform.
!
! para
!One convenient way to create a compatible table to be a new child is using
!the commandLIKE/command option of commandCREATE TABLE/command. This
!creates a table with the same columns with the same type (however note the
!caveat below regarding constraints). Alternatively a compatible table can
!be created by first creating a new child using commandCREATE
!TABLE/command then removing the inheritance link with commandALTER
!TABLE/command. /para
!
! para
!A parent table cannot be dropped while any
!of
