Re: [HACKERS] [COMMITTERS] pgsql: Stamp major release 8.3.0,

2007-01-12 Thread Joachim Wieland
On Fri, Jan 12, 2007 at 01:45:10AM +0100, Chris Mair wrote: I just wanted to mention that the latest release of OpenBSD i386 (4.0) is still broken too. So the ecpg-check failure would apply to (at least) to 3.8, 4.0, and likely 3.9. ok, but then we have some hosts in the buildfarm that run the

Re: [HACKERS] [COMMITTERS] pgsql: Stamp major release 8.3.0,

2007-01-12 Thread Stefan Kaltenbrunner
Joachim Wieland wrote: On Fri, Jan 12, 2007 at 01:45:10AM +0100, Chris Mair wrote: I just wanted to mention that the latest release of OpenBSD i386 (4.0) is still broken too. So the ecpg-check failure would apply to (at least) to 3.8, 4.0, and likely 3.9. ok, but then we have some hosts in

Re: [HACKERS] [COMMITTERS] pgsql: Stamp major release 8.3.0,

2007-01-12 Thread Chris Mair
On Fri, 12 Jan 2007 10:09:34 +0100 Joachim Wieland [EMAIL PROTECTED] wrote: On Fri, Jan 12, 2007 at 09:29:36AM +0100, Stefan Kaltenbrunner wrote: ok, but then we have some hosts in the buildfarm that run the updated versions like zebra and spoonbill. In this case we can't decide on the OS

Re: [HACKERS] [GENERAL] Checkpoint request failed on version 8.2.1.

2007-01-12 Thread Zeugswetter Andreas ADI SD
I find it very unlikely that you would during normal operations end up in a situation where you would first have permissions to create files in a directory, and then lose them. What could be is that you have a directory where you never had permissions to create the file in the first

Re: [HACKERS] share info between backends

2007-01-12 Thread Zeugswetter Andreas ADI SD
comments? Why not make it probabilistic by using, say, MyProcPid % n where n is the number of tablespaces? Then you don't need anything shared. You still want a (local) counter, so that temp files for one session are spread out. Andreas ---(end of

Re: [HACKERS] Problem linking libecpg.5.3.dylib on OS X

2007-01-12 Thread Michael Meskes
On Thu, Jan 11, 2007 at 10:47:32PM -0500, Tom Lane wrote: Actually I'd suggest that using an exported variable at all is probably bad style. I'd suggest that libecpg export a set() function instead: ... I think I found an easier solution. With my latest commit ecpg uses a #define to set a

Re: [HACKERS] [COMMITTERS] pgsql: Stamp major release 8.3.0,

2007-01-12 Thread Michael Meskes
On Fri, Jan 12, 2007 at 01:20:15AM +0100, Joachim Wieland wrote: Attached is a patch to get guppy green again (hopefully). Applied. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL

Re: [HACKERS] O_DIRECT, or madvise and/or posix_fadvise

2007-01-12 Thread Martijn van Oosterhout
On Thu, Jan 11, 2007 at 02:35:13PM -0800, [EMAIL PROTECTED] wrote: I caught this thread about O_DIRECT on kerneltrap.org: http://kerneltrap.org/node/7563 It sounds like there is much to be gained here in terms of reducing the number of user/kernel space copies in the operating system. I

[HACKERS] to_char not IMMUTABLE?

2007-01-12 Thread Mario Weilguni
I had a problem when upgrading a database from 8.1.4 to 8.2.1: Sorry, the error messages are in german. pg_restore: [archiver (db)] Error while PROCESSING TOC: pg_restore: [archiver (db)] Error from TOC entry 1531; 1259 3477393 INDEX idx_inspektionen_dat_inspektion pg_restore: [archiver (db)]

Re: [HACKERS] share info between backends

