Re: [BUGS] BUG #5487: dblink failed with 63 bytes connection names - Mailing list pgsql-hackers

From Takahiro Itagaki
Subject Re: [BUGS] BUG #5487: dblink failed with 63 bytes connection names
Date
Msg-id 20100601115511.95D2.52131E4D@oss.ntt.co.jp
Whole thread Raw
Responses Re: [BUGS] BUG #5487: dblink failed with 63 bytes connection names  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
List pgsql-hackers
"Takahiro Itagaki" <itagaki.takahiro@oss.ntt.co.jp> wrote:

> Bug reference:      5487
> Logged by:          Takahiro Itagaki
> Email address:      itagaki.takahiro@oss.ntt.co.jp
> Description:        dblink failed with 63 bytes connection names
> Details:
>
> Contib/dblink module seems to have a bug in handling
> connection names in NAMEDATALEN-1 bytes.

Here is a patch to fix the bug. I think it comes from wrong usage
of snprintf(NAMEDATALEN - 1). It just copies 62 bytes + \0.

In addition, it should be safe to use pg_mbcliplen() to truncate
extra bytes in connection names because we might return invalid
text when a multibyte character is at 62 or 63 bytes.

Note that the fix should be ported to previous versions, too.


> It cannot use exiting connections with 63 bytes name
> in some cases. For example, we cannot disconnect
> such connections. Also, we can reconnect with the
> same name and will have two connections with the name.
>
> =# SELECT dblink_connect(repeat('1234567890', 6) || 'ABC',
> 'host=localhost');
>  dblink_connect
> ----------------
>  OK
> (1 row)
>
> =# SELECT dblink_get_connections();
>                       dblink_get_connections
> -------------------------------------------------------------------
>  {123456789012345678901234567890123456789012345678901234567890ABC}
> (1 row)
>
> =# SELECT dblink_disconnect(repeat('1234567890', 6) || 'ABC');
> ERROR:  connection
> "123456789012345678901234567890123456789012345678901234567890ABC" not
> available

Regards,
---
Takahiro Itagaki
NTT Open Source Software Center


Attachment

pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: functional call named notation clashes with SQL feature
Next
From: Giles Lean
Date:
Subject: Re: is_absolute_path incorrect on Windows