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(dot)harris(at)gmail(dot)com> napisał(a):
On Mon, Mar 16, 2009 at 11:09 AM, Tomasz Olszak <tolszak(at)o2(dot)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