2007-01-12 Thread Andrew Dunstan
Zeugswetter Andreas ADI SD wrote: comments? Why not make it probabilistic by using, say, MyProcPid % n where n is the number of tablespaces? Then you don't need anything shared. You still want a (local) counter, so that temp files for one session are spread out. Yes, but this can

Re: [HACKERS] to_char not IMMUTABLE?

2007-01-12 Thread Martijn van Oosterhout
On Fri, Jan 12, 2007 at 11:55:07AM +0100, Mario Weilguni wrote: to_char(timestamp, '') should be constant and marked immutable, or am I wrong here? Or is it not marked immutable because of possible changes on date_format? AIUI, to_char is not immutable because it can be effected by

Re: [HACKERS] [COMMITTERS] pgsql: Stamp major release 8.3.0,

2007-01-12 Thread Tom Lane
Joachim Wieland [EMAIL PROTECTED] writes: Attached patch enables the special expected files only for i386-unknown-openbsd3.8. This seems the wrong approach; we do not have anywhere near that good a handle on which platforms have this behavior. I'd vote for treating it like a locale difference,

Re: [HACKERS] to_char not IMMUTABLE?

2007-01-12 Thread Mario Weilguni
Am Freitag, 12. Januar 2007 14:48 schrieb Martijn van Oosterhout: On Fri, Jan 12, 2007 at 11:55:07AM +0100, Mario Weilguni wrote: to_char(timestamp, '') should be constant and marked immutable, or am I wrong here? Or is it not marked immutable because of possible changes on date_format?

Re: [HACKERS] [GENERAL] Checkpoint request failed on version 8.2.1.

2007-01-12 Thread Magnus Hagander
On Fri, Jan 12, 2007 at 10:49:53AM +0100, Zeugswetter Andreas ADI SD wrote: I find it very unlikely that you would during normal operations end up in a situation where you would first have permissions to create files in a directory, and then lose them. What could be is that you

Re: [HACKERS] [GENERAL] Checkpoint request failed on version 8.2.1.

2007-01-12 Thread Magnus Hagander
On Thu, Jan 11, 2007 at 10:39:47PM -0500, Tom Lane wrote: Jim C. Nasby [EMAIL PROTECTED] writes: On Thu, Jan 11, 2007 at 03:14:37PM -0500, Tom Lane wrote: ... And anyway there should never *be* a real permissions problem; if there is then the user's been poking under the hood sufficient

Re: [HACKERS] [GENERAL] Checkpoint request failed on version 8.2.1.

2007-01-12 Thread Tom Lane
Zeugswetter Andreas ADI SD [EMAIL PROTECTED] writes: It seems the win unlink is not implemented correctly and we need to replace it. Easier said than done ... regards, tom lane ---(end of broadcast)--- TIP 3: Have you

Re: [HACKERS] to_char not IMMUTABLE?

2007-01-12 Thread Tom Lane
Mario Weilguni [EMAIL PROTECTED] writes: Thanks for the info. Changing this to use extract is no real problem, I was just curious if this is intendend behaviour. From the CVS logs: 2006-11-28 14:18 tgl * src/include/catalog/: pg_proc.h (REL7_3_STABLE), pg_proc.h

Re: [HACKERS] to_char not IMMUTABLE?

2007-01-12 Thread Albe Laurenz
Mario Weilguni wrote: I had a problem when upgrading a database from 8.1.4 to 8.2.1: Sorry, the error messages are in german. pg_restore: [archiver (db)] Error while PROCESSING TOC: pg_restore: [archiver (db)] Error from TOC entry 1531; 1259 3477393 INDEX idx_inspektionen_dat_inspektion

Re: [HACKERS] [COMMITTERS] pgsql: Stamp major release 8.3.0,

2007-01-12 Thread Chris Mair
Attached is a patch to get guppy green again (hopefully). The two new files go into src/interfaces/ecpg/test/expected Hi, I just wanted to mention that the latest release of OpenBSD i386 (4.0) is still broken too. So the ecpg-check failure would apply to (at least) to 3.8, 4.0, and likely

