Re: [HACKERS] Outstanding patches

?), and I'm not sure we resolved them. Last I heard, we had concluded that SQL2003's notion of a sequence is sufficiently close to ours that the differences are mostly syntax. (Note that SQL99 does not define sequences.) Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC

Re: [HACKERS] a tiny question

mean by memory contention? Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org

Re: [HACKERS] PL/Perl and Perl 5.8

satisfies Tom's objections). It should probably be in RC1... Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail

Re: [HACKERS] PL/Perl and Perl 5.8

of it, at any rate, and may have fixed it in the interim. Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org

[HACKERS] protocol change in 7.4

). The rest is up for grabs. Finally, how should we manage the transition? I wasn't around for the earlier protocol changes, so I'd appreciate any input on steps we can take to improve backward-compatibility. Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC

Re: [HACKERS] protocol change in 7.4

need a protocol change to do it properly, AFAICS. IIRC, Peter E. expressed some interest in doing this... Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go

Re: [HACKERS] protocol change in 7.4

on different nodes). Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster

Re: [HACKERS] PostgreSQL IRC Channel... who's the Admin?

Bruce ops, and he talked to Bruce about it. Not sure what came out of that... Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command

Re: [HACKERS] 7.2.3 vacuum bug

: COMMIT; Now, client 2 will receive RelationClearRelation: relation 25172 deleted while still in use, rather than Relation a does not exist, as you might expect. Not sure if it's the same bug, or just a different problem... Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC

Re: [HACKERS] 7.2.3 vacuum bug

at all. Ok, fair enough -- I agree that we should treat the two cases differently. But one thing I think we should do in any case is improve the wording of the error message. Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(end of broadcast

Re: [HACKERS] CVS TOT fails to build on MacOSX 10.2.1

(32767) exceeded You need bison 1.50 or greater to build the new ecpg (due to a bison limitation). Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster

Re: [HACKERS] Request for supported platforms

Bruce Momjian [EMAIL PROTECTED] writes: Ports list updated: Shouldn't the join regression test failure be fixed? Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 5: Have you checked our

Re: [HACKERS] PREPARE / EXECUTE

to remove. IMHO, the utility of this feature doesn't justify the problems that would come with implementing it (see the archives for the original implementation discussions). Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(end of broadcast

Re: [HACKERS] Memory leaks

' to CFLAGS. I mentioned it to the author of valgrind, but IIRC he didn't mention any plans to change this behavior. Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 5: Have you checked our

Re: [HACKERS] Open items

Bruce Momjian [EMAIL PROTECTED] writes: Michael, please use bison 1.75 to update ecpg Why is this necessary? AFAIK we don't keep bison-derived files in CVS... Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(end of broadcast

Re: [HACKERS] PL/Perl and Perl 5.8

-- but what do other people think? -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster

[HACKERS] compile error in CVS HEAD

it appears in.) make[3]: *** [copy.o] Error 1 Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org

Re: [HACKERS] PL/Perl and Perl 5.8

/* HAS_CRYPT_R */ The crypt_data struct is defined in crypt.h, but only if _GNU_SOURCE is defined -- just like crypt_r(). Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 2: you can get off all lists

[HACKERS] PL/Perl and Perl 5.8

, though. Does anyone have any comments on how to fix this properly? Regardless of the solution we choose, I think this needs to be fixed before 7.3 is released. Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(end of broadcast

Re: [HACKERS] PL/Perl and Perl 5.8

Tom Lane [EMAIL PROTECTED] writes: Neil Conway [EMAIL PROTECTED] writes: As of current CVS, PL/Perl doesn't seem to compile against Perl 5.8. Builds fine on HPUX 10.20 with Perl 5.8.0 and gcc 2.95.3. It may also depend on the way Perl is configured. I've attached the output of 'perl -V

Re: [HACKERS] Peer to peer replication of Postgresql databases

channels for each. One is the sequencial channel which carries writes whose order is important, and the non-sequencial channel carries write queries whose order is not important. How do you distinguish between these? Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC

Re: [HACKERS] [PATCHES] inline newNode()

Gavin Sherry [EMAIL PROTECTED] writes: On 10 Oct 2002, Neil Conway wrote: Compiled with '-DBUFFER_SIZE=256 -O2', I get the following results in seconds: MemSet(): ~9.6 memset(): ~19.5 __builtin_memset(): ~10.00 I ran the same code. I do not understand the results you go

Re: [HACKERS] Open items

schema dump option to pg_dump Why do we need this for 7.3? Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs

Re: [HACKERS] pg_dump file question

-- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])

