Brent Verner <[EMAIL PROTECTED]> writes:
> (gdb) p *resSlot
> Error accessing memory address 0x40141830: Invalid argument.
Oooh. resSlot has been truncated to 32 bits --- judging by the other
nearby pointer values, it almost certainly should have been 0x140141830.
Now we have a lead.
I am guess
On 24 Dec 2000 at 01:00 (-0500), Tom Lane wrote:
| Brent Verner <[EMAIL PROTECTED]> writes:
| > here's a post-mortem.
|
| > #0 0x1200ce58c in ExecEvalFieldSelect (fselect=0x1401615c0,
| > econtext=0x14016a030, isNull=0x14016ab31 "", isDone=0x0) at execQual.c:1096
|
| Looks reasonable as fa
Brent Verner <[EMAIL PROTECTED]> writes:
> here's a post-mortem.
> #0 0x1200ce58c in ExecEvalFieldSelect (fselect=0x1401615c0,
> econtext=0x14016a030, isNull=0x14016ab31 "", isDone=0x0) at execQual.c:1096
Looks reasonable as far as it goes. Evidently the crash is in the
heap_getattr macro
here's a post-mortem.
#0 0x1200ce58c in ExecEvalFieldSelect (fselect=0x1401615c0,
econtext=0x14016a030, isNull=0x14016ab31 "", isDone=0x0) at execQual.c:1096
#1 0x1200ceafc in ExecEvalExpr (expression=0x1401615f0, econtext=0x0,
isNull=0x14016ab31 "", isDone=0x0) at execQual.c:1234
#2
Tatsuo Ishii <[EMAIL PROTECTED]> writes:
>> I propose we add a new configuration parameter, MAX_FILES_PER_PROCESS,
>> with a default value of about 100. A new backend would set its
>> max-files setting to the smaller of this parameter or
>> sysconf(_SC_OPEN_MAX).
> Seems nice idea. We have been
> Department of Things that Fell Through the Cracks:
>
> Back in August we had concluded that it is a bad idea to trust
> "sysconf(_SC_OPEN_MAX)" as an indicator of how many files each backend
> can safely open. FreeBSD was reported to return 4136, and I have
> since noticed that LinuxPPC return
* Tom Lane <[EMAIL PROTECTED]> [001223 14:16] wrote:
> Department of Things that Fell Through the Cracks:
>
> Back in August we had concluded that it is a bad idea to trust
> "sysconf(_SC_OPEN_MAX)" as an indicator of how many files each backend
> can safely open. FreeBSD was reported to return
> (1) A dbadmin who hasn't read the run-time configuration doc page (that
> you did such a nice job with) is going to have lots of performance
> issues besides this one.
>
> (2) The last thing *I* want to hear is stories of a default Postgres
> installation causing system-wide instability. But i
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Maybe a setting that controls the total number of files that postmaster
> plus backends can allocate among them would be useful.
That'd be nice if we could do it, but I don't see any inexpensive way
to get one backend to release an open FD when anoth
Maybe a setting that controls the total number of files that postmaster
plus backends can allocate among them would be useful. If you have a per
backend setting then that sort of assumes lots of clients with relatively
little usage. Which is probably true in many cases, but not in all.
--
Pete
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane writes:
>> I'm not sure why this didn't get dealt with, but I think it's a "must
>> fix" kind of problem for 7.1. The dbadmin has *got* to be able to
>> limit Postgres' appetite for open file descriptors.
> Use ulimit.
Even if ulimit exist
Tom Lane writes:
> I'm not sure why this didn't get dealt with, but I think it's a "must
> fix" kind of problem for 7.1. The dbadmin has *got* to be able to
> limit Postgres' appetite for open file descriptors.
Use ulimit.
> I propose we add a new configuration parameter, MAX_FILES_PER_PROCESS
Tom Lane wrote:
>
> Department of Things that Fell Through the Cracks:
>
> Back in August we had concluded that it is a bad idea to trust
> "sysconf(_SC_OPEN_MAX)" as an indicator of how many files each backend
> can safely open. FreeBSD was reported to return 4136, and I have
> since noticed t
Department of Things that Fell Through the Cracks:
Back in August we had concluded that it is a bad idea to trust
"sysconf(_SC_OPEN_MAX)" as an indicator of how many files each backend
can safely open. FreeBSD was reported to return 4136, and I have
since noticed that LinuxPPC returns 1024. Bot
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > OK, but does shipping our code with hooks obligate us?
>
> It does not; if RMS thinks it does, he's full of it.
>
> If push actually comes to shove, I'd simply remove the readline hooks,
> but the entire issue is nonsense.
That is my opinion too.
Bruce Momjian <[EMAIL PROTECTED]> writes:
> OK, but does shipping our code with hooks obligate us?
It does not; if RMS thinks it does, he's full of it.
If push actually comes to shove, I'd simply remove the readline hooks,
but the entire issue is nonsense.
regards, tom l
> FreeBSD has a freely available library called 'libedit' that could
> be shipped with postgresql, it's under the BSD license.
Yes, that is our solution if we have a real problem here.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610
* Bruce Momjian <[EMAIL PROTECTED]> [001223 06:59] wrote:
> Rasmus Lerdorf, the big PHP developer, told me that the existance of GNU
> readline hooks in our source tree could cause RMS/GNU to force us to a
> GNU license.
>
> Obviously, we could remove readline hooks and ship a BSD line editing
>
Bruce Momjian wrote:
>
> > Bruce Momjian wrote:
> > >
> > > Rasmus Lerdorf, the big PHP developer, told me that the existance of GNU
> > > readline hooks in our source tree could cause RMS/GNU to force us to a
> > > GNU license.
> > >
> > > Obviously, we could remove readline hooks and ship a BSD
Bruce Momjian wrote:
>
> Rasmus Lerdorf, the big PHP developer, told me that the existance of GNU
> readline hooks in our source tree could cause RMS/GNU to force us to a
> GNU license.
>
> Obviously, we could remove readline hooks and ship a BSD line editing
> library, but does this make any se
On Sat, 23 Dec 2000, Bruce Momjian wrote:
> OK, but does shipping our code with hooks obligate us? We don't ship
> readline.
Oh, oops. I didn't know readline wasn't in the postgres tree. Then,
obviously, distribution of .tar.gz does not obligate postgres to anything,
HOWEVER, the problem arises
> On Sat, 23 Dec 2000, Bruce Momjian wrote:
>
> > Rasmus Lerdorf, the big PHP developer, told me that the existence of GNU
> > readline hooks in our source tree could cause RMS/GNU to force us to a
> > GNU license.
> >
> > Obviously, we could remove readline hooks and ship a BSD line editing
> >
On Sat, 23 Dec 2000, Bruce Momjian wrote:
> Rasmus Lerdorf, the big PHP developer, told me that the existance of GNU
> readline hooks in our source tree could cause RMS/GNU to force us to a
> GNU license.
>
> Obviously, we could remove readline hooks and ship a BSD line editing
> library, but do
> Bruce Momjian writes:
>
> > Rasmus Lerdorf, the big PHP developer, told me that the existance of GNU
> > readline hooks in our source tree could cause RMS/GNU to force us to a
> > GNU license.
>
> This sort of thing is complete nonsense.
>
> By the same logic you could argue that the system("
Bruce Momjian writes:
> Rasmus Lerdorf, the big PHP developer, told me that the existance of GNU
> readline hooks in our source tree could cause RMS/GNU to force us to a
> GNU license.
This sort of thing is complete nonsense.
By the same logic you could argue that the system("cp template1 ...")
Rasmus Lerdorf, the big PHP developer, told me that the existance of GNU
readline hooks in our source tree could cause RMS/GNU to force us to a
GNU license.
Obviously, we could remove readline hooks and ship a BSD line editing
library, but does this make any sense to you? It doesn't make sense t
26 matches
Mail list logo
