On Fri, Jun 22, 2001 at 01:13:50PM +0200, RISKO Gergely wrote:
Hi,
> I continued to port your patch, and now it works,only one error,
You are clever, I knew that is better wait sometime :-)
> So I attach my patch.
I try see it next week. Thanks.
Karel
PS. This sol
Alex Pilosov <[EMAIL PROTECTED]> writes:
> Example, having a statement like 'select count(*) from foo where
> fieldname=$1' where I know that $1 is a stringish type and it _should_ be
> convertable using xxx_in (CString-to-datum conversion functions), however,
> I do not know the precise type (cou
Olivier PRENANT <[EMAIL PROTECTED]> writes:
>> Shouldn't this be handled by the OpenSSL configuration?
> Not yet, opensl-0.9.7 will detect egd. Until then, client has to seed
> prng.
I think we shouldn't patch our code to work around an openssl bug that
will go away soon anyway.
On Thu, Jun 21, 2001 at 02:32:59PM +1000, Joe Shevland wrote:
> I'd certainly be keen on helping out with a Java/Swing approach. It would be
> an excellent test of the meta-data stuff in the JDBC driver and to catch any
> ommissions. I'm willing to provide a homepage etc if wanted (and for some
>
Oleg Bartunov <[EMAIL PROTECTED]> writes:
> I've read that 7.2 release is planned in 2 months.
> Do you have a plan to work with index_formtuple ?
At the moment I'm trying to concentrate on fixing VACUUM.
When that's done, maybe I can spend some time on GIST issues.
regar
Thomas Lockhart <[EMAIL PROTECTED]> writes:
> The description in pg_dump was chosen to assist with a transition in the
> next version of PostgreSQL to having available a true "no time zone"
> timestamp, leaving the current implementation as the "time zone aware"
> type. I'm concerned about changin
Larry Rosenman <[EMAIL PROTECTED]> writes:
> Can one of you knowledgeable people tell me why current CVS as of
> a week ago would have the backend running this query grow to
> 600 meg+?
Sounds like there's still a memory leak in there somewhere, but the
query looks fairly harmless. Could we se
Alex Pilosov <[EMAIL PROTECTED]> writes:
> You usually start out as a user, find out the development environment,
> etc, etc, use it for your project, then you find that there are few things
> about a project that really make you itch. Then you scratch that itch, and
> hopefully send your patch to
Larry Rosenman <[EMAIL PROTECTED]> writes:
> What else?
If you don't want to do the debugger work yourself, could you send me
enough of the data to let me reproduce the problem?
regards, tom lane
---(end of broadcast)---
T
On Wed, 20 Jun 2001, Mike Haberman wrote:
> hello all,
>
> I am using an xml -> sql generator where foreign key are specified
> after the columns are. The sql is written as the xml file is being
> parsed so, the foreign key stuff must be written after the fact.
>
> The problem I need to solve
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> I've been staring at the lock names for an hour now and the best name I've
> come up with is SHARE UPDATE EXCLUSIVE, as in "share update, otherwise
> exclusive" (the implication being that update would allow select as well),
> or some permutation ther
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Strange that even at 1024 performance still drops off at 7. Seems it
> may be more than buffer thrashing.
Yeah, if anything the knee in the curve seems to be worse at 1024
buffers. Curious. Deserves more investigation, perhaps.
This does remind me t
"Bernardo Pons" <[EMAIL PROTECTED]> writes:
> The problem I've found is that the attribute that stores the info about data
> length (attribute atttypmod of catalog table pg_attribute) is some kind of
> internal coding. For example, for an attribute varchar(100) atttypmod value
> is 104; for an att
Bruce Momjian <[EMAIL PROTECTED]> writes:
>> This does remind me that I'd been thinking of suggesting that we
>> raise the default -B to something more reasonable, maybe 1000 or so
>> (yielding an 8-meg-plus shared memory area).
> BSD/OS has a 4MB max but we document how to increase it by recompi
Bruce Momjian <[EMAIL PROTECTED]> writes:
>> Hmm. Anyone like the idea of a platform-specific default established
>> by configure? We could set it in the template file on platforms where
>> the default SHMMAX is too small to allow 1000 buffers.
> Template file seems like a good idea for platfor
Bruce Momjian <[EMAIL PROTECTED]> writes:
>> We could offer a --with switch to manually choose the default, too.
> Good idea, yes. Not sure if we need a --with switch because they can
> just edit the postgresql.conf or postgresql.conf.sample file.
Well, we have a --with switch for DEF_MAXBACKEN
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane writes:
>> This does remind me that I'd been thinking of suggesting that we
>> raise the default -B to something more reasonable, maybe 1000 or so
>> (yielding an 8-meg-plus shared memory area).
> On Modern(tm) systems, 8 MB is just as arbit
Lincoln Yeoh <[EMAIL PROTECTED]> writes:
> Why is SHMMAX so low on some O/Ses?
Historical artifact, I think: the SysV IPC code was developed on
machines that were tiny by current standards. Unfortunately, vendors
haven't stopped to review their kernel parameters and scale them up
appropriately.
18 matches
Mail list logo
