Closed GoogleCodeExporter closed 9 years ago
Reproducible in r143
==== Running RPostgreSQL/tests/dbtemptable.R
Loading required package: RPostgreSQL
Loading required package: DBI
row number 0 is out of range 0..-1
*** caught segfault ***
address (nil), cause 'memory not mapped'
Traceback:
1: .Call("RS_PostgreSQL_exec", conId, statement, PACKAGE = .PostgreSQLPkgName)
2: postgresqlExecStatement(conn, statement, ...)
3: is(object, Cl)
4: is(object, Cl)
5: .valueClassTest(standardGeneric("dbSendQuery"), "DBIResult", "dbSendQuery")
6: dbSendQuery(con, "CREATE TEMPORARY TABLE xyz ON COMMIT DROP AS select * from foo limit 1; select * from xyz;")
aborting ...
check_with_vars.sh: line 42: 5871 Segmentation fault R --slave < $f
A test script and a patch against r143 is attached.
The segmentation fault is caused by accessing the query result without
checking the existence of result.
A check for the number of tuples obtained is added.
The expected results is
==== Running RPostgreSQL/tests/dbtemptable.R
Loading required package: RPostgreSQL
Loading required package: DBI
name
1 bar
PASS -- ended without segmentation fault
Original comment by tomoa...@kenroku.kanazawa-u.ac.jp
on 24 Sep 2010 at 11:52
Attachments:
Further thinking on the context of the location, the code is trying to identify
if the column is set to NOT NULL or NULL value is allowed. However, the NOT
NULL enforcement is done by the server side and the necessity or even utility
in the client side is questionable.
Perhaps, this is better discussed in r-db-sig@stat.math.ethz.ch, since this is
related to DBI interface as a whole, including other drivers and usage.
I actually think these could be useful in a result for dbReadTable() call,
but not for general dbSendQuery or dbGetQuery results where the SQL is visible
and the queried target may not represent a simple table.
Original comment by tomoa...@kenroku.kanazawa-u.ac.jp
on 25 Sep 2010 at 2:30
Attachments:
Reassigned owner.
Original comment by ne...@neiltiffin.com
on 13 Oct 2010 at 2:18
Fixed as of r160, r162.
Original comment by tomoa...@kenroku.kanazawa-u.ac.jp
on 14 Oct 2010 at 2:41
Original issue reported on code.google.com by
rmcge...@gmail.com
on 22 Sep 2010 at 7:46