[HACKERS] row-wise comparison question/issue

I noticed something odd when trying to use the row-wise comparison mentioned in the release notes for 8.2 and in the docs http://developer.postgresql.org/pgdocs/postgres/functions-comparisons.html#ROW-WISE-COMPARISON This sets up a suitable test: create type myrowtype AS (a integer, b integer); c

Re: [HACKERS] New CRC algorithm: Slicing by 8

On 10/20/06, Alvaro Herrera <[EMAIL PROTECTED]> wrote: It doesn't say anything aboutbeing free of patents though.The Sourceforge project referred to in the article (but for which nolink is given) seems to be this one: http://sourceforge.net/projects/slicing-by-8Yes. I had already mentioned that lin

Re: [HACKERS] Asynchronous I/O Support

Hi, On 10/18/06, Martijn van Oosterhout wrote: On Wed, Oct 18, 2006 at 08:04:29PM +1300, Mark Kirkwood wrote:> >"bgwriter doing aysncronous I/O for the dirty buffers that it is> >supposed to sync"> >Another decent use-case? Good idea, but async i/o is generally poorly supported.

Re: [HACKERS] adminpack and pg_catalog

On 19/10/06 19:37, "Neil Conway" <[EMAIL PROTECTED]> wrote: > Why does adminpack install functions into pg_catalog? This is > inconsistent with the rest of the contrib/ packages, not to mention the > definition of pg_catalog itself (which ought to hold builtin object > definitions). The admin

Re: [HACKERS] adminpack and pg_catalog

On Thu, Oct 19, 2006 at 02:37:34PM -0400, Neil Conway wrote: > Why does adminpack install functions into pg_catalog? This is > inconsistent with the rest of the contrib/ packages, not to mention the > definition of pg_catalog itself (which ought to hold builtin object > definitions). And as AndrewS

Re: [HACKERS] Statements with syntax errors are not logged

On Thu, Oct 19, 2006 at 06:32:08PM -0400, Tom Lane wrote: > So I'm inclined to leave the behavior as-is. The documentation for > log_statement already says > > Note: Statements that generate syntax errors are not logged. Set > log_min_error_statement to error to log such statements.

Re: [HACKERS] New CRC algorithm: Slicing by 8

Tom Lane wrote: > "Gurjeet Singh" <[EMAIL PROTECTED]> writes: > >> Please refer to the following link for a new algorithm to calculate > >> CRC, developed by Intel. > >> > >> http://www.intel.com/technology/magazine/communications/slicing-by-8-0306.htm > > I can't help wondering what the patent s

Re: [HACKERS] New CRC algorithm: Slicing by 8

"Gurjeet Singh" <[EMAIL PROTECTED]> writes: >> Please refer to the following link for a new algorithm to calculate >> CRC, developed by Intel. >> >> http://www.intel.com/technology/magazine/communications/slicing-by-8-0306.htm I can't help wondering what the patent status of this algorithm is. (

Re: [HACKERS] Statements with syntax errors are not logged

I wrote: > Peter Eisentraut <[EMAIL PROTECTED]> writes: >> Then it should be changed to log *only* successfully executed statements >> and explicitly documented as such. > Well, maybe we should do that. I fooled around with doing that, and while it's a simple code change, I realized that it's go

Re: [HACKERS] [COMMITTERS] pgsql: Work around reported problem that AIX's getaddrinfo() doesn't

"Rocco Altier" <[EMAIL PROTECTED]> writes: > This change has broken my AIX 5.2 buildfarm machine (asp/kookaburra), > but doesn't seem to break the 5.3 member (grebe). Sigh, count on IBM to make life complicated. Instead of hacking servname, I suppose we will have to poke the correct value into si

Re: [HACKERS] [COMMITTERS] pgsql: Work around reported problem that AIX's getaddrinfo() doesn't

This change has broken my AIX 5.2 buildfarm machine (asp/kookaburra), but doesn't seem to break the 5.3 member (grebe). It appears to have problems with stats being off now? What can I do to help debug the situation? -rocco > -Original Message- > From: [EMAIL PROTECTED] > [mail

Re: [HACKERS] Granting all tables in schema by one SQL command

On 10/19/06, Krycek <[EMAIL PROTECTED]> wrote: The proposed syntax is: GRANT SELECT ON ALL TABLES IN public TO phpuser; GRANT SELECT ON NEW TABLES IN public TO phpuser;" "GRANT SELECT ON NEW TABLES IN public TO phpuser;"? What does "NEW TABLES" mean in this context? the point is to allow t