Re: [HACKERS] Moving to PostGres

using http://pljava.sf.net , or in a variety of other languages (Perl, Python, Tcl, Ruby, C, PL/PgSQL, SQL, sh, etc.) 2. How well is JAva supported for developing DB applications using PG? Pretty well, I guess. If you have a specific question, ask it. Cheers, Neil -- Neil Conway [EMAIL

Re: [HACKERS] Proposed LogWriter Scheme, WAS: Potential Large

while (although I'd guess the performance to be unimpressive), so AIO would not be *that* kernel-version specific. Anyone have any idea of Red Hat's Advanced Server uses KAIO or what? RH AS uses Ben LaHaise's implemention of AIO, I believe. Cheers, Neil -- Neil Conway [EMAIL PROTECTED

Re: [HACKERS] Hot Backup

feature has been implemented for 7.3 -- you appear to have been misinformed. That said, I agree that would be a good feature to have. Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 2: you can

Re: [HACKERS] Dirty Buffer Writing [was Proposed LogWriter Scheme]

forward to when 2.6 is widely deployed... Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster

Re: [HACKERS] floor function in 7.3b2

can't cast from float8 - numeric implicitely? IIRC the idea was to allow implicit casts from lower precision types to higher precision ones. Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 2: you can

Re: [HACKERS] Potential Large Performance Gain in WAL synching

the blocks that we flushed from the Postgres buffer will actually be written to disk. So in some sense of the word, that I/O is asynchronous. Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 4

Re: [HACKERS] Advice: Where could I be of help?

bitmap indexes, or improving GEQO (the genetic-algorithm based query optimizer). HTH, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org

Re: [HACKERS] making use of large TLB pages

provide a noticeable performance improvement, then we don't need to merge it. Cheers, Neil [1] It's worth noting that the huge tlb patch currently works in IA64, SPARC, and may well be ported to additional architectures in the future. -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC

Re: [HACKERS] making use of large TLB pages

applies if you're using a machine with 16GB of RAM, or whether the speedup from large pages is really just a correction of some Oracle deficiency that we don't suffer from, etc. However, I do think it's worth finding out. Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC

Re: [HACKERS] making use of large TLB pages

/Articles/10293/ Is it a lot of code? I haven't implemented it yet, so I'm not sure. However, I don't think it will be a lot of code. Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 6: Have

Re: [HACKERS] making use of large TLB pages

be appreciated. Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster

Re: [HACKERS] [GENERAL] Performance while loading data and indexing

when fsync is not enabled. Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org

Re: [HACKERS] [GENERAL] Performance while loading data and indexing

Greg Copeland [EMAIL PROTECTED] writes: On Thu, 2002-09-26 at 16:03, Neil Conway wrote: I'm not really familiar with the reasoning behind ext2's reputation as recovering poorly from crashes; if we fsync a WAL record to disk before we lose power, can't we recover reliably, even with ext2

Re: [HACKERS] making use of large TLB pages

Tom Lane [EMAIL PROTECTED] writes: Neil Conway [EMAIL PROTECTED] writes: I'd like to enable PostgreSQL to use large TLB pages, if the OS and processor support them. Hmm ... it seems interesting, but I'm hesitant to do a lot of work to support something that's only available on one

[HACKERS] making use of large TLB pages

to support (e.g. telling the # of clients attached to a given segment). Can anyone comment on exactly what functionality we expect when dealing with the storage mechanism of the shared buffer? Any comments would be appreciated. Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC

Re: [HACKERS] Web site

(AFAIK) have ads on them? Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so

Re: [HACKERS] pltcl.so patch

changes to some apparently unrelated PL/Python stuff -- this patch includes only the PL/Tcl changes. Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC Index: src/pl/tcl/pltcl.c === RCS file: /var/lib/cvs/pgsql

Re: [HACKERS] Temp tables and LRU-K caching

Tom Lane [EMAIL PROTECTED] writes: No, we never heard back from that guy. It is still a live topic though. One of the Red Hat people was looking at it over the summer, and I think Neil Conway is experimenting with LRU-2 code right now. Just to confirm that, I'm working on this, and hope

Re: [HACKERS] PGXLOG variable worthwhile?

not be persuasively refuted, IMHO. If you'd like to see this feature in the code, might I suggest that you spend less time complaining about gate keepers (hint: it's called code review), and more time explaining exactly why the feature is worth having? Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID

[HACKERS] regression test failure in CVS HEAD

It seems the 'numeric' and 'int8' tests are failing in CVS HEAD. The culprit seems to be the recent to_char() change made by Karel, but I haven't verified that. The diff follows. Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC *** ./expected/int8.out Fri Jan 26 17:50:26

Re: [HACKERS] Optimizer generates bad plans.

universally. I thought someone might be interested in a test case for the optimizer. Thanks, it's a useful query -- I've been meaning to take a look at GEQO for a while now... Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(end

Re: [HACKERS] DROP COLUMN misbehaviour with multiple inheritance

). If that's the case, I don't see a good reason not to include the fix, provided it's reasonably low-risk. Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL

Re: Beta2 on Friday Morning (Was: Re: [HACKERS] Open 7.3 items)

initdb's between betas are not disasterous, but should be avoided if possible. Since waiting till next week significantly reduces the chance of an initdb for beta3 and has no serious disadvantage that I can see, it seems the right decision to me. Cheers, Neil -- Neil Conway [EMAIL PROTECTED

Re: [HACKERS] Optimization levels when compiling PostgreSQL...

idea, we should make the change for the appropriate platforms in the official source, and let it get the widespread testing it requires. Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 2: you can

Re: [HACKERS] Optimization levels when compiling PostgreSQL...

to a current snapshot would still be non-trivial, significantly reducing the usefulness of snapshots, IMHO. Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL

Re: [HACKERS] Beta1 schedule

that. Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [HACKERS] #ifdef MULTIBYTE removed

/pg_config.h.in ? Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])

