Thread: dblink un-named connection doesn't get re-used
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
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. +