Re: [HACKERS] [PATCHES] oid2name optargs

"Magnus Hagander" <[EMAIL PROTECTED]> writes: > oid2name requires an extern char*optarg to build on win32. [ looks around... ] zic.c seems to need it too. regards, tom lane ---(end of broadcast)--- TIP 1: if posting/reading

Re: [HACKERS] Extending tablespaces

Okay, thank you. On Thu, 2006-10-19 at 15:56 -0400, Tom Lane wrote: > Gevik Babakhani <[EMAIL PROTECTED]> writes: > > Now I am thinking what it would take to give pg the functionality to > > extend tablespaces automatically. > > It's called LVM ... and no, we are not interested in reimplementing

Re: [HACKERS] Beta, RC Time?

Bruce Momjian <[EMAIL PROTECTED]> writes: > Where are we on releasing beta2 or perhaps going right to an RC1 > release? Seems it is time for one of them. I think we need a beta2 now, and perhaps RC1 in a week. We've done enough portability hacking recently that some more beta seems indicated.

Re: [HACKERS] Granting all tables in schema by one SQL command

looks to me that NEW TABLES are the tables created AFTER the GRANT :)Is that?[]'s- WalterOn 10/19/06, Krycek < [EMAIL PROTECTED]> wrote:HelloIm new to PostgreSQL development and I would like to make "introduce" patch that will satisfied this point of TODO:"%Allow GRANT/REVOKE permissions to be appl

[HACKERS] Granting all tables in schema by one SQL command

Hello Im new to PostgreSQL development and I would like to make "introduce" patch that will satisfied this point of TODO: "%Allow GRANT/REVOKE permissions to be applied to all schema objects with one command The proposed syntax is: GRANT SELECT ON ALL TABLES IN public TO phpuser; GRANT SEL

Re: [HACKERS] Asynchronous I/O Support

On Sun, Oct 15, 2006 at 14:26:12 -0400, Neil Conway <[EMAIL PROTECTED]> wrote: > > At least according to [1], kernel AIO on Linux still doesn't work for > buffered (i.e. non-O_DIRECT) files. There have been patches available > for quite some time that implement this, but I'm not sure when they a

[HACKERS] Beta, RC Time?

Where are we on releasing beta2 or perhaps going right to an RC1 release? Seems it is time for one of them. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of bro

Re: [HACKERS] [PATCHES] Win32 BYTE_ORDER

"Magnus Hagander" <[EMAIL PROTECTED]> writes: >> Done, but I think you forgot the defs for LITTLE_ENDIAN and >> friends ... it seems unlikely that a platform would provide >> those and then forget BYTE_ORDER. > Well, it compiled just fine, so it must've found it somewhere :-) I think the #if te

Re: [HACKERS] [PATCHES] Win32 BYTE_ORDER

> > This patch adds a #define for BYTE_ORDER to win32.h if it's > not pulled > > in elsewhere, as needed by msvc build of pgcrypto. Seems > several other > > platforms define it in their port file already, but not win32. > > Done, but I think you forgot the defs for LITTLE_ENDIAN and > friend

Re: [HACKERS] [PATCHES] earthdistance update for msvc

> > A define is needed to expose the M_PI define from the > system headers. > > It seems like the other places where we depend on M_PI, we > instead have > > #ifndef M_PI > #define M_PI 3.14159265358979323846 > #endif > > Perhaps that's a better solution? Oh. I actually did that for my quick-

Re: [HACKERS] [PATCHES] Win32 BYTE_ORDER

"Magnus Hagander" <[EMAIL PROTECTED]> writes: > This patch adds a #define for BYTE_ORDER to win32.h if it's not pulled > in elsewhere, as needed by msvc build of pgcrypto. Seems several other > platforms define it in their port file already, but not win32. Done, but I think you forgot the defs for

Re: [HACKERS] [PATCHES] earthdistance update for msvc

"Magnus Hagander" <[EMAIL PROTECTED]> writes: > A define is needed to expose the M_PI define from the system headers. It seems like the other places where we depend on M_PI, we instead have #ifndef M_PI #define M_PI 3.14159265358979323846 #endif Perhaps that's a better solution?

Re: [HACKERS] Extending tablespaces

Gevik Babakhani <[EMAIL PROTECTED]> writes: > Now I am thinking what it would take to give pg the functionality to > extend tablespaces automatically. It's called LVM ... and no, we are not interested in reimplementing filesystem-level functionality ... regards, tom lane