Re: [HACKERS] @(#)Mordre Labs advisory 0x0005: Several buffer overruns in PostgreSQL

wasn't able to reproduce either of these (wouldn't it require an input string with several hundred thousand commas?), can you give me a test-case? Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC Index: src/backend/utils/adt/geo_ops.c

Re: [HACKERS] C vs. C++ contributions

change during the 7.4 development cycle, which should give you the opportunity to make any protocol-level changes required to implement this properly. Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP

Re: [HACKERS] [PATCHES] fix for palloc() of user-supplied length

thought crossed my mind while I was reading through the code... Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [HACKERS] @(#)Mordred Labs advisory 0x0006: Two minor DoS conditions in PostgreSQL

are not cut-and-dry DoS opportunities, AFAICT -- however, the code may still be vulnerable. Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [HACKERS] @(#)Mordred Labs advisory 0x0002: Buffer overflow in PostgreSQL

routine that uses a statically sized buffer. Thanks for the report. Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC Index: src/backend/commands/variable.c === RCS file: /var/lib/cvs/pgsql-server/src/backend

Re: [HACKERS] @(#)Mordred Labs advisory 0x0003: Buffer overflow in PostgreSQL (fwd)

Neil Conway [EMAIL PROTECTED] writes: Tom Lane [EMAIL PROTECTED] writes: Vince Vielhaber [EMAIL PROTECTED] writes: Here's yet another. He claims malicious code can be run on the server with this one. regression=# select repeat('xxx',1431655765); server closed the connection

Re: [HACKERS] Build failure in current CVS

/conversion_procs/ascii_and_mic' Makefile:1: *** missing separator. Stop. make[4]: Leaving directory `/home/nconway/pgsql/src/backend/utils/mb/conversion_procs/ascii_and_mic' make[3]: *** [all] Error 2 Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(end

Re: [HACKERS] @(#)Mordred Labs advisory 0x0002: Buffer overflow in PostgreSQL

Bruce Momjian [EMAIL PROTECTED] writes: What would you like done with the patch you submitted? I'd like to see it applied to CVS HEAD and REL7_2_STABLE. Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(end of broadcast

Re: [HACKERS] @(#)Mordred Labs advisory 0x0002: Buffer overflow in PostgreSQL

Neil Conway [EMAIL PROTECTED] writes: Bruce Momjian [EMAIL PROTECTED] writes: What would you like done with the patch you submitted? I'd like to see it applied to CVS HEAD and REL7_2_STABLE. Uh, sorry -- wrote that without thinking. I'd like to see the patch applied to REL7_2_STABLE. I'll

Re: [HACKERS] @(#)Mordred Labs advisory 0x0003: Buffer overflow in PostgreSQL (fwd)

buffer is too large. It uses the logic you suggested. Just a quick and dirty fix, I may have missed something... The patch applies cleanly to both CVS HEAD and the 7.2 stable branch. Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC Index: src/backend/utils/adt

Re: [HACKERS] @(#)Mordred Labs advisory 0x0003: Buffer overflow in PostgreSQL (fwd)

-- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [HACKERS] @(#)Mordred Labs advisory 0x0003: Buffer overflow in PostgreSQL (fwd)

Tom Lane [EMAIL PROTECTED] writes: Neil Conway [EMAIL PROTECTED] writes: + /* Check for integer overflow */ + if (tlen / slen != count) + elog(ERROR, Requested buffer is too large.); What about slen == 0? Good point -- that wouldn't cause incorrect results or a security

Re: [HACKERS] @(#)Mordred Labs advisory 0x0004: Multiple buffer overflows in PostgreSQL. (fwd)

too large test=# select rpad('x',1431655765,''); ERROR: Requested length too large (That's on a Unicode DB, haven't tested other encodings but AFAICT this fix should still work.) Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC Index: src/backend/utils

Re: [HACKERS] @(#)Mordred Labs advisory 0x0004: Multiple buffer overflows in PostgreSQL. (fwd)

Vince Vielhaber [EMAIL PROTECTED] writes: On 20 Aug 2002, Neil Conway wrote: Is there any chance that pg_database_encoding_max_length() could return zero and give a divide by zero error? Or is that trapped? I don't think so (the array of encodings that contains the data seems to be pre

Re: [HACKERS] @(#)Mordred Labs advisory 0x0003: Buffer overflow in

a 7.2.2 release, and to that end I've posted patches against REL7_2_STABLE for all four of the security holes. The rest of the work that goes into making a release needs to be done by others (Marc, Vince, Bruce, etc.) -- if there's anything I can do to help, let me know. Cheers, Neil -- Neil

Re: [HACKERS] pg_dump, pg_dumpall and createdb privilege

DATABASE xxx WITH OWNER yyy: this technique can also be used by the DBA in the first place, avoiding the need to manually add and then remove CREATEDB privs from the new user account. Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(end of broadcast

Re: [HACKERS] @(#) Mordred Labs advisory 0x0001: Buffer overflow in

to entry for fixing buffer overruns or doing a code audit is much, much lower than for implementing advanced features like schemas or replication. The main thing that auditing code requires is time, rather than coding skill/knowledge. Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID

[HACKERS] regression test failures in CVS HEAD

; == Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster

Re: [HACKERS] @(#) Mordred Labs advisory 0x0001: Buffer overflow in

Dann Corbit [EMAIL PROTECTED] writes: If you *know* of a buffer overrun, and simply decide not to fix it, that sounds very negligent to me. *sigh*, no one is doing that, and it is pure negligence on your part for replying to a thread that you clearly have not read. Cheers, Neil -- Neil

Re: [HACKERS] @(#) Mordred Labs advisory 0x0001: Buffer overflow in

Dann Corbit [EMAIL PROTECTED] writes: I read (in some other message) that this buffer overrun problem has been known for a very, very long time. No, the problem you're referring to (cash_out() and friends) is *not* a buffer overrun. Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key

Re: Removing Libraries (Was: Re: [HACKERS] Open 7.3 issues)

you'd like to move the software to GBorg... Cheers, Neil -- Neil Conway [EMAIL PROTECTED] PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html

[HACKERS] compile warnings in CVS

`main': pg_controldata.c:91: warning: `%c' yields only last 2 digits of year in some locales pg_controldata.c:93: warning: `%c' yields only last 2 digits of year in some locales Cheers, Neil -- Neil Conway [EMAIL PROTECTED] PGP Key ID: DB3C29FC ---(end of broadcast

Re: [HACKERS] compile warnings in CVS

Neil Conway [EMAIL PROTECTED] writes: I get the following compiling the current CVS code with gcc 3.1: I also get 4 regression test failures, due to Gavin's improvements to the parser error messages. AFAICT no actual problems, the expected error message strings just needed to be updated

Re: [HACKERS] Standard replication interface?

for the different replication solutions to inter-operate, I think it's a better idea to solve the problem outright by improving one of the existing replication projects to the point at which it is ready for widespread production usage. Cheers, Neil -- Neil Conway [EMAIL PROTECTED] PGP Key ID: DB3C29FC

Re: [HACKERS] Admin nice-to-have's

(although I'm not sure it's worth the worry, when 'kill a backend executing SELECT ; psql template1 postgres' works as-is). Cheers, Neil -- Neil Conway [EMAIL PROTECTED] PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 3: if posting/reading through

Re: [HACKERS] Open 7.3 issues

(a) someone steps up to do the work (b) there is some consensus on the design, I don't have a problem with letting this wait for 7.4 Allow PL/PgSQL functions to return sets Is anyone working on this? I am. It should be ready in time for 7.3. Cheers, Neil -- Neil Conway [EMAIL PROTECTED] PGP

Re: [HACKERS] FUNC_MAX_ARGS benchmarks

-- Neil Conway [EMAIL PROTECTED] PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [HACKERS] IRIX and large SMP: donations of shells c

access on a system with 6 cpus (SGI Challenge L, R4400's). As I indicated in IRC, I'd be interested in the use of that machine. If that's okay, can you send me the auth info via email? You can find my GPG key on keyserver.net. Cheers, Neil -- Neil Conway [EMAIL PROTECTED] PGP Key ID: DB3C29FC

Re: [HACKERS] CLUSTER and indisclustered

of the data in the table, which isn't always the case -- which is another reason why make this automatic seems unwarranted, IMHO). It seems like you're looking for a solution to a non-existent problem. Cheers, Neil -- Neil Conway [EMAIL PROTECTED] PGP Key ID: DB3C29FC

Re: [HACKERS] getpid() function

-in functions to provide information to the user -- so there will be an increasing need for some kind of naming convention for built-in functions. However, establishing a naming convention without breaking backwards compatibility might be tricky. Cheers, Neil -- Neil Conway [EMAIL PROTECTED] PGP Key

Re: [HACKERS] Trimming the Fat: Getting code via CVSup ...

/interfaces libpqxx *default prefix=/var/lib/cvs/pgsql/contrib earthdistance Replacing 'pgsql' with 'pgsql-server' yields a 'no such module' warning message and the module is skipped. Cheers, Neil -- Neil Conway [EMAIL PROTECTED] PGP Key ID: DB3C29FC ---(end of broadcast

Re: [HACKERS] getpid() function

to have a naming convention for builtin functions, what about builtin types? 'pg_int4', anyone? :-) Cheers, Neil -- Neil Conway [EMAIL PROTECTED] PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http

[HACKERS] FUNC_MAX_ARGS benchmarks

idle, and all other PostgreSQL settings were at their default values. With FUNC_MAX_ARGS=16: 28.832 28.609 28.726 28.680 (average = 28.6 seconds) With FUNC_MAX_ARGS=32: 29.097 29.337 29.138 28.985 29.231 (average = 29.15 seconds) Cheers, Neil -- Neil Conway [EMAIL PROTECTED] PGP Key ID

Re: Trim the Fat (Was: Re: [HACKERS] Open 7.3 items )

language interfaces (for languages like Python, where several interfaces exist, this would probably be a good idea anyway). Cheers, Neil -- Neil Conway [EMAIL PROTECTED] PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 3: if posting/reading through

Re: [HACKERS] Open 7.3 items

these during the beta cycle? Cheers, Neil -- Neil Conway [EMAIL PROTECTED] PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message

Re: [HACKERS] Open 7.3 items

which design we're going to implement. Given that it's pretty esoteric, I'd prefer this wait for 7.4 Cheers, Neil -- Neil Conway [EMAIL PROTECTED] PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http

Re: [HACKERS] Open 7.3 items

for FUNC_MAX_ARGS, effectively doubling both. If we're going to change NAMEDATALEN, we should probably set it to 128, as that's what SQL99 requires. Cheers, Neil -- Neil Conway [EMAIL PROTECTED] PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 5

Re: [HACKERS] Open 7.3 items

? Also, what happens if I enable the GUC var, create a bunch of different users/databases, and then disable it again? Cheers, Neil -- Neil Conway [EMAIL PROTECTED] PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster

Re: [HACKERS] Open 7.3 items

before I enabled the GUC var, how does authentication work? Cheers, Neil -- Neil Conway [EMAIL PROTECTED] PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs

Re: [HACKERS] Password sub-process ...

not make any sense... Cheers, Neil -- Neil Conway [EMAIL PROTECTED] PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org

Re: [HACKERS] Why is MySQL more chosen over PostgreSQL?

to include inheritance. I'd say removing inheritence would be a waste of time -- it would probably be easier to just fix its deficiencies. Cheers, Neil -- Neil Conway [EMAIL PROTECTED] PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 2: you can get off

Re: [HACKERS] getpid() function

()', or 'unix_pid', or 'backend_pid()'. Also, can you add some documentation on this? Cheers, Neil -- Neil Conway [EMAIL PROTECTED] PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users

Re: [HACKERS] getpid() function

- Misc. Functions. I don't think it belongs in the monitoring section, since it isn't part of the stats collector and isn't really used for monitoring. Cheers, Neil -- Neil Conway [EMAIL PROTECTED] PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 5

Re: [HACKERS] question on backends

it. At the moment, a backend connects to a single database for its entire lifecycle -- so you'd either need one pool of persistent backends for each database in use, or you'd need to allow a backend to change the database it is connected to. Cheers, Neil -- Neil Conway [EMAIL PROTECTED] PGP Key

[HACKERS] sub-selects in CHECK

appreciate a more informed assessment... Thanks in advance, Neil -- Neil Conway [EMAIL PROTECTED] PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere

Re: [HACKERS] bug in COPY

On Wed, Jul 24, 2002 at 04:23:56PM -0400, Tom Lane wrote: [EMAIL PROTECTED] (Neil Conway) writes: This behavior doesn't look right: It's not, but I believe the correct point of view is that the input data is defective and should be rejected. See past discussions leading up to the TODO

[HACKERS] regression in CVS HEAD

to be the spurious comma in the dumped CREATE TYPE statement, and I think it was introduced by Peter E.'s recent checkin. Cheers, Neil -- Neil Conway [EMAIL PROTECTED] PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 3: if posting/reading through Usenet

Re: [HACKERS] [PATCHES] prepareable statements

calls on a syntactical level, which I think is okay.) Cheers, Neil -- Neil Conway [EMAIL PROTECTED] PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL

[HACKERS] regression in CVS HEAD

:759 #13 0x0815745a in PostgresMain (argc=9, argv=0x827b388, username=0x827b9f0 nconway) at postgres.c:1924 #14 0x081070cd in main (argc=9, argv=0xb9a4) at main.c:229 Can someone fix this please? Cheers, Neil -- Neil Conway [EMAIL PROTECTED] PGP Key ID: DB3C29FC

<    5   6   7   8   9   10   11   >