Jonah, you're the man :).
Thank you very much, I tried to solve it for about 2 weeks. I know that few
people in the net have the same problem too.
I simply chanche that line, recompile postgresql and wait for some better
solution.
I know that a lot of people uses DBI-LINK. It simply doesn't work when you
envoking functions(for example make_ancessor or somethink like that) from
remote client like pgAdmin :).
Regards to all
Thank you one more time Jonah.
Dnia 16 marca 2009 17:26 "Jonah H. Harris" <jonah.har...@gmail.com>
napisał(a):
On Mon, Mar 16, 2009 at 11:09 AM, Tomasz Olszak <tols...@o2.pl> wrote:
So it looks like that plperlu function is executing from remote and local
clients with the same set of environment variable.
It has nothing to do with the environment variables.
So I don't have a clue how can I iron out this issue.
Finally, my low-level Oracle knowledge does benefit Postgres :)
It's a TNS parsing error due to a combination of Oracle's use of a Lispish
s-expression-like name-value pair format and Postgres' process listing format
for remote connections.
On connection, the Oracle client sends the current application name to the
Oracle server (which is listed in the V$SESSION view); in the case of Postgres,
the program name is the current backend process name text. Because Oracle
picks up Postgres' backend text, "postgres: www postgres 192.168.1.1(13243)",
the (13243) screws up Oracle's TNS parser which prevents it from resolving the
connection. This doesn't happen when you're connected to PG locally, because
the backend text is, "postgres: www postgres [local]".
The solution to this is to change the following line in
src/backend/postmaster/postmaster.c:
remote_port[0] == '\0' ? "%s" : "%s(%s)"
TO
remote_port[0] == '\0' ? "%s" : "%s[%s]"
OR
remote_port[0] == '\0' ? "%s" : "%s:%s"
Which I would prefer as a nice change to make overall.
--
Jonah H. Harris, Senior DBA
myYearbook.com
