Drop/Erase collection fails after several data has been loaded

[beccati@…]

Both with raserase and rasql erasing a collection becomes impossible after several data has been loaded into it with rasgeo

Unable to reproduce with a test case for now however bulk loading same data several times may cause it

raserase -coll TEST
ERROR - ctxRerase::main, l. 162: Serialisable exception r_Ebase_dbms: error in base DBMS.

rasql -q "drop collection TEST" $RADM
rasql: rasdaman query tool v1.0, rasdaman v8 — generated on 31.01.2012 17:14:19.
opening database RASBASE at localhost:7001...ok
Executing update query…ok
rasdaman error 206: Serialisable exception r_Ebase_dbms: error in base DBMS.
aborting transaction…ok
rasql done.

---

Request: 'commit TA'…Throwing Exception (SQLCODE=0):
Error: base DBMS reports: Error in base DBMS, error number: 0

Error in response: (35 206 0 Error in base DBMS, error number: ) Error in base DBMS, error number: 0

[beccati@…]

As requested here follows log files with —enable-debug for two of the collections giving errors on deletion:

errorInBaseDbmsOnDelete.log.tgz is related to the error condition described in the ticket
The core error seems to be as follows:
. . . . . . . . . . SELECT Tile FROM RAS_TILES WHERE BlobId = 137731
. . . . . . . . . LEAVE BLOBTile::kill() libpq 'select' did not yield 1 result but 0
. . . . . . . . . Throwing Exception (SQLCODE=0):

errorUnknownOnDelete.log.tgz is related to another collection giving an unknown error upon deletion attempt (this happens only for that collection), reporting the following:
. . . . . . LEAVE RnpRasDaManComm::decodeFragment, rasdaman exception caught: Exception: not specified
Error: request terminated: Exception: not specified
. . . . . . rasdaman exception kind=17, errorno=0
Error in response: (17 0) Exception: not specified

Alan

[beccati@…]

error in base dbms log

[beccati@…]

unspecified exception error log

[Dimitar Misev]

Ok I figured the problem, it happens in this code:

(void) snprintf( pgQuery, (size_t) sizeof(pgQuery), "SELECT Tile FROM RAS_TILES WHERE BlobId = %ld", indbmyOId5 );
TALK( pgQuery );
pgResult = PQexec( pgConn, pgQuery );
if (PQresultStatus(pgResult) != PGRES_TUPLES_OK)
{
  LEAVE( "BLOBTile::kill() libpq 'select tile' error: " << PQerrorMessage(pgConn) );
  PQclear( pgResult );
  generateException();
}
else if (PQntuples(pgResult) != 1)
{
  LEAVE( "BLOBTile::kill() libpq 'select' did not yield 1 result but " << PQntuples(pgResult) );
  PQclear( pgResult );
  generateException();
}

The data has been corrupted in some way, because there is an entry in the index but no entry in this RAS_TILES table.

For me it was happening with a long running import on a bigger dataset, where after certain time the import was interrupted. In the end neither the data was completely imported nor was I able to delete the collection. This consistently repeated 2-3 times, until I increased the timeout/countdown values in rasmgr.conf. However I wasn't able to reproduce it on a smaller dataset and very small timeout/countdown parameters.

Can you give it a try with the patch I attached? I'm not certain whether it will allow to remove everything properly, but it's worth trying.

[Dimitar Misev]

I've figured out the real reason for this problem as well as a workaround for it. I created a clearer ticket #237, and we can close this one.