[BUGS] BUG #5748: Invalid oidvector data during binary recv

[Yeb Havinga]

The following bug has been logged online:

Bug reference:  5748
Logged by:  Yeb Havinga
Email address:  yebhavi...@gmail.com
PostgreSQL version: 9.0.1
Operating system:   Linux
Description:Invalid oidvector data during binary recv
Details: 

postgres=# create table a as select ''::oidvector;
SELECT 1
postgres=# copy a to '/tmp/test' with binary;
COPY 1
postgres=# copy a from '/tmp/test' with binary;
ERROR:  invalid oidvector data

The error caused by the ARR_LBOUND(result)[0] != 0) check in oidvectorrecv,
and after some debugging and looking at common values of the lbound, I
wonder if this check itself is correct.

regards,
Yeb Havinga

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: [BUGS] BUG #5748: Invalid oidvector data during binary recv

[Yeb Havinga]

On 2010-11-11 16:48, Tom Lane wrote:

"Yeb Havinga"  writes:

postgres=# create table a as select ''::oidvector;
SELECT 1
postgres=# copy a to '/tmp/test' with binary;
COPY 1
postgres=# copy a from '/tmp/test' with binary;
ERROR:  invalid oidvector data

The problem seems to be that array_recv passes back a zero-dimensional
array, *not* a 1-D array, when it observes that the input has no
elements.  A zero-D array is not part of the subset of possible arrays
that we allow for oidvector.

I'm less than convinced that this is worth fixing.  oidvector is not
intended for general-purpose use anyway.  What's the use-case where this
would come up?
We're currently reading data from a remote pg_statistics, in particular 
stavalues1.. etc. Even when our own user defined relations do not make 
use of oidvectors (or intvectors), during testing on arbitrary 
pg_statistic rows we encountered this error message. Nonetheless we 
decided to report it as a bug, since it was not related to anyarray 
handling, but clearly a bug that oidvector cannot input binary, what it 
can input as text and output binary.


regards,
Yeb Havinga


--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: [BUGS] BUG #5748: Invalid oidvector data during binary recv

[Yeb Havinga]

On 2010-11-11 17:14, Heikki Linnakangas wrote:

On 11.11.2010 18:11, Yeb Havinga wrote:

We're currently reading data from a remote pg_statistics, in particular
stavalues1.. etc. Even when our own user defined relations do not make
use of oidvectors (or intvectors), during testing on arbitrary
pg_statistic rows we encountered this error message. Nonetheless we
decided to report it as a bug, since it was not related to anyarray
handling, but clearly a bug that oidvector cannot input binary, what it
can input as text and output binary.


Just reading such an oidvector should not throw an error, you must've 
tried to send it back to the server, perhaps to store it to a table.
Hmm.. we're reading with libpq in binary mode and the error is thrown in 
the receive function call. No storing yet in a table at that point.
But pg_statistic.stavalues* are a special anyway. They are defined as 
anyarray, but we don't normally allow you to create a table with 
anyarray columns.


Yes, but the test case shows the actual error can be triggered without 
any use of anyarray.


If there is going to be a patch fixing things, the value 
'{"1"}'::oidvector[] can't be exported and imported through binary send 
recv as well.


regards,
Yeb Havinga


--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: [BUGS] BUG #5748: Invalid oidvector data during binary recv

[Yeb Havinga]

On 2010-11-11 17:56, Tom Lane wrote:

Yeb Havinga  writes:

If there is going to be a patch fixing things, the value
'{"1"}'::oidvector[] can't be exported and imported through binary send
recv as well.

That's pilot error, nothing more nor less.  (oidvector != oidvector[])
We're not trying to import the '{"1"}' binary value with oidvectorrecv. 
We hit the error in oidvectorrecv because we binary received an 
oidvector[] (through array_recv), so made an initial test case with an 
oidvector, not oidvector[].


