Thread

1. Re: [BUGS] Running queries on inherited tables

   Tom Lane <tgl@sss.pgh.pa.us> — 1999-09-13T15:01:13Z

   Michael Richards <miker@scifair.acadiau.ca> writes:
   > On Sun, 12 Sep 1999, Tom Lane wrote:
   >> That would be a good route to a reimplementation, actually.  Want to
   >> have a go at it?
   > Sure.  I'll wade into the code and see if I can swim. I think I'll first
   > try to implement ALTER TABLE class_name DELETE COLUMN col_name
   
   > Which version do you suggest I work with to come up with patches?
   
   You should definitely start from current sources, not from REL6_5,
   in order to minimize the pain of integrating changes.  The tricky call
   here is how often to update your copy of current --- rebuilding every
   day is just a time sink, but if you let your copy get too far out of
   date then you have problems merging what you've done.  One possibility
   is to keep an eye on the cvs-committers digest, and update(+ merge
   changes) whenever someone commits changes in the same files that you've
   got changes to.
   
   > D'oh. Now that I think about it you'd need 2n the amount of space
   > anyway... That brings up an intersting point... Does the database do a
   > rollback if it runs out of space on the device?
   
   I think it rolls back OK if we fail to acquire a new page for a user
   table.  Failing to write a pg_log page might be disastrous though.
   Vadim would understand that better than I do.
   
   			regards, tom lane
   
   

2. Re: [BUGS] Running queries on inherited tables

   Vadim Mikheev <vadim@krs.ru> — 1999-09-13T18:21:29Z

   Tom Lane wrote:
   > 
   > > anyway... That brings up an intersting point... Does the database do a
   > > rollback if it runs out of space on the device?
   > 
   > I think it rolls back OK if we fail to acquire a new page for a user
   > table.  Failing to write a pg_log page might be disastrous though.
   > Vadim would understand that better than I do.
   
   There should be no problem with this too.
   
   Vadim