Re: [HACKERS] [GENERAL] Checkpoint request failed on version 8.2.1.

2007-01-12 Thread Tom Lane
Magnus Hagander [EMAIL PROTECTED] writes: On Thu, Jan 11, 2007 at 10:39:47PM -0500, Tom Lane wrote: One point worth making is that I'm not really convinced anymore that we have proof that antivirus code has been creating any such problems. We do. I have positive proof of this being caused by

Re: [HACKERS] SPAR Simple PostgreSQL AddOn Replication System

2007-01-12 Thread Jonah H. Harris
On 1/11/07, Gurjeet Singh [EMAIL PROTECTED] wrote: Also, the sources are not available. Do you plan to make the sources available? -- Jonah H. Harris, Software Architect | phone: 732.331.1324 EnterpriseDB Corporation| fax: 732.331.1301 33 Wood Ave S, 3rd Floor| [EMAIL

Re: [HACKERS] [COMMITTERS] pgsql: Stamp major release 8.3.0,

2007-01-12 Thread Stefan Kaltenbrunner
Tom Lane wrote: Joachim Wieland [EMAIL PROTECTED] writes: Attached patch enables the special expected files only for i386-unknown-openbsd3.8. This seems the wrong approach; we do not have anywhere near that good a handle on which platforms have this behavior. I'd vote for treating it like

Re: [HACKERS] [GENERAL] Checkpoint request failed on version 8.2.1.

2007-01-12 Thread Zeugswetter Andreas ADI SD
I wrote: I find it very unlikely that you would during normal operations end up in a situation where you would first have permissions to create files in a directory, and then lose them. What could be is that you have a directory where you never had permissions to create the file in

Re: [HACKERS] [GENERAL] Checkpoint request failed on version 8.2.1.

2007-01-12 Thread Magnus Hagander
On Fri, Jan 12, 2007 at 09:47:55AM -0500, Tom Lane wrote: Magnus Hagander [EMAIL PROTECTED] writes: On Thu, Jan 11, 2007 at 10:39:47PM -0500, Tom Lane wrote: One point worth making is that I'm not really convinced anymore that we have proof that antivirus code has been creating any such

Re: [HACKERS] Request for review: tsearch2 patch

2007-01-12 Thread Teodor Sigaev
Yeah, it's a workaround. Since there's no concept other than alpha/numeric/latin in tsearch2, Asian characters have to be fall in one of them. Ok, I see. Pls, test attached patch - if it is good then I'll commit it at Monday to HEAD and 8.2 branches. PS. Magnus, may I ask you to test under

Re: [HACKERS] [GENERAL] Checkpoint request failed on version 8.2.1.

2007-01-12 Thread Tom Lane
Magnus Hagander [EMAIL PROTECTED] writes: On Fri, Jan 12, 2007 at 09:47:55AM -0500, Tom Lane wrote: No, I didn't claim that Windows AV software is bug-free ;-). What I said was that I'm not certain it's related to the permission denied reports, as opposed to other problems. Or are your stack

Re: [HACKERS] copy table from file: with row replacement?

2007-01-12 Thread Bruce Momjian
Michael Enke wrote: Hello all, I have a feature request as I think it is not possible with the actual version: I want to load huge amount of data and I know that COPY is much faster than doing inserts. But in my case I have an already filled table and rows (not all, only partly) from

Re: [HACKERS] [GENERAL] Checkpoint request failed on version 8.2.1.

2007-01-12 Thread Magnus Hagander
Tom Lane wrote: Magnus Hagander [EMAIL PROTECTED] writes: On Fri, Jan 12, 2007 at 09:47:55AM -0500, Tom Lane wrote: No, I didn't claim that Windows AV software is bug-free ;-). What I said was that I'm not certain it's related to the permission denied reports, as opposed to other problems.

Re: [HACKERS] [GENERAL] Checkpoint request failed on version 8.2.1.

2007-01-12 Thread Tom Lane
Magnus Hagander [EMAIL PROTECTED] writes: Tom Lane wrote: Actually, it could still be the same problem, with the AV software only involved to the extent that it's trying to scan files for viruses. Partially the same, but I've seen AV software keeping it open for hours... Basically until

Re: [HACKERS] ideas for auto-processing patches

2007-01-12 Thread markwkm
On 1/11/07, Andrew Dunstan [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: I am not clear about what is being proposed. Currently buildfarm syncs against (or pulls a fresh copy from, depending on configuration) either the main anoncvs repo or a mirror (which you can get using cvsup or

Re: [HACKERS] ideas for auto-processing patches

2007-01-12 Thread Andrew Dunstan
[EMAIL PROTECTED] wrote: What do you think about setting up the buildfarm clients with the users they are willing to test patches for, as opposed to having the patch system track who is are trusted users? My thoughts are the former is easier to implement and that it allows anyone to use the

Re: [HACKERS] [GENERAL] Checkpoint request failed on version 8.2.1.

2007-01-12 Thread Magnus Hagander
Tom Lane wrote: Magnus Hagander [EMAIL PROTECTED] writes: Tom Lane wrote: Actually, it could still be the same problem, with the AV software only involved to the extent that it's trying to scan files for viruses. Partially the same, but I've seen AV software keeping it open for hours...

Re: [HACKERS] [GENERAL] Checkpoint request failed on version 8.2.1.

2007-01-12 Thread Tom Lane
Magnus Hagander [EMAIL PROTECTED] writes: Tom Lane wrote: pg_control is certainly not ever deleted or renamed, and in fact I believe there's an LWLock enforcing that only one PG process at a time is even touching it. So we need another theory to explain this one :-( Right. What we need is a

[HACKERS] Idea for fixing the Windows fsync problem

2007-01-12 Thread Tom Lane
I just had a thought about fixing those Windows permission denied problems. The case that we believe we understand is where the bgwriter is trying to execute a previously-logged fsync request against a table file that is pending delete --- that is, actually has been unlink()'d, but some other

Re: [HACKERS] SPAR Simple PostgreSQL AddOn Replication System

2007-01-12 Thread Gurjeet Singh
On 1/12/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hi Gurjeet glad you copied me, else would have missed it no longer subscribed. I also almost missed your mail. I was monitoring just the conversation (gmail) that I sent you mail in, but since you changed the subject, it almost

Re: [HACKERS] [COMMITTERS] pgsql: Stamp major release 8.3.0,

2007-01-12 Thread Magnus Hagander
Joachim Wieland wrote: On Thu, Jan 11, 2007 at 01:15:56PM +0100, Magnus Hagander wrote: Can't comment on that one, since I just noticed it existed. How similar was this one to the standard regression tests? Those were moved into a C executable so they'd run on a Windows system without a shell,

Re: [HACKERS] [GENERAL] Autovacuum Improvements

2007-01-12 Thread Simon Riggs
On Fri, 2006-12-29 at 20:25 -0300, Alvaro Herrera wrote: Christopher Browne wrote: Seems to me that you could get ~80% of the way by having the simplest 2 queue implementation, where tables with size some threshold get thrown at the little table queue, and tables above that size go to

Re: [HACKERS] O_DIRECT, or madvise and/or posix_fadvise

2007-01-12 Thread markwkm
On 1/12/07, Martijn van Oosterhout kleptog@svana.org wrote: On Thu, Jan 11, 2007 at 02:35:13PM -0800, [EMAIL PROTECTED] wrote: I caught this thread about O_DIRECT on kerneltrap.org: http://kerneltrap.org/node/7563 It sounds like there is much to be gained here in terms of reducing the

[HACKERS] TODO items for removal

2007-01-12 Thread Simon Riggs
These two items are complete in 8.2, IIRC Allow constraint_exclusion to work for UNIONs like it does for inheritance, allow it to work for UPDATE and DELETE statements, and allow it to be used for all statements with little performance impact Fix memory leak from exceptions

Re: [HACKERS] [GENERAL] Autovacuum Improvements

2007-01-12 Thread Simon Riggs
On Fri, 2007-01-12 at 19:33 -0300, Alvaro Herrera wrote: Alvaro, have you completed your design? No, I haven't, and the part that's missing is precisely the queues stuff. I think I've been delaying posting it for too long, and that is harmful because it makes other people waste time

Re: [HACKERS] [GENERAL] Checkpoint request failed on version 8.2.1.

2007-01-12 Thread Jim C. Nasby
On Thu, Jan 11, 2007 at 06:04:56PM -0500, Andrew Dunstan wrote: Please don't. At least not on the PostgreSQL web site nor in the docs. And no, I don't run my production servers on Windows either. For good or ill, we made a decision years ago to do a proper Windows port. I think that it's

Re: [HACKERS] copy table from file: with row replacement?

2007-01-12 Thread Michael Enke
This works for small amount of data. But for large amount of data the join takes a lot of time. Regards, Michael Bruce Momjian wrote: Michael Enke wrote: Hello all, I have a feature request as I think it is not possible with the actual version: I want to load huge amount of data and I know

Re: [HACKERS] copy table from file: with row replacement?

2007-01-12 Thread Florian G. Pflug
Michael Enke wrote: This works for small amount of data. But for large amount of data the join takes a lot of time. It certainly is faster then anly algorithm that checks for duplicates for each lines of copy input could ever be. Especially for joins, doing them in one large batch allows you

Re: [HACKERS] Request for review: tsearch2 patch

2007-01-12 Thread Tatsuo Ishii
Yeah, it's a workaround. Since there's no concept other than alpha/numeric/latin in tsearch2, Asian characters have to be fall in one of them. Ok, I see. Pls, test attached patch - if it is good then I'll commit it at Monday to HEAD and 8.2 branches. I have tested on a Linux box

Re: [HACKERS] [GENERAL] Autovacuum Improvements

2007-01-12 Thread Christopher Browne
In an attempt to throw the authorities off his trail, [EMAIL PROTECTED] (Alvaro Herrera) transmitted: Simon Riggs wrote: Some feedback from initial testing is that 2 queues probably isn't enough. If you have tables with 100s of blocks and tables with millions of blocks, the tables in the

Re: [HACKERS] [PERFORM] unusual performance for vac following 8.2upgrade

2007-01-12 Thread Richard Huxton
Tom Lane wrote: Alvaro Herrera [EMAIL PROTECTED] writes: Can we actually get rid of pg_class entries for temp tables. Maybe creating a temp pg_class which would be local to each session? Heck, it doesn't even have to be an actual table -- it just needs to be somewhere from where we can load

Re: [HACKERS] [PERFORM] unusual performance for vac following 8.2upgrade

2007-01-12 Thread Gregory Stark
Tom Lane [EMAIL PROTECTED] writes: 3. What about dependencies on user-defined types, functions, etc? How will you get things to behave sanely if one backend tries to drop a type that some other backend is using in a column of a temp table? Even if you put entries into pg_depend, which would

Re: [HACKERS] [PERFORM] unusual performance for vac following 8.2upgrade

2007-01-12 Thread Jim C. Nasby
On Thu, Jan 11, 2007 at 09:51:39PM -0500, Tom Lane wrote: Alvaro Herrera [EMAIL PROTECTED] writes: Can we actually get rid of pg_class entries for temp tables. Maybe creating a temp pg_class which would be local to each session? Heck, it doesn't even have to be an actual table -- it just

Re: [HACKERS] [PATCHES] Patch to log usage of temporary files

2007-01-12 Thread Guillaume Smet
Hi all, Sorry for arriving so late into the discussion. I don't know if it's possible but it could be useful to have the text of the query which required the creation of the temporary files as an additional DETAIL line. At least, if it's possible to have it in this part of the code. Thoughts?

Re: [HACKERS] [PATCHES] wal_checksum = on (default) | off

2007-01-12 Thread Martijn van Oosterhout
On Thu, Jan 11, 2007 at 11:10:38PM +, Simon Riggs wrote: On Thu, 2007-01-11 at 17:06 +, Gregory Stark wrote: Having a CRC in WAL but not in the heap seems kind of pointless. Yes... If your hardware is unreliable the corruption could anywhere. Agreed. I thought the point

Re: [pgsql-patches] [HACKERS] [PATCHES] Patch to log usage of

2007-01-12 Thread Bruce Momjian
Simon Riggs wrote: On Thu, 2007-01-11 at 12:37 -0500, Bruce Momjian wrote: The trace probe was incorrect Yes, incomplete, no doubt. On that point you were 100% right to reject. and kind of at an odd place. I don't think we want to go down the road of throwing trace in everwhere, do

Re: [pgsql-patches] [HACKERS] [PATCHES] Patch to log usage oftemporary files

2007-01-12 Thread Simon Riggs
On Fri, 2007-01-12 at 11:44 -0500, Bruce Momjian wrote: I think the right approach is to look at our existing code and come up with places we want them, and add them in one shot. Doing thing in small parts doesn't work too well with a project this size. Will do. -- Simon Riggs

Re: [HACKERS] [pgsql-patches] [PATCHES] Patch to log usage of temporary

2007-01-12 Thread Bruce Momjian
Guillaume Smet wrote: Hi all, Sorry for arriving so late into the discussion. I don't know if it's possible but it could be useful to have the text of the query which required the creation of the temporary files as an additional DETAIL line. At least, if it's possible to have it in this

Re: [HACKERS] [pgsql-patches] [PATCHES] Patch to log usage of temporary files

2007-01-12 Thread Guillaume Smet
Hi Bruce, Thanks for your answer. On 1/12/07, Bruce Momjian [EMAIL PROTECTED] wrote: We have the ability to conditionally print statements based on error level, but LOG isn't a valid level for log_min_error_statement. We could add a parameter that few people would use, but the right way to do

Re: [HACKERS] [pgsql-patches] [PATCHES] Patch to log usage of temporary files

2007-01-12 Thread Tom Lane
Guillaume Smet [EMAIL PROTECTED] writes: That's not what I had in mind. I was asking if the text of the query was available when logging the temp file usage. If so it could be good to add a DETAIL line with it directly and systematically when logging the temp file usage. (1) you could make

Re: [HACKERS] [pgsql-patches] [PATCHES] Patch to log usage of temporary

2007-01-12 Thread Bruce Momjian
Guillaume Smet wrote: Hi Bruce, Thanks for your answer. On 1/12/07, Bruce Momjian [EMAIL PROTECTED] wrote: We have the ability to conditionally print statements based on error level, but LOG isn't a valid level for log_min_error_statement. We could add a parameter that few people

Re: [HACKERS] [pgsql-patches] [PATCHES] Patch to log usage of temporary files

2007-01-12 Thread Guillaume Smet
On 1/12/07, Bruce Momjian [EMAIL PROTECTED] wrote: Usually people don't want th query unless they ask for it. One nify trick would be to print the query as DETAIL unless they are already logging queries, but that just seems too complex. If you want the query, why not just log them all?

Re: [HACKERS] [pgsql-patches] [PATCHES] Patch to log usage of temporary files

2007-01-12 Thread Guillaume Smet
On 1/12/07, Tom Lane [EMAIL PROTECTED] wrote: Guillaume Smet [EMAIL PROTECTED] writes: That's not what I had in mind. I was asking if the text of the query was available when logging the temp file usage. If so it could be good to add a DETAIL line with it directly and systematically when

Re: [HACKERS] [pgsql-patches] [PATCHES] Patch to log usage of temporary files

2007-01-12 Thread Tom Lane
Guillaume Smet [EMAIL PROTECTED] writes: On 1/12/07, Tom Lane [EMAIL PROTECTED] wrote: (2) there is already a generalized solution to this, it's called log_min_error_statement. I didn't think of that when posting my message but Bruce seems to say that we can't use it in this case. Dunno why

Re: [HACKERS] [pgsql-patches] [PATCHES] Patch to log usage of temporary

2007-01-12 Thread Bruce Momjian
Guillaume Smet wrote: On 1/12/07, Bruce Momjian [EMAIL PROTECTED] wrote: Usually people don't want th query unless they ask for it. One nify trick would be to print the query as DETAIL unless they are already logging queries, but that just seems too complex. If you want the query, why

Re: [HACKERS] [pgsql-patches] [GENERAL] Corrupt database? 8.1/FreeBSD6.0

2007-01-12 Thread Alvaro Herrera
Alvaro Herrera wrote: Tom Lane wrote: Alvaro Herrera [EMAIL PROTECTED] writes: Maybe we could forcibly activate the freeze mode on a template database? Might not be a bad idea. And even more to the point, forcibly disable analyze. Patch implementing this (albeit untested!)

Re: [HACKERS] [pgsql-patches] [GENERAL] Corrupt database? 8.1/FreeBSD6.0

2007-01-12 Thread Tom Lane
Alvaro Herrera [EMAIL PROTECTED] writes: Ok, it does what it's intended to do. But in testing it I also confirmed that a database-wide vacuum creates a pgstat entry for it and for all tables in it. Is this something we want to prevent? That's odd, because I didn't see any such thing when I

Re: [HACKERS] [pgsql-patches] [PATCHES] Patch to log usage of

2007-01-12 Thread Bruce Momjian
Tom Lane wrote: Guillaume Smet [EMAIL PROTECTED] writes: On 1/12/07, Tom Lane [EMAIL PROTECTED] wrote: (2) there is already a generalized solution to this, it's called log_min_error_statement. I didn't think of that when posting my message but Bruce seems to say that we can't use it

Re: [HACKERS] [pgsql-patches] [GENERAL] Corrupt database? 8.1/FreeBSD6.0

2007-01-12 Thread Alvaro Herrera
Tom Lane wrote: Alvaro Herrera [EMAIL PROTECTED] writes: Ok, it does what it's intended to do. But in testing it I also confirmed that a database-wide vacuum creates a pgstat entry for it and for all tables in it. Is this something we want to prevent? That's odd, because I didn't see

Re: [HACKERS] [pgsql-patches] [PATCHES] Patch to log usage of temporary files

2007-01-12 Thread Bill Moran
In response to Guillaume Smet [EMAIL PROTECTED]: On 1/12/07, Bruce Momjian [EMAIL PROTECTED] wrote: Usually people don't want th query unless they ask for it. One nify trick would be to print the query as DETAIL unless they are already logging queries, but that just seems too complex. If

Re: [HACKERS] [pgsql-patches] [GENERAL] Corrupt database? 8.1/FreeBSD6.0

2007-01-12 Thread Tom Lane
Alvaro Herrera [EMAIL PROTECTED] writes: Tom Lane wrote: Alvaro Herrera [EMAIL PROTECTED] writes: Ok, it does what it's intended to do. But in testing it I also confirmed that a database-wide vacuum creates a pgstat entry for it and for all tables in it. Is this something we want to

Re: [HACKERS] NaN behavior

2007-01-12 Thread Neil Conway
On Thu, 2007-01-11 at 21:04 -0500, Neil Conway wrote: Comments? I'll write up a doc patch, barring any objections. I'll apply the attached doc patch to CVS tomorrow, barring any objections. -Neil Index: doc/src/sgml/datatype.sgml