[HACKERS] Mixing threaded and non-threaded

(I hope this is -hackers appropriate - feel free to point me elsewhere) I'm using 7.4.1 as the backend to several applications. Until recently, I've been developing solely single-threaded applications. I just rebuilt postgresql with --enable-thread-safety, to work with some multi-threaded code.

VACUUM delay (was Re: [HACKERS] What's planned for 7.5?)

Christopher Browne <[EMAIL PROTECTED]> writes: > "Stephen" <[EMAIL PROTECTED]> writes: >> Any chance we'll see the VACUUM delay patch (throttle) get into 7.5? > The hope, in 7.5, is to have ARC, which is the "super-duper-duper" > version, working. Actually, I'm not sure that ARC should be conside

Re: [HACKERS] What's planned for 7.5?

"Stephen" <[EMAIL PROTECTED]> writes: > Any chance we'll see the VACUUM delay patch (throttle) get into 7.5? I only > had the chance to try the first patch by Tom Lane and it was very good > already. I was hoping it gets into 7.4.1 but it didn't. :-( > > I really need the VACUUM delay patch because

Re: [HACKERS] failed to re-find parent key

Dave Cramer <[EMAIL PROTECTED]> writes: > Actually the hack checks for oids, and doesn't make the index, if there > isn't an oid in the table, so I tried it with a table without oids, and > it still occurs. My thought was that at this point the indexes on pg_attribute are very possibly corrupt, an

Re: [HACKERS] failed to re-find parent key

On Tue, 2004-01-13 at 21:16, Tom Lane wrote: > Dave Cramer <[EMAIL PROTECTED]> writes: > > I can't recreate it either, it is only happening on my customers > > machines, which are using an older version of redhat (7.2) and gcc 2.96 > > > Is it possible these versions are relevant to the issue? >

Re: [HACKERS] failed to re-find parent key

Tom Lane <[EMAIL PROTECTED]> writes: > Hmm. Compiler bug maybe? I can't recall if gcc 2.96 had a good > reputation or not. 2.96's reputation is of being *THE* canonical bad version of gcc. mplayer for example has a configure check that specifically makes it difficult to compile with 2.96 wi

Re: [HACKERS] failed to re-find parent key

Dave Cramer <[EMAIL PROTECTED]> writes: > I can't recreate it either, it is only happening on my customers > machines, which are using an older version of redhat (7.2) and gcc 2.96 > Is it possible these versions are relevant to the issue? Hmm. Compiler bug maybe? I can't recall if gcc 2.96 had

Re: [HACKERS] Adding a data type

Hi Dann, On Jan 14, 2004, at 10:22 AM, Dann Corbit wrote: What is the correct outline of the procedure for adding a data type to PostgreSQL? Did you take a look here? It's a good place to start. Cheers, Michael Glaesemann

Re: [HACKERS] failed to re-find parent key

I can't recreate it either, it is only happening on my customers machines, which are using an older version of redhat (7.2) and gcc 2.96 Is it possible these versions are relevant to the issue? Dave On Tue, 2004-01-13 at 19:05, Tom Lane wrote: > Dave Cramer <[EMAIL PROTECTED]> writes: > > Sorry

[HACKERS] Adding a data type

Title: Message What is the correct outline of the procedure for adding a data type to PostgreSQL?  

Re: [HACKERS] failed to re-find parent key

Dave Cramer <[EMAIL PROTECTED]> writes: > Sorry folks, this is a red-herring, my hack didn't have anything to do > with it. In that case you could provide a self-contained example? I tried this a few times in the regression database: select * into temp a from tenk1; drop table a; and saw no pro

Re: [HACKERS] [pgsql-hackers-win32] Win32 signal code - first try

> IMO, it's time for a second run of the code, and a functional test which > simulates the command processing loop which should include: > > 1. setjmp/longjmp stack manipulation (i.e. ELOG) > 2. in process/out of process generates signals > 3. all thread mechanisms. Definitely. Magnus, I assume

Re: [HACKERS] LWLock/ShmemIndex startup question

> Tom Lane said: > > > > Actually, I was expecting you to complain that the s_lock.h coding is > > gcc-specific. Which compilers do we need to support on Windows? > > > > AFAIK the only target build environment for Windows right now is > MinGW/gcc Yes, I'm working with MingW. > If anyone kno

Re: [HACKERS] failed to re-find parent key

Sorry folks, this is a red-herring, my hack didn't have anything to do with it. It occurs with or without the index. Question is was there a bug between 7.4 and 7.4.1 which may have caused this? Dave On Tue, 2004-01-13 at 16:30, Dave Cramer wrote: > I have hacked analyze.c to automatically create

[HACKERS] failed to re-find parent key

I have hacked analyze.c to automatically create a unique index on the oid when a table is created and I am getting the failed to re-find parent key in pg_attribute_relid_attnam_index every 8 attempts to do the following select * from foo into temp a; drop table a; Currently analyze does not creat

Re: [HACKERS] Suggestions for analyze patch required...

"Mark Cave-Ayland" <[EMAIL PROTECTED]> writes: > I agree that the custom function needs an input as to the number of rows > used for analysis, but I think that this is determined by the > application in question. It may be that while the existing algorithm is > fine for the existing data types, it

Re: [HACKERS] Suggestions for analyze patch required...

Hi Tom, Thanks for your criticism on this. > -Original Message- > From: Tom Lane [mailto:[EMAIL PROTECTED] > Sent: 11 January 2004 17:04 > To: Mark Cave-Ayland > Cc: [EMAIL PROTECTED] > Subject: Re: [HACKERS] Suggestions for analyze patch required... > > > "Mark Cave-Ayland" <[EMAIL P

Re: [HACKERS] LWLock/ShmemIndex startup question

Tom Lane wrote: Manfred Spraul <[EMAIL PROTECTED]> writes: What are the chances for Win64 support? sizeof(unsigned long) remains 4, sizeof(void*) is 8. If you can tell me what type Datum should be (unsigned long long maybe?), we could probably handle that. Probably uintptr_t: That's the o

Re: [HACKERS] LWLock/ShmemIndex startup question

Manfred Spraul <[EMAIL PROTECTED]> writes: > What are the chances for Win64 support? sizeof(unsigned long) remains 4, > sizeof(void*) is 8. If you can tell me what type Datum should be (unsigned long long maybe?), we could probably handle that. It was a pretty brain-dead combination of choices o

Re: [HACKERS] LWLock/ShmemIndex startup question

Tom Lane said: > > Actually, I was expecting you to complain that the s_lock.h coding is > gcc-specific. Which compilers do we need to support on Windows? > AFAIK the only target build environment for Windows right now is MinGW/gcc If anyone knows how to get the M$ compilers to work nicely with

Re: [HACKERS] LWLock/ShmemIndex startup question

Tom Lane wrote: Claudio Natoli <[EMAIL PROTECTED]> writes: Or, maybe we'll just use the tas() implementation that already exists for __i386__/__x86_64__ in s_lock.h. How did I miss that? Move along. Nothing to see here. Actually, I was expecting you to complain that the s_lock.h coding is

Re: [HACKERS] LWLock/ShmemIndex startup question

Claudio Natoli <[EMAIL PROTECTED]> writes: > Or, maybe we'll just use the tas() implementation that already exists for > __i386__/__x86_64__ in s_lock.h. How did I miss that? > Move along. Nothing to see here. Actually, I was expecting you to complain that the s_lock.h coding is gcc-specific. Whi

Re: [HACKERS] [pgsql-hackers-win32] Win32 signal code - first try

Claudio Natoli wrote: > FWIW, in a multithreaded version of postgres I'm fooling around with, I > replaced the recv call (where backends spend most of their time waiting) > which a select(small timeout)/SleepEx(0) "busy" loop, which calls to recv > when ready. Works just fine. Ok, that makes perfe

Re: [HACKERS] LWLock/ShmemIndex startup question

Claudio Natoli <[EMAIL PROTECTED]> writes: > FWIW, I've done a code walk-through, and it looks ok (lack of real-world > testing notwithstanding), and actually does use the Win32 sema set. The only > real problem is that it calls ShmemInitStruct in semget, which ultimately > gets us into bootstrap h

Re: [HACKERS] Encoding problems in PostgreSQL with XML data

Merlin Moncure kirjutas E, 12.01.2004 kell 19:56: > Hannu Krosing wrote: > > IIRC, the charset transformations are done as a separate step in the > > wire protocol _before_ any parser has chance transform or not. > > Yep. My point is that this is wrong. Of course :) It seems to be a quick hac

Re: [HACKERS] LWLock/ShmemIndex startup question

> Ok, I think having a native win32 spin-lock implementation > (say, based on InterlockedCompareExchange?) is the minimal > impact answer. I'll work on producing that. Or, maybe we'll just use the tas() implementation that already exists for __i386__/__x86_64__ in s_lock.h. How did I miss that?

Re: [HACKERS] Reserved words and named function parameters

Any opinions which to do, or alternate proposals? I'm leaning slightly to #2, since I doubt anyone is trying to use "IN" as a function name, but ... One addition. The information_schema.parameters view will need to be updated to reflect parameter names. http://www.postgresql.org/docs/7.4/static