Re: [HACKERS] [PATCHES] Adminpack build fix

> > Attached patch removes a couple of extern definitions from > adminpack, > > replacing some of them with a #include. > > I've now removed all the local DLLIMPORT-redeclarations I > could find in favor of marking the relevant variables in the > main header files. Thanks. All affected projec

[HACKERS] Extending tablespaces

Recently I ran into a "disk full" problem with my database. I had to play with the tablespaces and locations symlinks... until the disk could be cleaned just enough for the database to continue operation. I had plenty of space on another disk but found no *easy* way to humbly ask postgres to contin

Re: [HACKERS] [PATCHES] Adminpack build fix

"Magnus Hagander" <[EMAIL PROTECTED]> writes: > Attached patch removes a couple of extern definitions from adminpack, > replacing some of them with a #include. I've now removed all the local DLLIMPORT-redeclarations I could find in favor of marking the relevant variables in the main header files.

Re: [HACKERS] Speaking of contrib Makefiles

> both cube and seg seems to do some funky stuff with > flex/bison, if I'm not entirely mistaken. Cube, for example, > uses a rule that builds "cubeparse.o" from "cubescan.c". > (which in turnis built from flex/bison files). > > Is there any reason why we don't build a file called > "cubescan.

[HACKERS] Speaking of contrib Makefiles

both cube and seg seems to do some funky stuff with flex/bison, if I'm not entirely mistaken. Cube, for example, uses a rule that builds "cubeparse.o" from "cubescan.c". (which in turnis built from flex/bison files). Is there any reason why we don't build a file called "cubescan.o" from "cubescan.

[HACKERS] adminpack and pg_catalog

Why does adminpack install functions into pg_catalog? This is inconsistent with the rest of the contrib/ packages, not to mention the definition of pg_catalog itself (which ought to hold builtin object definitions). And as AndrewSN pointed out on IRC, it also breaks pg_dump. -Neil -

Re: [HACKERS] CVS repository rsync

> > I've set up my laptop to sync down the full cvs repository > using rsync > > (remember - windows = no cvsup). This works well, except > every now and > > then (not every time, but definitly often enough to bother me) it > > resyncs the entire repository, and not just the files that have ha

Re: [HACKERS] CVS repository rsync

Magnus Hagander wrote: > I've set up my laptop to sync down the full cvs repository using rsync > (remember - windows = no cvsup). This works well, except every now and > then (not every time, but definitly often enough to bother me) it > resyncs the entire repository, and not just the files that h

Re: [HACKERS] qsort vs MSVC build

