dblink un-named connection doesn't get re-used

Sorry for the self-reply...

On Oct 18, 2007, at 9:09 AM, Decibel! wrote:

Is it intentional that dblink's unnamed connections don't get re-used?

From the dblink docs (both 8.1 and HEAD):

if only one argument is given, the connection is unnamed; only
one unnamed
connection can exist at a time

So this sounds to me like a bug.
--
Decibel!, aka Jim C. Nasby, Database Architect decibel@decibel.org
Give your computer some brain candy! www.distributed.net Team #1828

Decibel! wrote:

Is it intentional that dblink's unnamed connections don't get re-used?

yes

stats=# select dblink_connect('dbname=stats');
dblink_connect
----------------
OK
(1 row)

stats=# select dblink_connect('dbname=postgres');
dblink_connect
----------------
OK
(1 row)

AFAIK there's no way I could possibly use or refer to the connection to
stats at this point; so why doesn't dblink close it when I issue the
second connect?

Why doesn't C free allocated memory automatically if you reassign a pointer?

No one has ever complained before, so I can't imagine that the resource
leak is much of an issue in real world cases. But if you don't like the
behavior, patches are gratefully accepted ;-).

Seriously though, I can change it for 8.3, but is it really worth
back-patching?

Joe

On Oct 18, 2007, at 11:17 PM, Joe Conway wrote:

Decibel! wrote:

Is it intentional that dblink's unnamed connections don't get re-
used?

yes

stats=# select dblink_connect('dbname=stats');
dblink_connect
----------------
OK
(1 row)
stats=# select dblink_connect('dbname=postgres');
dblink_connect
----------------
OK
(1 row)

AFAIK there's no way I could possibly use or refer to the
connection to stats at this point; so why doesn't dblink close it
when I issue the second connect?

Why doesn't C free allocated memory automatically if you reassign a
pointer?

No one has ever complained before, so I can't imagine that the
resource leak is much of an issue in real world cases. But if you
don't like the behavior, patches are gratefully accepted ;-).

Seriously though, I can change it for 8.3, but is it really worth
back-patching?

I think it'd be worth changing for 8.3. While C forces you to worry
about memory, SQL does not, so I bet this is a surprise to most folks.

It might be worth backpatching the docs, because they're wrong.
--
Decibel!, aka Jim C. Nasby, Database Architect decibel@decibel.org
Give your computer some brain candy! www.distributed.net Team #1828

Decibel! wrote:

On Oct 18, 2007, at 11:17 PM, Joe Conway wrote:

Seriously though, I can change it for 8.3, but is it really worth
back-patching?

I think it'd be worth changing for 8.3. While C forces you to worry
about memory, SQL does not, so I bet this is a surprise to most folks.

I don't think anyone has ever noticed -- certainly not enough to
complain in the past 5 years. This behavior has been the same since day
one. I don't mind changing it, but I don't see it as a big deal.

It might be worth backpatching the docs, because they're wrong.

How so? Please provide better wording if you don't like what it
currently says. Simply saying it is wrong is unhelpful.

Joe

Ühel kenal päeval, R, 2007-10-19 kell 15:42, kirjutas Joe Conway:

Decibel! wrote:

On Oct 18, 2007, at 11:17 PM, Joe Conway wrote:

Seriously though, I can change it for 8.3, but is it really worth
back-patching?

I think it'd be worth changing for 8.3. While C forces you to worry
about memory, SQL does not, so I bet this is a surprise to most folks.

I don't think anyone has ever noticed -- certainly not enough to
complain in the past 5 years. This behavior has been the same since day
one. I don't mind changing it, but I don't see it as a big deal.

Most likely nobody ever uses un-named connection beyond initial testing.

--------------
Hannu

This has been saved for the 8.4 release:

http://momjian.postgresql.org/cgi-bin/pgpatches_hold

---------------------------------------------------------------------------

Hannu Krosing wrote:

?hel kenal p?eval, R, 2007-10-19 kell 15:42, kirjutas Joe Conway:

Decibel! wrote:

On Oct 18, 2007, at 11:17 PM, Joe Conway wrote:

Seriously though, I can change it for 8.3, but is it really worth
back-patching?

I think it'd be worth changing for 8.3. While C forces you to worry
about memory, SQL does not, so I bet this is a surprise to most folks.

I don't think anyone has ever noticed -- certainly not enough to
complain in the past 5 years. This behavior has been the same since day
one. I don't mind changing it, but I don't see it as a big deal.

Most likely nobody ever uses un-named connection beyond initial testing.

--------------
Hannu

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://postgres.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

This has been saved for the 8.4 release:

http://momjian.postgresql.org/cgi-bin/pgpatches_hold

---------------------------------------------------------------------------

Decibel! wrote:

Is it intentional that dblink's unnamed connections don't get re-used?

stats=# select datname, usename from pg_stat_activity;
datname | usename
---------+---------
stats | decibel
(1 row)

stats=# select dblink_connect('dbname=stats');
dblink_connect
----------------
OK
(1 row)

stats=# select dblink_connect('dbname=postgres');
dblink_connect
----------------
OK
(1 row)

stats=# select datname, usename from pg_stat_activity;
datname | usename
----------+----------
stats | decibel
stats | postgres
postgres | postgres
(3 rows)

AFAIK there's no way I could possibly use or refer to the connection
to stats at this point; so why doesn't dblink close it when I issue
the second connect?
--
Decibel!, aka Jim C. Nasby, Database Architect decibel@decibel.org
Give your computer some brain candy! www.distributed.net Team #1828

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://postgres.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Add to TODO:

* Have /contrib/dblink reuse unnamed connections

http://archives.postgresql.org/pgsql-hackers/2007-10/msg00895.php

---------------------------------------------------------------------------

Decibel! wrote:

Is it intentional that dblink's unnamed connections don't get re-used?

stats=# select datname, usename from pg_stat_activity;
datname | usename
---------+---------
stats | decibel
(1 row)

stats=# select dblink_connect('dbname=stats');
dblink_connect
----------------
OK
(1 row)

stats=# select dblink_connect('dbname=postgres');
dblink_connect
----------------
OK
(1 row)

stats=# select datname, usename from pg_stat_activity;
datname | usename
----------+----------
stats | decibel
stats | postgres
postgres | postgres
(3 rows)

AFAIK there's no way I could possibly use or refer to the connection
to stats at this point; so why doesn't dblink close it when I issue
the second connect?
--
Decibel!, aka Jim C. Nasby, Database Architect decibel@decibel.org
Give your computer some brain candy! www.distributed.net Team #1828

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://postgres.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +