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

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



---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

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

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

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



---------------------------(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

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

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

Ü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

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. +

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

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. +

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Add to TODO:

* Have /contrib/dblink reuse unnamed connections

http://archives.postgresql.org/pgsql...0/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. +

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers