From: Andy S. <an...@ee...> - 2006-11-24 17:40:01
|
Our storage class has a cleanStore() method which is used by the installer to drop everything if the user decides to do a clean install (mostly used by devs). This never worked for me when using Postgresql. The reason is that I can't drop the bit_or function, even as db owner. Not even from pgadmin3 with the cascade option. And since PG is transactional, even for DDL, the whole cleanStore transaction is rolled back. The error I'm getting is: "ERROR: cannot drop function bit_or because it is required by the database system" Googling doesn't show that much for pg related "because it is required by the database system". Usually that happens if there are objects depening on this function or if it's a built-in function. Bit_or has no deps (none shown in pgadmin3) and isn't a built-in function. Question: Should we just remove the 'DROP AGGREGATE BIT_OR(bit)' from PostgresqlStorage? I'd prefer that over adding a checkPoint() in its cleanStore() method since transactions shouldn't be committed inside the db layer in that case. - Andy |
From: Bharat M. <bh...@me...> - 2006-11-25 04:45:13
|
Andy Staudacher wrote: > Our storage class has a cleanStore() method which is used by the installer > to drop everything if the user decides to do a clean install (mostly used by > devs). > > This never worked for me when using Postgresql. > The reason is that I can't drop the bit_or function, even as db owner. Not > even from pgadmin3 with the cascade option. > And since PG is transactional, even for DDL, the whole cleanStore > transaction is rolled back. That's odd. When I added that, I know that I was able to drop the aggregate. Hmm. g2dev=# \da bit_or List of aggregate functions Schema | Name | Data type | Description --------+--------+-----------+------------- public | bit_or | bit | (1 row) g2dev=# drop aggregate bit_or(bit); DROP AGGREGATE g2dev=# \da bit_or List of aggregate functions Schema | Name | Data type | Description --------+------+-----------+------------- (0 rows) It still works for me from the command line. And I see that we drop the aggregate in a separate connection in PostgreSqlStorage.. so even though it has an error is that really a problem? -Bharat |
From: Andy S. <an...@ee...> - 2006-11-25 05:08:34
|
gallery2=# drop aggregate BIT_OR(bit); ERROR: cannot drop function bit_or(bit) because it is required by the database system And that as the windows postgres user (owner of the db, all rights). And as i said, it doesn't report any deps on that function. And no, using a 2nd connection doesn't help since we don't commit the first transaction in case of of an error on dropping the function. So I'm +1 for ignoring errors, no error checking if dropping the function fails. - andy Bharat Mediratta wrote: > Andy Staudacher wrote: > > Our storage class has a cleanStore() method which is used by the > > installer to drop everything if the user decides to do a > clean install > > (mostly used by devs). > > > > This never worked for me when using Postgresql. > > The reason is that I can't drop the bit_or function, even > as db owner. > > Not even from pgadmin3 with the cascade option. > > And since PG is transactional, even for DDL, the whole cleanStore > > transaction is rolled back. > > That's odd. When I added that, I know that I was able to > drop the aggregate. Hmm. > > g2dev=# \da bit_or > List of aggregate functions > Schema | Name | Data type | Description > --------+--------+-----------+------------- > public | bit_or | bit | > (1 row) > > g2dev=# drop aggregate bit_or(bit); > DROP AGGREGATE > g2dev=# \da bit_or > List of aggregate functions > Schema | Name | Data type | Description > --------+------+-----------+------------- > (0 rows) > > It still works for me from the command line. And I see that > we drop the aggregate in a separate connection in > PostgreSqlStorage.. so even though it has an error is that > really a problem? > > -Bharat > |
From: Bharat M. <bh...@me...> - 2006-11-25 07:20:39
|
Andy Staudacher wrote: > gallery2=# drop aggregate BIT_OR(bit); > ERROR: cannot drop function bit_or(bit) because it is required by the > database system > > And that as the windows postgres user (owner of the db, all rights). > And as i said, it doesn't report any deps on that function. > > And no, using a 2nd connection doesn't help since we don't commit the first > transaction in case of of an error on dropping the function. > > So I'm +1 for ignoring errors, no error checking if dropping the function > fails. I'm +1 for ignoring errors in that particular case. We ignore errors when we try to install the aggregate also, so it should be ok if we don't manage to drop it. -Bharat |