Thread

1. use of dblink_build_sql_insert() induces a server crash

   Rushabh Lathia <rushabh.lathia@gmail.com> — 2010-02-03T12:49:33Z

   Hi All,
   
   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
       This probably means the server terminated abnormally
       before or while processing the request.
   The connection to the server was lost. Attempting reset: Failed.
   
   Version: Latest
   
   Description:  The dblink_build_sql_insert()/get_tuple_of_interest functions
   is not taking care number of attributes in the target.
   
   PFA patch to fix the same.
   
   Thanks,
   Rushabh Lathia
   (www.EnterpriseDB.com)
   

2. Re: use of dblink_build_sql_insert() induces a server crash

   Joe Conway <mail@joeconway.com> — 2010-02-03T17:26:52Z

   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
   
   
   

3. Re: use of dblink_build_sql_insert() induces a server crash

   Joe Conway <mail@joeconway.com> — 2010-02-03T18:08:16Z

   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
   

4. Re: use of dblink_build_sql_insert() induces a server crash

   Tom Lane <tgl@sss.pgh.pa.us> — 2010-02-03T18:18:00Z

   Joe Conway <mail@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
   
   

5. Re: use of dblink_build_sql_insert() induces a server crash

   Joe Conway <mail@joeconway.com> — 2010-02-03T19:39:14Z

   On 02/03/2010 10:18 AM, Tom Lane wrote:
   > Joe Conway <mail@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