Tom Lane wrote:
Confirmations on other platforms please, anyone?
For anyone else who has problems getting it to compile, try copying
the relevant version of pg_dlopen from src/backend/port/dynloader/. I
attach the code I actually ran on HPUX.
FWIW:
RH9
---
# ./eatallfds libperl.s
> > Attached is the test program I used.
>
> Can folks please try this on other platforms?
[after some minor changes] Can confirm that LoadLibrary (aka dlopen) does
not reduce the files limit under Win32.
Cheers,
Claudio
---
Certain disclaimers and policies apply to all email sent from Memetr
Kevin Brown <[EMAIL PROTECTED]> writes:
> I wasn't able to test on HP-UX
I get the same result on HPUX, after whacking the test program around
a bit: no change in the number of files we can open. Confirmations on
other platforms please, anyone?
For anyone else who has problems getting it to comp
Kevin Brown <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Hmm. This may be OS-specific. The shlibs certainly show up in the
>> output of lsof in every variant I've checked, but do they count against
>> your open-file limit?
> It seems not, for both shared libraries that are linked in at start
Tom Lane wrote:
> Kevin Brown <[EMAIL PROTECTED]> writes:
> > I originally thought that each shared library that was loaded would eat
> > a file descriptor (since I thought it would be implemented via mmap())
> > but that doesn't seem to be the case, at least under Linux
>
> Hmm. This may be OS-s
Scott Goodwin <[EMAIL PROTECTED]> writes:
> I'll grab the CVS PG copy and try it out. Is this something the Darwin
> folks should be notified about? It might cause problems with other
> apps.
It's unlikely that they'll consider it their problem.
regards, tom lane
--
I'll grab the CVS PG copy and try it out. Is this something the Darwin
folks should be notified about? It might cause problems with other
apps.
thanks,
/s.
On Feb 22, 2004, at 4:47 PM, Tom Lane wrote:
Scott Goodwin <[EMAIL PROTECTED]> writes:
Found the problem. If I have a very long environme
Tom Lane wrote:
The core committee has agreed that it's about time to put out new
dot-releases in both the 7.3 and 7.4 branches. (The main thing forcing
this is the realization that permissions checks on view updates were
pretty badly broken by the now-reverted patch of 13-Feb-03 --- this
could b
The core committee has agreed that it's about time to put out new
dot-releases in both the 7.3 and 7.4 branches. (The main thing forcing
this is the realization that permissions checks on view updates were
pretty badly broken by the now-reverted patch of 13-Feb-03 --- this
could be labeled a secur
Scott Goodwin <[EMAIL PROTECTED]> writes:
> Found the problem. If I have a very long environment variable exported
> and I start PG, PG crashes when I try to load PG/Tcl. In my case I use
> color ls and I have a very long LS_COLORS environment variable set.
I was able to duplicate this. I am
One perfectly good reason for this scenario is portability between
postgres and any database implementing the standard (e.g. Oracle).
cheers
andrew
Dave Cramer wrote:
Not to minimize your work, as I think it is great, but this particular
use-case I consider to be overkill for pl/java. It is pr
I'm in Sweden. Some time tuesday evening (european time) perhaps?
Why is your work not made public somewhere? The project on sourceforge is
inactive it seems. Do you have a CVS setup privately?
> Not to minimize your work, as I think it is great, but this particular
> use-case I consider to be ov
I'm certain that the length of a single env var is the only factor
involved, and not the size of the enviroment itself. If I login to my
normal environment and unset LS_COLORS, everything works fine. If I
move my .bashrc out of the way, login fresh and create an env var > 522
chars, it fails. M
FWIW, I have now tested the scheme below, and it appears to work as
expected. I can't see any reason it should disturb any existing
functionality, unless people currently use plperl to store nonlexical
variables which might now clobber each other. I think it's worth doing,
for a small but nontr
Not to minimize your work, as I think it is great, but this particular
use-case I consider to be overkill for pl/java. It is probably easier to
use pl/pgsql if all you want to do is calculations.
We had suggested an online chat to discuss this, when would you be
available for that? What timezone a
> 1) Using JNI, you probably still want to communicate with another
> running java process.
B.T.W. I don't really agree on "probably". There are numerous cases when you
will be happy just communicating with the database, communicate with another
remote resource (message queue typically), or not co
Scott Goodwin <[EMAIL PROTECTED]> writes:
> Found the problem. If I have a very long environment variable exported
> and I start PG, PG crashes when I try to load PG/Tcl. In my case I use
> color ls and I have a very long LS_COLORS environment variable set.
Interesting. Did you check whether
Hi Dave,
Comments on your comments inline...
> What I would like to see is an abstraction of the interface that
> communicates with the JVM so that we can use either, as you have pointed
> out the JNI mechanism has advantages, as does the remote mechanism.
>
Yes, we must agree 100% on the "interf
Kevin Brown <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I'm imagining repeatedly open() until
>> failure at some point during postmaster startup, and then save that
>> result as the number-of-openable-files limit.
> I strongly favor this method. In particular, the probe should probably
> be
Thomas,
What I would like to see is an abstraction of the interface that
communicates with the JVM so that we can use either, as you have pointed
out the JNI mechanism has advantages, as does the remote mechanism.
I recently did an analysis of the two methods and there are a couple of
other poi
20 matches
Mail list logo