Neil Conway <[EMAIL PROTECTED]> writes: > On Thu, 2006-10-19 at 13:56 -0400, Tom Lane wrote: >> Is it worth renaming our qsort to pg_qsort to avoid this? (I'd be >> inclined to do that via a macro "#define qsort pg_qsort", not by running >> around and changing all the code.) > Why not change each

Re: [HACKERS] qsort vs MSVC build

On Thu, 2006-10-19 at 13:56 -0400, Tom Lane wrote: > Is it worth renaming our qsort to pg_qsort to avoid this? (I'd be > inclined to do that via a macro "#define qsort pg_qsort", not by running > around and changing all the code.) Why not change each call site? I don't think it would hurt to be c

Re: [HACKERS] qsort vs MSVC build

> >> Is it worth renaming our qsort to pg_qsort to avoid this? > >> (I'd be inclined to do that via a macro "#define qsort > pg_qsort", not > >> by running around and changing all the code.) > > > Yeah, I think it is ;-) Just make sure it happens before we pull in > > stdlib.h, so we don't re

Re: [HACKERS] CVS repository rsync

> > This works well, except every now and > > then (not every time, but definitly often enough to bother me) it > > resyncs the entire repository, and not just the files that have had > > commits to them. > > I haven't noticed this personally, although I might have just > missed it. > Are you s

Re: [HACKERS] qsort vs MSVC build

"Magnus Hagander" <[EMAIL PROTECTED]> writes: >> Is it worth renaming our qsort to pg_qsort to avoid this? >> (I'd be inclined to do that via a macro "#define qsort >> pg_qsort", not by running around and changing all the code.) > Yeah, I think it is ;-) Just make sure it happens before we pull

Re: [HACKERS] CVS repository rsync

On Thu, 2006-10-19 at 19:52 +0200, Magnus Hagander wrote: > I've set up my laptop to sync down the full cvs repository using rsync > (remember - windows = no cvsup). Yeah, I do this as well, and for similar reasons (cvsup is unmaintained and annoying to build, at least on AMD64/Debian). > This wo

Re: [HACKERS] qsort vs MSVC build

On Thu, Oct 19, 2006 at 01:56:24PM -0400, Tom Lane wrote: > Is it worth renaming our qsort to pg_qsort to avoid this? (I'd be > inclined to do that via a macro "#define qsort pg_qsort", not by running > around and changing all the code.) Redefining a function that is defined in POSIX and present

Re: [HACKERS] qsort vs MSVC build

> > MSVCRTD.lib(MSVCR80D.dll) : error LNK2005: _qsort already > defined in > > qsort.obj > > Hmm. I've been seeing related complaints on Darwin, but they > were just warnings (about our qsort conflicting with the one in libc). Yeah, seems it works in Mingw, but for some reason it's fatal in M

Re: [HACKERS] [PATCHES] Adminpack build fix

"Magnus Hagander" <[EMAIL PROTECTED]> writes: >> The same redeclaration technique is being used elsewhere >> (pg_buffercache and pg_freespacemap it looks like). Aren't >> you getting warnings there too? > I am - I just started working on getting those done as well. OK, I guess we gotta play th

Re: [HACKERS] qsort vs MSVC build

"Magnus Hagander" <[EMAIL PROTECTED]> writes: > I just tried a rebuild of the MSVC stuff, and got the following error. > Any ideas on the best way to fix that? > 1>.\src\port\qsort.c(53) : warning C4005: 'min' : macro redefinition > C:\Program Files\Microsoft Visual Studio This is fixed a

[HACKERS] CVS repository rsync

I've set up my laptop to sync down the full cvs repository using rsync (remember - windows = no cvsup). This works well, except every now and then (not every time, but definitly often enough to bother me) it resyncs the entire repository, and not just the files that have had commits to them. Anybo

Re: [HACKERS] [PATCHES] Adminpack build fix

> >> The reason for redeclaring these in the contrib files is to get > >> DLLIMPORT onto them... > > > Interedting - it builds on MSVC without it :-O > > > Anyway. That certainly explains why MSVC is complaining - > it's getting > > completely different definitions of these variables from the

[HACKERS] qsort vs MSVC build

I just tried a rebuild of the MSVC stuff, and got the following error. Any ideas on the best way to fix that? (as you notice, I haven't pulled the very latest cvs so I haven't for the min() fix that's put in now. Just let me know if the rest is also fixed ;-)) //Magnus Build started: Project: p

Re: [HACKERS] [PATCHES] Adminpack build fix

"Magnus Hagander" <[EMAIL PROTECTED]> writes: >> The reason for redeclaring these in the contrib files is to >> get DLLIMPORT onto them... > Interedting - it builds on MSVC without it :-O > Anyway. That certainly explains why MSVC is complaining - it's getting > completely different definitions

Re: [HACKERS] [PATCHES] Adminpack build fix

> > Attached patch removes a couple of extern definitions from > adminpack, > > replacing some of them with a #include. (Cam eup with this > because we > > got a duplicate definition of DataDir when building with > Visual C++). > > That isn't going to work unless we put DLLIMPORT into the >

Re: [HACKERS] [PATCHES] Contrib Makefiles

> > A couple of the Makefiles in contrib don't define OBJS= as > standard, > > instead they define SRCS= and then a makefile rule for > OBJS= that does > > a replacement on that. > > > Is there any actual reason for that? > > Can't see one. Ok. Thanks. > > If not, could the attached patch

Re: [HACKERS] [PATCHES] Contrib Makefiles

"Magnus Hagander" <[EMAIL PROTECTED]> writes: > A couple of the Makefiles in contrib don't define OBJS= as standard, > instead they define SRCS= and then a makefile rule for OBJS= that does a > replacement on that. > Is there any actual reason for that? Can't see one. > If not, could the attache

Re: [HACKERS] [PATCHES] Adminpack build fix

"Magnus Hagander" <[EMAIL PROTECTED]> writes: > Attached patch removes a couple of extern definitions from adminpack, > replacing some of them with a #include. (Cam eup with this because we > got a duplicate definition of DataDir when building with Visual C++). That isn't going to work unless we p

Re: [HACKERS] Additional stats for Relations

On Thu, Oct 19, 2006 at 11:47:53AM -0400, Tom Lane wrote: > "Jim C. Nasby" <[EMAIL PROTECTED]> writes: > > BTW, if we add these counters we'll be up to 7 stats dealing with vacuum > > and analyze, and NikhilS has a patch we're finalizing that would add 3 > > more. Right now there's 4 slated to go i

Re: [HACKERS] Additional stats for Relations

"Jim C. Nasby" <[EMAIL PROTECTED]> writes: > BTW, if we add these counters we'll be up to 7 stats dealing with vacuum > and analyze, and NikhilS has a patch we're finalizing that would add 3 > more. Right now there's 4 slated to go into pg_stat_* in 8.2, but maybe > we should have a separate view f

Re: [HACKERS] Statements with syntax errors are not logged

Peter Eisentraut <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> To some extent the logging >> settings are only meant to capture successfully executed statements > Then it should be changed to log *only* successfully executed statements > and explicitly documented as such. Well, maybe we shou

Re: [HACKERS] Statements with syntax errors are not logged

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, Oct 19, 2006 at 04:28:17PM +0200, Peter Eisentraut wrote: > When setting log_statement = 'all', statements that fail parsing are not > logged. For example: [...] HA! This one has bitten me just today :-) The problem was a faulty client send

Re: [HACKERS] Additional stats for Relations

On Thu, Oct 19, 2006 at 04:10:46PM +0530, NikhilS wrote: > Hi Jim, > > On 10/18/06, Jim C. Nasby <[EMAIL PROTECTED]> wrote: > > > >Also how many times a relation has been vacuumed (which puts all the > >other numbers in more perspective... good catch Simon). And I think > >number of pages that cou

Re: [HACKERS] Statements with syntax errors are not logged

Tom Lane wrote: > The 'mod' and 'ddl' settings obviously can't be handled until after > basic parsing. We could create a completely separate code path for > 'all' but I'm not sure I see the point. The users are evidently expecting that "log all statements" means to log all statements issued by t

Re: [HACKERS] Statements with syntax errors are not logged

Peter Eisentraut <[EMAIL PROTECTED]> writes: > When setting log_statement = 'all', statements that fail parsing are not > logged. > Is that intentional? The 'mod' and 'ddl' settings obviously can't be handled until after basic parsing. We could create a completely separate code path for 'all' but

[HACKERS] Statements with syntax errors are not logged

When setting log_statement = 'all', statements that fail parsing are not logged. For example: LOG: connection received: host=[local] LOG: connection authorized: user=peter database=peter LOG: statement: select * from pg_class; LOG: duration: 19.084 ms ### here a log entry is missing ERROR: s

Re: [HACKERS] Fwd: New CRC algorithm: Slicing by 8

Andrew Dunstan wrote: If you have a patch, send it to -hackers. I mean -patches of course. Sorry. cheers andrew ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster

Re: [HACKERS] Fwd: New CRC algorithm: Slicing by 8

Gurjeet Singh wrote: Can someone let us all know what is the limit on the attachments sent to the -hackers list? Generally it's probably best not to send attachments to -hackers at all. If you have a patch, send it to -hackers. Or you can publish it somewhere on the web and post a

[HACKERS] Fwd: New CRC algorithm: Slicing by 8

    Resending... The previous 3 attempt haven't succeeded, probably because of size restrictions; so sending in two parts.    This is part 2; unfortunately, the size of the gzipped file is still a bit big (26 KB), so I have uploaded it to http://www.geocities.com/gurjeet79/crc_sb8_test.tar.gz    P

Re: [HACKERS] Additional stats for Relations

Hi Jim, On 10/18/06, Jim C. Nasby <[EMAIL PROTECTED]> wrote: Also how many times a relation has been vacuumed (which puts all theother numbers in more perspective... good catch Simon). And I thinknumber of pages that could not be added to the FSM would also beextremely valuable. By the above, do y

Re: [HACKERS] pg_internal.init is hazardous to your health

Simon Riggs wrote: RelationCacheInitFileInvalidate() is also called on each FinishPreparedTransaction(). It's only called if the prepared transaction invalidated the init file. If that is called 100% of the time, then we can skip writing an additional record for prepared transactions by trig

Re: [HACKERS] New CRC algorithm: Slicing by 8

Resending... The previous 3 attempt haven't succeeded, probably because of size restrictions; so sending in two parts.On 10/18/06, Gurjeet Singh < [EMAIL PROTECTED]> wrote:Hi all,    Please refer to the following link for a new algorithm to calculate CRC, developed by Intel.     http://www.intel.co