use of dblink_build_sql_insert() induces a server crash
in [PgSql]
|
Prev: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
Next: [HACKERS] Partial Page Writes documentaiton mention
From: Joe Conway on 3 Feb 2010 12:26 On 02/03/2010 04:49 AM, Rushabh Lathia wrote: > Testcase: > > create table foo (a int ); > postgres=# SELECT dblink_build_sql_insert('foo','1 2',2,'{\"0\", > \"a\"}','{\"99\", \"xyz\"}'); > HINT: Use the escape string syntax for escapes, e.g., E'\r\n'. > server closed the connection unexpectedly Thanks for the report -- will have a look later today. Joe
From: Joe Conway on 3 Feb 2010 13:08 On 02/03/2010 04:49 AM, Rushabh Lathia wrote: > > create table foo (a int ); > postgres=# SELECT dblink_build_sql_insert('foo','1 2',2,'{\"0\", > \"a\"}','{\"99\", \"xyz\"}'); > HINT: Use the escape string syntax for escapes, e.g., E'\r\n'. > server closed the connection unexpectedly The problem exists with all three dblink_build_sql_* functions. Here is a more complete patch. If there are no objections I'll apply this to HEAD and look at back-patching -- these functions have hardly been touched since inception. Joe
From: Tom Lane on 3 Feb 2010 13:18 Joe Conway <mail(a)joeconway.com> writes: > The problem exists with all three dblink_build_sql_* functions. Here is > a more complete patch. If there are no objections I'll apply this to > HEAD and look at back-patching -- these functions have hardly been > touched since inception. Do you really need to copy the relation tupdesc when you only are going to make a one-time check of the number of attributes? This coding would make some sense if you intended to use the tupdesc again later in the functions, but it appears you don't. Also, what about cases where the relation contains dropped columns --- it's not obvious whether this test is correct in that case. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Joe Conway on 3 Feb 2010 14:39
On 02/03/2010 10:18 AM, Tom Lane wrote: > Joe Conway <mail(a)joeconway.com> writes: >> The problem exists with all three dblink_build_sql_* functions. Here is >> a more complete patch. If there are no objections I'll apply this to >> HEAD and look at back-patching -- these functions have hardly been >> touched since inception. > > Do you really need to copy the relation tupdesc when you only are going > to make a one-time check of the number of attributes? This coding would > make some sense if you intended to use the tupdesc again later in the > functions, but it appears you don't. > > Also, what about cases where the relation contains dropped columns --- > it's not obvious whether this test is correct in that case. Good input, as always. Here's another whack at it. Thanks, Joe |