Re: [HACKERS] CLUSTER and indisclustered

TER will significantly change the ordering 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 Conw

Re: [HACKERS] FUNC_MAX_ARGS benchmarks

("could not start editor %s\n", editorName); Cheers, Neil -- Neil Conway <[EMAIL PROTECTED]> PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

[HACKERS] encrypted passwords

more complicated. (4) The naming standard for system catalogs would dictate that the 'passwd' field of pg_shadow actually be named 'usepasswd' or something similar, wouldn't it? The same applies to the 'valuntil field. Cheers, Neil -- Neil Conway <[EMAIL P

Re: [HACKERS] Open 7.3 issues

g on this? Not sure we need this for 7.3 -- unless (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

Re: [HACKERS] Standard replication interface?

rate on producing a *really good* replication implementation, which might eventually be integrated into PostgreSQL itself. Producing a "generic API" for something that really doesn't need genericity sounds like a waste of time, IMHO. Cheers, Neil -- Neil Conway

Re: [HACKERS] Standard replication interface?

it, a "generic monitoring API" would be pointless. 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] Standard replication interface?

er than trying to reduce the problem by making it slightly easier 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 usa

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

n if the connection limit is hit (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

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

ction with CPAN, I'm not sure why 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

ata.c: In function `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 -

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

Re: [HACKERS] pg_dump, pg_dumpall and createdb privilege

d in CVS. Databases are now created using CREATE 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

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

nd replication. It's probably worth noting that the "barrier 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/kn

[HACKERS] regression test failures in CVS HEAD

, col8 ddef5 ); + NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index 'defaulttest_pkey' +for table 'defaulttest' insert into defaulttest default values; insert into defaulttest default values; insert into defaulttest default values; == 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

t read. 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: > 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 -- Ne

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

h? This seems to fix the problem: nconway=# select repeat('xxx',1431655765); ERROR: Requested 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,

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

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 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? Go

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

y'); ERROR: Requested length 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

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

[HACKERS] backpatch of datetime fixes

in 7.2 code (I originally found the problem when playing with datetime on 7.3-dev with integer datetimes) -- I've tested it a little bit and it seems to work, but this patch probably requires pretty widespread testing. Cheers, Neil -- Neil Conway <[EMAIL PROTECTED]> || PGP Key ID: DB3

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

nly a limited amount that I can do. I think we should make 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 a

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

ranoia to another 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/p

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

Neil Conway <[EMAIL PROTECTED]> writes: > Sir Mordred The Traitor <[EMAIL PROTECTED]> writes: > > There exists a buffer overflow in a SET TIME ZONE command, that > > allows an attacker to execute malicious code. > > Here's a patch for the problem. I al

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. > > &

Re: [HACKERS] Build failure in current CVS

ckend/utils/mb/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 PROTECTE

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

Bruce Momjian <[EMAIL PROTECTED]> writes: > Tom Lane wrote: > > Neil Conway <[EMAIL PROTECTED]> writes: > > > The handling of the TZ environmental variable is subject to a buffer > > > overrun. > > > > This problem is long gone in current sou

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

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&#x

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

ode yet, it's probably worth noting that the two test cases posted above 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

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

e will hopefully be an FE/BE protocol 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 --

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

upport any > longer? Nope, exactly the same 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] @(#)Mordre Labs advisory 0x0005: Several buffer overruns in PostgreSQL

t; detect a buffer overrun condition caused by a very long argument. I 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]

Re: [HACKERS] [Resend] Sprintf() auditing and a patch

hat causes regression tests to fail won't be accepted (period), you may as well run them now, rather now later. > > At least I didn't just bitch and moan about the bugs. ;) Thank you; frankly, I wish your attitude was more common. Cheers, Neil -- Neil Conway <[EMAIL PROTECTED]> || PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

[HACKERS] tweaking MemSet() performance

mset() / MemSet() performance when copying word-aligned amounts of memory? If so, what's a good value for MEMSET_LOOP_LIMIT (perhaps 512)? Also, if anyone would like to contribute the results of doing the benchmark on their particular system, that might provide some useful additional dat

Re: [HACKERS] #ifdef MULTIBYTE removed

BYTE #define be removed from src/include/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 "

Re: [HACKERS] Beta1 schedule

ht have just missed 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] Optimization levels when compiling PostgreSQL...

seems both unwarranted, and potentially dangerous. If -O3 is a good 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 -

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

d development snapshot 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: subscri

Re: [HACKERS] genetic algorithm in PostgreSQL

probably read: http://citeseer.nj.nec.com/bennett91genetic.html http://citeseer.nj.nec.com/stillger96genetic.html If you're unfamiliar with database query optimization itself, I found this to be a good survey of the field: http://citeseer.nj.nec.com/371707.html Cheers, Neil -- Neil Con

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

ces the number of people who will be willing to try it out -- so 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

Re: [HACKERS] Optimizer generates bad plans.

t that may not be true 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: DB3C29

Re: [HACKERS] DROP COLUMN misbehaviour with multiple inheritance

e beta1 anyway due to the casting changes, right? (not to mention the split -> split_part change). 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: DB3C2

[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 *** ./exp

Re: [HACKERS] PGXLOG variable worthwhile?

t just vote, they provided reasons why they thought the feature was brain-damaged -- reasons which have 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 c

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 worki

[HACKERS] making use of large TLB pages

ect the SysV IPC API 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 PR

Re: [HACKERS] Web site

one of the mirror sites (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

Re: [HACKERS] pltcl.so patch

buffers (snprintf() rather than sprintf(), and so on). I also didn't include Nigel's 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/p

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 &

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

(~50%) than ext3-writeback, which was in turn significantly faster (~25%) than ext3-ordered. > Also, though ext3 is slower, turning fsync off should make ext3 function > similar to ext2. Why would that be? Cheers, Neil -- Neil Conway <[EMAIL PROTECTED]>

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

anything to disk. ISTM that the performance advantage of ext2 over ext3 is should be even larger 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

Re: [HACKERS] making use of large TLB pages

make one of these syscalls. If it fails, fall back to the SysV stuff. Does that sound reasonable? Any other comments would 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] making use of large TLB pages

//lwn.net/Articles/6535/ http://lwn.net/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 ---

Re: [HACKERS] making use of large TLB pages

east worth implementing -- if it doesn't 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. --

Re: [HACKERS] making use of large TLB pages

have no idea if that will translate into an 8% performance gain for PostgreSQL, or whether the performance gain only 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. Ho

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

nor improvements that could be made. You could also try implementing bitmap indexes, or improving GEQO (the genetic-algorithm based query optimizer). HTH, Neil -- Neil Conway <[EMAIL PROTECTED]> || PGP Key ID: DB3C29FC ---(end of broadcast)---

Re: [HACKERS] floor function in 7.3b2

ting discussion -- but is there a reason why we 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: D

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

ntinue with what it was doing, and at some later time 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: DB3C29F

Re: [HACKERS] Moving to PostGres

an define functions in Java 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, a

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

a user-space implementation for a little 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,

Re: [HACKERS] Hot Backup

current 7.3 beta(2) release. AFAIK no such 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 ---(e

Re: [HACKERS] pg_dump file question

CREATE DATABASE ... WITH OWNER. However, I'm not sure if there are other, similar problems that haven't been fixed yet. 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] Dirty Buffer Writing [was Proposed LogWriter Scheme]

w & interesting features for database systems in the new kernel -- I'm looking 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] [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 &g

Re: [HACKERS] Open items

f what the final conclusion was... > Add 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 extensi

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

Postmasters use seperate > communication 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 Conwa

[HACKERS] PL/Perl and Perl 5.8

m like the right fix, 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 --

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 configu

Re: [HACKERS] PREPARE / EXECUTE

arel implemented), but ultimately decided 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: D

Re: [HACKERS] PL/Perl and Perl 5.8

king around the bug. IMHO, yes -- 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

ach function 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] Memory leaks

some reason) -- add '-DPS_USE_NONE -UPS_USE_CLOBBER_ARGV' 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

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

Re: [HACKERS] PL/Perl and Perl 5.8

t_struct; #endif #endif /* 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)---

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

eproc.y > preproc.y:5560: fatal error: maximum table size (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] 7.2.3 vacuum bug

M a; client 1: 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 --

Re: [HACKERS] 7.2.3 vacuum bug

age than what appears when the table wasn't found 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

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)-

[HACKERS] protocol change in 7.4

of the discussion relating to this is fuzzy). 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

Re: [HACKERS] protocol change in 7.4

ort in 7.4, and we'd 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:

Re: [HACKERS] a tiny question

emory contention What do you 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] protocol change in 7.4

el for communications between backends 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?

in the channel. I talked to lilo about getting 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 g

Re: [HACKERS] PL/Perl and Perl 5.8

rsion (which presumably 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 appro

Re: [HACKERS] PL/Perl and Perl 5.8

o the stable branch, but the Perl maintainers are aware 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

Re: [HACKERS] a tiny question

"Luis Alberto Amigo Navarro" <[EMAIL PROTECTED]> writes: > Is there a way to set more than one shared regions? No, there isn't. Cheers, Neil -- Neil Conway <[EMAIL PROTECTED]> || PGP Key ID: DB3C29FC ---(end of broadcast)

Re: [HACKERS] Win32 port

r how quickly they are put out. It's also possible that a faster release cycle would mean a more rushed, less stable development process (and therefore more bugs). Cheers, Neil -- Neil Conway <[EMAIL PROTECTED]> || PGP Key ID: DB3C29FC ---(end o

Re: [HACKERS] Outstanding patches

g voiced about this (by Peter?), 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 Conw

Re: [HACKERS] [GENERAL] Database replication... - Mission Critica

ical databases at the end. > > This is wrong assumption. Agreed. Another simple example is: INSERT INTO foo VALUES (random()); Cheers, Neil -- Neil Conway <[EMAIL PROTECTED]> || PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP

[HACKERS] PL/PgSQL buglet / doc error

nconway=# select test_func(); test_func --- (1 row) Should this be implemented, or should the assertion that 'RETURN is optional' be removed from the docs? Cheers, Neil -- Neil Conway <[EMAIL PROTECTED]> || PGP Key ID: DB3C29FC ---(end of br

Re: [HACKERS] PL/PgSQL buglet / doc error

Stephan Szabo <[EMAIL PROTECTED]> writes: > On 7 Nov 2002, Neil Conway wrote: > > If you have declared the function to return void, then the expression > > can be omitted, and will be ignored in any case. > > I'm not sure how you translated the above to return is

Re: [HACKERS] Outstanding patches

s been submitted to Bruce. I'm fine with it being committed as is (as you suggest), or waiting until there is more substantial work done on the topic. Cheers, Neil -- Neil Conway <[EMAIL PROTECTED]> || PGP Key ID: DB3C29FC ---(end of broadcast)-

Re: [HACKERS] CREATE TABLE/AS does not allow WITH OIDS?

; in the case of multiple source tables, or a source table defined by an SRF? Unless we can define some consistent semantics for when we use the hasoids of the source table(s), I'd say we should just add the WITH/WITHOUT OIDS syntax. Cheers, Neil -- Neil Conway <[EMAIL PR

Re: [HACKERS] Outstanding patches

Yes, I'll implement the rest of the SQL200x sequence stuff eventually. However, if you'd rather wait for me to finish it all and then commit it at that point, that's fine with me. Cheers, Neil -- Neil Conway <[EMAIL PROTECTED]> || PGP Key ID: DB3C29FC

Re: [HACKERS] [GENERAL] Database replication... - Mission Critica

hat about if the different postgres servers in the cluster > run on different architectures! That way you'd get different floating point > results on each machine... IMHO, that falls into the category of: "Dr., it hurts when I do this!" -- "Well, don&

Re: [HACKERS] [GENERAL] command

"Shridhar Daithankar" <[EMAIL PROTECTED]> writes: > On 8 Nov 2002 at 11:03, Florian Litot wrote: > > yes it's good but can i have the date with each line? > > Err.. I don't think so. Try the log_timestamp GUC option. Cheers, Neil -- Neil Conway &l

Re: [HACKERS] An article mentioning PostgreSQL

http://www.gnuenterprise.org/ 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

<    1   2   3   4   5   6   7   8   9   10   >