Anyway I now have troubles to make a good test case to trip the lbound 
check. The actual oidvector array that failed was '{"23 23 2275 2281 
23","",2281,26,2275,23,"25 25",701,25,20,1700,"23 23","701 
701",21,700,"1700 1700","603 603","2281 2281","20 20","600 600","718 
718","21 21",1022,"2281 26 2281 23","2281 26 2281 21 2281","17 17","20 
23",602,869,1186,"601"}', but when I test with that now, the non-zero 
lbound value is on a oidvector that also has a zero ndim.


IOW: sorry for the noise, just trying to make a good bug report.

regards,
Yeb Havinga


--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: [BUGS] BUG #5748: Invalid oidvector data during binary recv

[Yeb Havinga]

On 2010-11-11 17:02, Heikki Linnakangas wrote:

On 11.11.2010 17:48, Tom Lane wrote:

"Yeb Havinga"  writes:

postgres=# create table a as select ''::oidvector;
SELECT 1
postgres=# copy a to '/tmp/test' with binary;
COPY 1
postgres=# copy a from '/tmp/test' with binary;
ERROR:  invalid oidvector data


The problem seems to be that array_recv passes back a zero-dimensional
array, *not* a 1-D array, when it observes that the input has no
elements.  A zero-D array is not part of the subset of possible arrays
that we allow for oidvector.


Yeah, I just reached that conclusion too..
The patch below changes array_recv, so that it returns an empty 1-D 
array when an empty 1-D array was written binary. No changes in 
oidvectorrecv or int2vectorrecv are needed.


diff --git a/src/backend/utils/adt/arrayfuncs.c 
b/src/backend/utils/adt/arrayfuncs.c

index 4ceb256..98e725a 100644
--- a/src/backend/utils/adt/arrayfuncs.c
+++ b/src/backend/utils/adt/arrayfuncs.c
@@ -1288,7 +1288,7 @@ array_recv(PG_FUNCTION_ARGS)
my_extra->element_type = element_type;
}

-   if (nitems == 0)
+   if (ndim == 0)
{
/* Return empty array ... but not till we've validated 
element_type */

PG_RETURN_ARRAYTYPE_P(construct_empty_array(element_type));

Make check passes.

regards,
Yeb Havinga


--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: [BUGS] BUG #5748: Invalid oidvector data during binary recv

[Yeb Havinga]

On 2010-11-15 11:40, Heikki Linnakangas wrote:

On 15.11.2010 12:08, Yeb Havinga wrote:

On 2010-11-11 17:02, Heikki Linnakangas wrote:

On 11.11.2010 17:48, Tom Lane wrote:

"Yeb Havinga" writes:

postgres=# create table a as select ''::oidvector;
SELECT 1
postgres=# copy a to '/tmp/test' with binary;
COPY 1
postgres=# copy a from '/tmp/test' with binary;
ERROR: invalid oidvector data


The problem seems to be that array_recv passes back a zero-dimensional
array, *not* a 1-D array, when it observes that the input has no
elements. A zero-D array is not part of the subset of possible arrays
that we allow for oidvector.


Yeah, I just reached that conclusion too..

The patch below changes array_recv, so that it returns an empty 1-D
array when an empty 1-D array was written binary. No changes in
oidvectorrecv or int2vectorrecv are needed.


That seems like a bad idea. array_in() represents an empty array with 
zero dimensions, we're not going to change the generic array_recv() 
function used for all arrays to behave differently because of some 
corner-case in oidvectorrecv.
It's possible to trigger it with any element type, as long as the use 
manages to construct a 1-D array. E.g. with contrib/_int.sql loaded, 
array substraction is possible. Now:

postgres=# select ARRAY[1]::int4[] - ARRAY[1]::int4[];
 ?column?
--
 {}
(1 row)

postgres=# select array_ndims(ARRAY[1]::int4[] - ARRAY[1]::int4[]);
 array_ndims
-
   1
(1 row)

Binary send and recv of the value at hand would change it into a 0-D vector.



If we want do anything about this, the right fix is to add a special 
case in oidvectorrecv/int2vectorrecv to handle empty array.
Judging from the fact that it also happens with int4 arrays, this seems 
like the wrong place.


regards,
Yeb Havinga




--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs