Re: [HACKERS] What is happening on buildfarm member baiji?

2007-05-15 Thread Dave Page
Andrew Dunstan wrote: Dave Page wrote: 1) There appears to be no way to specify the default port number in the MSVC build. The buildfarm passes it to configure for regular builds, which obviously isn't run in VC++ mode, thus leaving the build on 5432. I have committed fixes to

[HACKERS] Re: [BUGS] Removing pg_auth_members.grantor (was Grantor name gets lost when grantor role dropped)

2007-05-15 Thread Russell Smith
Alvaro Herrera wrote: Alvaro Herrera wrote: 2. decide that the standard is braindead and just omit dumping the grantor when it's no longer available, but don't remove pg_auth_members.grantor Which do people feel should be implemented? I can do whatever we decide; if no one has a

Re: [HACKERS] Seq scans roadmap

2007-05-15 Thread Heikki Linnakangas
Just to keep you guys informed, I've been busy testing and pondering over different buffer ring strategies for vacuum, seqscans and copy. Here's what I'm going to do: Use a fixed size ring. Fixed as in doesn't change after the ring is initialized, however different kinds of scans use

Re: [HACKERS] Seq scans roadmap

2007-05-15 Thread Luke Lonergan
Heikki, 32 buffers = 1MB with 32KB blocksize, which spoils the CPU L2 cache effect. How about using 256/blocksize? - Luke -Original Message- From: Heikki Linnakangas [mailto:[EMAIL PROTECTED] On Behalf Of Heikki Linnakangas Sent: Tuesday, May 15, 2007 2:32 AM To:

Re: [HACKERS] Seq scans roadmap

2007-05-15 Thread Heikki Linnakangas
Luke Lonergan wrote: 32 buffers = 1MB with 32KB blocksize, which spoils the CPU L2 cache effect. How about using 256/blocksize? Sounds reasonable. We need to check the effect on the synchronized scans, though. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com

Re: [HACKERS] Windows Vista support (Buildfarm Vaquita)

2007-05-15 Thread Michael Meskes
On Wed, May 09, 2007 at 12:46:52PM +0100, Dave Page wrote: Unfortunately I do not have access to a Vista system I could use to test and track this one down. I'm happy to run any tests you like. Dave, could you please apply this small patch to pgtypeslib/datetime.c. I still have no clue where

[HACKERS] Invalid magic number in log file?

2007-05-15 Thread Gregory Stark
When starting up a postmaster from an older build on a database initialized with a newer build I'm getting the following errors. I think I saw the same thing earlier going in the opposite direction too. Shouldn't there be some earlier errors firing from the control file version number? [EMAIL

[HACKERS] fixing uuid-ossp

2007-05-15 Thread Andrew Dunstan
I propose to unbreak this contrib module for machines that don't have uuid.h installed in a directory called ossp (e.g. fc6), by changing #include ossp/uuid.h to #include uuid.h People who *do* have it installed in such a directory can add to the build with a --with-includes configure

Re: [HACKERS] Invalid magic number in log file?

2007-05-15 Thread Alvaro Herrera
Gregory Stark wrote: When starting up a postmaster from an older build on a database initialized with a newer build I'm getting the following errors. I think I saw the same thing earlier going in the opposite direction too. Shouldn't there be some earlier errors firing from the control file

Re: [HACKERS] [BUGS] Removing pg_auth_members.grantor (was Grantor name gets lost when grantor role dropped)

2007-05-15 Thread Alvaro Herrera
Russell Smith wrote: Alvaro Herrera wrote: Alvaro Herrera wrote: 2. decide that the standard is braindead and just omit dumping the grantor when it's no longer available, but don't remove pg_auth_members.grantor Which do people feel should be implemented? I can do whatever we

Re: [HACKERS] Managing the community information stream

2007-05-15 Thread Bruce Momjian
To follow up on this, if you look at how TODO items are created, they often come out of discussion threads, and sometimes more than one idea comes from a discussion thread. If we moved to a trackers system, how would we handle that? Also, if I want to discuss renaming something or cleaning up

Re: [HACKERS] Invalid magic number in log file?

2007-05-15 Thread Gregory Stark
Alvaro Herrera [EMAIL PROTECTED] writes: Gregory Stark wrote: When starting up a postmaster from an older build on a database initialized with a newer build I'm getting the following errors. I think I saw the same thing earlier going in the opposite direction too. Shouldn't there be some

[HACKERS] Not ready for 8.3

2007-05-15 Thread Bruce Momjian
Based on our progress during this feature freeze, we will not complete the feature freeze until August/September. I think we need adjust expectations about an 8.3 release date, and decide if we want to radically change our work process. Basically, to make a release anywhere near July, we need

[HACKERS] Bulk inserts and usage_count

2007-05-15 Thread Heikki Linnakangas
While testing the buffer ring patch, I noticed that bulk inserts with both INSERT and COPY pin and unpin the buffer they insert to for every tuple. That means that the usage_count of all those buffers are bumped up to 5. That's gotta be bad if you try to run a COPY concurrently with other

Re: [HACKERS] Not ready for 8.3

2007-05-15 Thread Gregory Stark
Bruce Momjian [EMAIL PROTECTED] writes: I think the only other thing we _could_ do is to re-open normal 8.3 development, so we aren't hampering updates to trivial parts of the code. Many of the patches now in the queue had been developed for months before 8.3 started, so the hope is that we

Re: [HACKERS] Not ready for 8.3

2007-05-15 Thread Joshua D. Drake
Bruce Momjian wrote: Based on our progress during this feature freeze, we will not complete the feature freeze until August/September. I think we need adjust expectations about an 8.3 release date, and decide if we want to radically change our work process. Basically, to make a release

Re: [HACKERS] Concurrently updating an updatable view

2007-05-15 Thread Richard Huxton
Hiroshi Inoue wrote: Florian G. Pflug wrote: I think there should be a big, fat warning that self-referential updates have highly non-obvious behaviour in read-committed mode, and should be avoided. It seems pretty difficult for PostgreSQL rule system to avoid such kind of updates. I'm

Re: [HACKERS] Managing the community information stream

2007-05-15 Thread Joshua D. Drake
Bruce Momjian wrote: To follow up on this, if you look at how TODO items are created, they often come out of discussion threads, and sometimes more than one idea comes from a discussion thread. If we moved to a trackers system, how would we handle that? We have the discussion on list, if it

Re: [HACKERS] Concurrently updating an updatable view

2007-05-15 Thread Florian G. Pflug
Richard Huxton wrote: Hiroshi Inoue wrote: Florian G. Pflug wrote: I think there should be a big, fat warning that self-referential updates have highly non-obvious behaviour in read-committed mode, and should be avoided. It seems pretty difficult for PostgreSQL rule system to avoid such

Re: [HACKERS] Not ready for 8.3

2007-05-15 Thread Bruce Momjian
Joshua D. Drake wrote: Bruce Momjian wrote: Based on our progress during this feature freeze, we will not complete the feature freeze until August/September. I think we need adjust expectations about an 8.3 release date, and decide if we want to radically change our work process.

Re: [HACKERS] Not ready for 8.3

2007-05-15 Thread Bruce Momjian
Joshua D. Drake wrote: Patch status: http://developer.postgresql.org/index.php/Todo:PatchStatus If... this is actually a problem (I leave to other committers and reviewers to comment) then I suggest we push all patches without a reviewer as of now to 8.4. Leaving only those

Re: [HACKERS] Managing the community information stream

2007-05-15 Thread Alvaro Herrera
Joshua D. Drake wrote: Also, if I want to discuss renaming something or cleaning up some code, do we create a tracker item for that or do we have a developer email list to discuss such issues? In the most conformist sense yes, but I can tell you that generally isn't how CMD does it. How

Re: [HACKERS] Not ready for 8.3

2007-05-15 Thread Gregory Stark
Bruce Momjian [EMAIL PROTECTED] writes: Joshua D. Drake wrote: Bruce Momjian wrote: Based on our progress during this feature freeze, we will not complete the feature freeze until August/September. I think we need adjust expectations about an 8.3 release date, and decide if we want to

Re: [HACKERS] Not ready for 8.3

2007-05-15 Thread Stefan Kaltenbrunner
Joshua D. Drake wrote: FYI, whoever did that Todo:Patch status, Bravo! That is easily one of the smallest but best improvements to the process I have seen in recent memory. well bruce asked for something like that: http://archives.postgresql.org/pgsql-hackers/2007-05/msg00249.php and I

Re: [HACKERS] Managing the community information stream

2007-05-15 Thread Bruce Momjian
Alvaro Herrera wrote: Joshua D. Drake wrote: Also, if I want to discuss renaming something or cleaning up some code, do we create a tracker item for that or do we have a developer email list to discuss such issues? In the most conformist sense yes, but I can tell you that generally

Re: [HACKERS] Seq scans roadmap

2007-05-15 Thread Jeff Davis
On Tue, 2007-05-15 at 10:42 +0100, Heikki Linnakangas wrote: Luke Lonergan wrote: 32 buffers = 1MB with 32KB blocksize, which spoils the CPU L2 cache effect. How about using 256/blocksize? Sounds reasonable. We need to check the effect on the synchronized scans, though. I am a

Re: [HACKERS] Invalid magic number in log file?

2007-05-15 Thread Alvaro Herrera
Gregory Stark wrote: Alvaro Herrera [EMAIL PROTECTED] writes: Gregory Stark wrote: When starting up a postmaster from an older build on a database initialized with a newer build I'm getting the following errors. I think I saw the same thing earlier going in the opposite direction

Re: [HACKERS] Managing the community information stream

2007-05-15 Thread Alvaro Herrera
Bruce Momjian wrote: Alvaro Herrera wrote: In Debian's bug tracking system, when the bug is created (which is done by sending an email to a certain address) it gets a number, and the email is distributed to certain lists. People can then reply to that mail, and send messages to [EMAIL

Re: [HACKERS] Not ready for 8.3

2007-05-15 Thread Josh Berkus
Bruce, Realistically I just don't see getting everything in the ToDo patch list in; my vote is that we start deferring stuff for 8.4 if it doesn't have a reviewer, except for items which were submitted early in the cycle (and to whom it would be unfair). If that means shortening the 8.4

Re: [HACKERS] pg_comparator table diff/sync

2007-05-15 Thread Fabien COELHO
On May 11, 1:16 pm, Erik 2.0 [EMAIL PROTECTED] wrote: Is pg_comparator the only project out there that does what it does? I tried patching it, and it seems OK, but I'm not terribly confident in my patch. I'm hoping someone will tell me there's a great table- driven rsync out there that

Re: [HACKERS] Not ready for 8.3

2007-05-15 Thread Joshua D. Drake
That is not fair to patch submitters, and pushes the problem to 8.4, where it will be no better. If it isn't done, it isn't done. We aren't dropping the patch. The patch has been accepted, just not reviewed. It is just delayed. Sure it is, if we have a short release cycle. There are plenty

Re: [HACKERS] Not ready for 8.3

2007-05-15 Thread Andrew Dunstan
Gregory Stark wrote: Bruce Momjian [EMAIL PROTECTED] writes: I think the only other thing we _could_ do is to re-open normal 8.3 development, so we aren't hampering updates to trivial parts of the code. Many of the patches now in the queue had been developed for months before 8.3 started,

Re: [HACKERS] Managing the community information stream

2007-05-15 Thread Joshua D. Drake
Bruce Momjian wrote: In Debian's bug tracking system, when the bug is created (which is done by sending an email to a certain address) it gets a number, and the email is distributed to certain lists. People can then reply to that mail, and send messages to [EMAIL PROTECTED] and it gets tracked

Re: [HACKERS] Not ready for 8.3

2007-05-15 Thread Oleg Bartunov
We have new patch available http://www.sigaev.ru/misc/tsearch_core-0.47.gz to sync with CVS HEAD. Oleg On Tue, 15 May 2007, Joshua D. Drake wrote: Bruce Momjian wrote: Based on our progress during this feature freeze, we will not complete the feature freeze until August/September. I think

Re: [HACKERS] Not ready for 8.3

2007-05-15 Thread Chris Browne
[EMAIL PROTECTED] (Josh Berkus) writes: Bruce, Realistically I just don't see getting everything in the ToDo patch list in; my vote is that we start deferring stuff for 8.4 if it doesn't have a reviewer, except for items which were submitted early in the cycle (and to whom it would be

Re: [HACKERS] fixing uuid-ossp

2007-05-15 Thread Andrew Dunstan
I wrote: I propose to unbreak this contrib module for machines that don't have uuid.h installed in a directory called ossp (e.g. fc6), by changing #include ossp/uuid.h to #include uuid.h People who *do* have it installed in such a directory can add to the build with a --with-includes

Re: [HACKERS] Not ready for 8.3

2007-05-15 Thread Oleg Bartunov
On Tue, 15 May 2007, Joshua D. Drake wrote: Tsearch2 in core. I know that Tom has some reservations, he I and Treat all commented on how it was done and to my knowledge those reservations have not been resolved. We'd like to know about these reservations. If I understand you mean there are

Re: [HACKERS] Not ready for 8.3

2007-05-15 Thread Stefan Kaltenbrunner
Joshua D. Drake wrote: [...] Concurrent psql, nifty but still trying to decide on actual interface. Full Page Writes Improvement, doesn't actually do anything *yet* (as far as I can tell) it just makes it so something can be done in the future. It is also apparently a small patch. UTF8

Re: [HACKERS] Not ready for 8.3

2007-05-15 Thread Joshua D. Drake
Oleg Bartunov wrote: On Tue, 15 May 2007, Joshua D. Drake wrote: Tsearch2 in core. I know that Tom has some reservations, he I and Treat all commented on how it was done and to my knowledge those reservations have not been resolved. We'd like to know about these reservations. If I

Re: [HACKERS] Not ready for 8.3

2007-05-15 Thread Alvaro Herrera
Stefan Kaltenbrunner wrote: Joshua D. Drake wrote: PL/PSM, link wrong (goes to guc temp_tablespaces). This can certainly be developed outside of core. Don't get me wrong I like the feature but it can take advantage of facilities outside of core. url fixed - I wonder why we had so much

Re: [HACKERS] Not ready for 8.3

2007-05-15 Thread Joshua D. Drake
Alvaro Herrera wrote: Stefan Kaltenbrunner wrote: Joshua D. Drake wrote: PL/PSM, link wrong (goes to guc temp_tablespaces). This can certainly be developed outside of core. Don't get me wrong I like the feature but it can take advantage of facilities outside of core. url fixed - I wonder

Re: [HACKERS] Not ready for 8.3

2007-05-15 Thread Stefan Kaltenbrunner
Alvaro Herrera wrote: Stefan Kaltenbrunner wrote: Joshua D. Drake wrote: PL/PSM, link wrong (goes to guc temp_tablespaces). This can certainly be developed outside of core. Don't get me wrong I like the feature but it can take advantage of facilities outside of core. url fixed - I wonder

Re: [HACKERS] [BUGS] Removing pg_auth_members.grantor (was Grantor name gets lost when grantor role dropped)

2007-05-15 Thread Alvaro Herrera
Alvaro Herrera wrote: Alvaro Herrera wrote: 2. decide that the standard is braindead and just omit dumping the grantor when it's no longer available, but don't remove pg_auth_members.grantor Which do people feel should be implemented? I can do whatever we decide; if no one

Re: [HACKERS] Not ready for 8.3

2007-05-15 Thread Aidan Van Dyk
They are not stable. The items should point to the archives, which are supposedly more stable. (I had already fixed one item in PatchStatus this morning). Really it would be much nicer to have links using the Message-Id but I doubt that's at all doable. I use this all the time:

Re: [HACKERS] Not ready for 8.3

2007-05-15 Thread Alvaro Herrera
Stefan Kaltenbrunner wrote: Alvaro Herrera wrote: Stefan Kaltenbrunner wrote: Joshua D. Drake wrote: PL/PSM, link wrong (goes to guc temp_tablespaces). This can certainly be developed outside of core. Don't get me wrong I like the feature but it can take advantage of facilities

Re: [HACKERS] Not ready for 8.3

2007-05-15 Thread Magnus Hagander
Stefan Kaltenbrunner wrote: They are not stable. The items should point to the archives, which are supposedly more stable. (I had already fixed one item in PatchStatus this morning). Really it would be much nicer to have links using the Message-Id but I doubt that's at all doable. hrm -

Re: [HACKERS] Managing the community information stream

2007-05-15 Thread Bruce Momjian
Alvaro Herrera wrote: Bruce Momjian wrote: Alvaro Herrera wrote: In Debian's bug tracking system, when the bug is created (which is done by sending an email to a certain address) it gets a number, and the email is distributed to certain lists. People can then reply to that mail,

Re: [HACKERS] Managing the community information stream

2007-05-15 Thread Bruce Momjian
Joshua D. Drake wrote: Bruce Momjian wrote: In Debian's bug tracking system, when the bug is created (which is done by sending an email to a certain address) it gets a number, and the email is distributed to certain lists. People can then reply to that mail, and send messages to [EMAIL

Re: [HACKERS] Not ready for 8.3

2007-05-15 Thread Alvaro Herrera
Aidan Van Dyk wrote: They are not stable. The items should point to the archives, which are supposedly more stable. (I had already fixed one item in PatchStatus this morning). Really it would be much nicer to have links using the Message-Id but I doubt that's at all doable. I use

Re: [HACKERS] Not ready for 8.3

2007-05-15 Thread Oleg Bartunov
On Tue, 15 May 2007, Joshua D. Drake wrote: Oleg Bartunov wrote: On Tue, 15 May 2007, Joshua D. Drake wrote: Tsearch2 in core. I know that Tom has some reservations, he I and Treat all commented on how it was done and to my knowledge those reservations have not been resolved. We'd like to

Re: [HACKERS] Not ready for 8.3

2007-05-15 Thread Bruce Momjian
Gregory Stark wrote: Bruce Momjian [EMAIL PROTECTED] writes: I think the only other thing we _could_ do is to re-open normal 8.3 development, so we aren't hampering updates to trivial parts of the code. Many of the patches now in the queue had been developed for months before 8.3

Re: [HACKERS] Not ready for 8.3

2007-05-15 Thread Bruce Momjian
Josh Berkus wrote: Bruce, Realistically I just don't see getting everything in the ToDo patch list in; my vote is that we start deferring stuff for 8.4 if it doesn't have a reviewer, except for items which were submitted early in the cycle (and to whom it would be unfair). It seems

Re: [HACKERS] Not ready for 8.3

2007-05-15 Thread Bruce Momjian
Joshua D. Drake wrote: That is not fair to patch submitters, and pushes the problem to 8.4, where it will be no better. If it isn't done, it isn't done. We aren't dropping the patch. The patch has been accepted, just not reviewed. It is just delayed. Delayed isn't rejected, but it isn't

Re: [HACKERS] Not ready for 8.3

2007-05-15 Thread Bruce Momjian
Andrew Dunstan wrote: I think the only other thing we _could_ do is to re-open normal 8.3 development, so we aren't hampering updates to trivial parts of the code. Many of the patches now in the queue had been developed for months before 8.3 started, so the hope is that we wouldn't have

Re: [HACKERS] Not ready for 8.3

2007-05-15 Thread Alvaro Herrera
Bruce Momjian wrote: Gregory Stark wrote: Bruce Momjian [EMAIL PROTECTED] writes: I think the only other thing we _could_ do is to re-open normal 8.3 development, so we aren't hampering updates to trivial parts of the code. Many of the patches now in the queue had been developed for

Re: [HACKERS] Not ready for 8.3

2007-05-15 Thread Bruce Momjian
Chris Browne wrote: [EMAIL PROTECTED] (Josh Berkus) writes: Bruce, Realistically I just don't see getting everything in the ToDo patch list in; my vote is that we start deferring stuff for 8.4 if it doesn't have a reviewer, except for items which were submitted early in the cycle (and

Re: [HACKERS] Not ready for 8.3

2007-05-15 Thread Joshua D. Drake
Oleg Bartunov wrote: On Tue, 15 May 2007, Joshua D. Drake wrote: Oleg Bartunov wrote: On Tue, 15 May 2007, Joshua D. Drake wrote: Tsearch2 in core. I know that Tom has some reservations, he I and Treat all commented on how it was done and to my knowledge those reservations have not been

Re: [HACKERS] Not ready for 8.3

2007-05-15 Thread Bruce Momjian
Joshua D. Drake wrote: Oleg Bartunov wrote: On Tue, 15 May 2007, Joshua D. Drake wrote: Tsearch2 in core. I know that Tom has some reservations, he I and Treat all commented on how it was done and to my knowledge those reservations have not been resolved. We'd like to know about

Re: [HACKERS] Not ready for 8.3

2007-05-15 Thread Oleg Bartunov
On Tue, 15 May 2007, Joshua D. Drake wrote: Oleg Bartunov wrote: On Tue, 15 May 2007, Joshua D. Drake wrote: Oleg Bartunov wrote: On Tue, 15 May 2007, Joshua D. Drake wrote: Tsearch2 in core. I know that Tom has some reservations, he I and Treat all commented on how it was done and to my

Re: [HACKERS] Not ready for 8.3

2007-05-15 Thread Bruce Momjian
Oleg Bartunov wrote: On Tue, 15 May 2007, Joshua D. Drake wrote: Tsearch2 in core. I know that Tom has some reservations, he I and Treat all commented on how it was done and to my knowledge those reservations have not been resolved. We'd like to know about these reservations. If I

Re: [HACKERS] Not ready for 8.3

2007-05-15 Thread Bruce Momjian
Stefan Kaltenbrunner wrote: PL/PSM, link wrong (goes to guc temp_tablespaces). This can certainly be developed outside of core. Don't get me wrong I like the feature but it can take advantage of facilities outside of core. url fixed - I wonder why we had so much of them and all those

Re: [HACKERS] Not ready for 8.3

2007-05-15 Thread Bruce Momjian
Alvaro Herrera wrote: Stefan Kaltenbrunner wrote: Alvaro Herrera wrote: Stefan Kaltenbrunner wrote: Joshua D. Drake wrote: PL/PSM, link wrong (goes to guc temp_tablespaces). This can certainly be developed outside of core. Don't get me wrong I like the feature but it can take

Re: [HACKERS] Not ready for 8.3

2007-05-15 Thread Alvaro Herrera
Bruce Momjian wrote: Stefan Kaltenbrunner wrote: PL/PSM, link wrong (goes to guc temp_tablespaces). This can certainly be developed outside of core. Don't get me wrong I like the feature but it can take advantage of facilities outside of core. url fixed - I wonder why we had so much

Re: [HACKERS] Not ready for 8.3

2007-05-15 Thread Joshua D. Drake
Bruce Momjian wrote: Oleg Bartunov wrote: This is a good example of how developers can get frustrated. Pushing a patch to 8.4 that was completed before 8.3 feature freeze is guaranteed to add to that --- and if we lose our developers, we might as well shut down the PostgreSQL project. Let's

Re: [HACKERS] Not ready for 8.3

2007-05-15 Thread Joshua D. Drake
Alvaro Herrera wrote: Bruce Momjian wrote: Stefan Kaltenbrunner wrote: PL/PSM, link wrong (goes to guc temp_tablespaces). This can certainly be developed outside of core. Don't get me wrong I like the feature but it can take advantage of facilities outside of core. url fixed - I wonder why we

Re: [HACKERS] Not ready for 8.3

2007-05-15 Thread Bruce Momjian
Joshua D. Drake wrote: Bruce Momjian wrote: Oleg Bartunov wrote: This is a good example of how developers can get frustrated. Pushing a patch to 8.4 that was completed before 8.3 feature freeze is guaranteed to add to that --- and if we lose our developers, we might as well shut down

Re: [HACKERS] Not ready for 8.3

2007-05-15 Thread Joshua D. Drake
Bruce Momjian wrote: Joshua D. Drake wrote: One good thing is that we have community discussion this now, so at least we are focusing on it. Agreed, but it certainly is not a critical mass problem either. We are starting to bounce off the wall, and are starting to take a step back to

Re: [HACKERS] 8.3 pending patch queue

2007-05-15 Thread Bruce Momjian
If people want proof that we have had some patches for months, this email is from Simon from January, 2007. --- Simon Riggs wrote: On Mon, 2007-01-01 at 19:04 -0500, Bruce Momjian wrote: I will start processing the

Re: [HACKERS] Managing the community information stream

2007-05-15 Thread Jim C. Nasby
On Tue, May 15, 2007 at 01:18:42PM -0400, Bruce Momjian wrote: In Debian's bug tracking system, when the bug is created (which is done by sending an email to a certain address) it gets a number, and the email is distributed to certain lists. People can then reply to that mail, and send

Re: [HACKERS] [BUGS] Removing pg_auth_members.grantor (was Grantor name gets lost when grantor role dropped)

2007-05-15 Thread Russell Smith
Alvaro Herrera wrote: Alvaro Herrera wrote: Alvaro Herrera wrote: 2. decide that the standard is braindead and just omit dumping the grantor when it's no longer available, but don't remove pg_auth_members.grantor Which do people feel should be implemented? I can do whatever we

Re: [HACKERS] Seq scans roadmap

2007-05-15 Thread Jim C. Nasby
On Tue, May 15, 2007 at 10:25:35AM -0700, Jeff Davis wrote: On Tue, 2007-05-15 at 10:42 +0100, Heikki Linnakangas wrote: Luke Lonergan wrote: 32 buffers = 1MB with 32KB blocksize, which spoils the CPU L2 cache effect. How about using 256/blocksize? Sounds reasonable. We need

Re: [HACKERS] 8.3 pending patch queue

2007-05-15 Thread Joshua D. Drake
Bruce Momjian wrote: If people want proof that we have had some patches for months, this email is from Simon from January, 2007. I don't think anyone (at least sanely) questions that there are patches hanging out there. Joshua D. Drake

Re: [HACKERS] [BUGS] Removing pg_auth_members.grantor (was Grantor name gets lost when grantor role dropped)

2007-05-15 Thread Russell Smith
Alvaro Herrera wrote: Russell Smith wrote: Alvaro Herrera wrote: Alvaro Herrera wrote: 2. decide that the standard is braindead and just omit dumping the grantor when it's no longer available, but don't remove pg_auth_members.grantor Which do people feel should be

Re: [HACKERS] 8.3 pending patch queue

2007-05-15 Thread Bruce Momjian
Joshua D. Drake wrote: Bruce Momjian wrote: If people want proof that we have had some patches for months, this email is from Simon from January, 2007. I don't think anyone (at least sanely) questions that there are patches hanging out there. My point is that pushing them for 8.4

Re: [HACKERS] Not ready for 8.3

2007-05-15 Thread Jim C. Nasby
On Tue, May 15, 2007 at 12:42:28PM -0400, Bruce Momjian wrote: Joshua D. Drake wrote: Patch status: http://developer.postgresql.org/index.php/Todo:PatchStatus If... this is actually a problem (I leave to other committers and reviewers to comment) then I suggest we push all

Re: [HACKERS] Not ready for 8.3

2007-05-15 Thread Jim C. Nasby
On Tue, May 15, 2007 at 10:32:14PM +0200, Magnus Hagander wrote: Stefan Kaltenbrunner wrote: They are not stable. The items should point to the archives, which are supposedly more stable. (I had already fixed one item in PatchStatus this morning). Really it would be much nicer to have

Re: [HACKERS] Not ready for 8.3

2007-05-15 Thread Bruce Momjian
Jim C. Nasby wrote: On Tue, May 15, 2007 at 12:42:28PM -0400, Bruce Momjian wrote: Joshua D. Drake wrote: Patch status: http://developer.postgresql.org/index.php/Todo:PatchStatus If... this is actually a problem (I leave to other committers and reviewers to

Re: [HACKERS] Not ready for 8.3

2007-05-15 Thread Bruce Momjian
Jim C. Nasby wrote: On Tue, May 15, 2007 at 10:32:14PM +0200, Magnus Hagander wrote: Stefan Kaltenbrunner wrote: They are not stable. The items should point to the archives, which are supposedly more stable. (I had already fixed one item in PatchStatus this morning). Really it would

Re: [HACKERS] Bulk inserts and usage_count

2007-05-15 Thread Jim C. Nasby
On Tue, May 15, 2007 at 04:37:28PM +0100, Heikki Linnakangas wrote: While testing the buffer ring patch, I noticed that bulk inserts with both INSERT and COPY pin and unpin the buffer they insert to for every tuple. That means that the usage_count of all those buffers are bumped snip A fix

Re: [HACKERS] Not ready for 8.3

2007-05-15 Thread Jim C. Nasby
On Tue, May 15, 2007 at 07:01:39PM -0400, Bruce Momjian wrote: Unless you're really in love with doing that sort of thing it's really good that someone else did it. You're one of a handful of folks that can actually review patches, while there's any number of us that can update a wiki.

Re: [HACKERS] Not ready for 8.3

2007-05-15 Thread Bruce Momjian
Jim C. Nasby wrote: On Tue, May 15, 2007 at 07:01:39PM -0400, Bruce Momjian wrote: Unless you're really in love with doing that sort of thing it's really good that someone else did it. You're one of a handful of folks that can actually review patches, while there's any number of us that

Re: [HACKERS] Interaction of PITR backups and Bulkoperationsavoiding WAL

2007-05-15 Thread Bruce Momjian
This has been saved for the 8.4 release: http://momjian.postgresql.org/cgi-bin/pgpatches_hold --- Simon Riggs wrote: On Fri, 2007-03-09 at 11:47 -0500, Tom Lane wrote: Simon Riggs [EMAIL PROTECTED] writes: On

Re: [HACKERS] 8.3 pending patch queue

2007-05-15 Thread Joshua D. Drake
Bruce Momjian wrote: Joshua D. Drake wrote: Bruce Momjian wrote: If people want proof that we have had some patches for months, this email is from Simon from January, 2007. I don't think anyone (at least sanely) questions that there are patches hanging out there. My point is that pushing

Re: [HACKERS] Interaction of PITR backups and Bulkoperationsavoiding WAL

2007-05-15 Thread Jim C. Nasby
Simon intended to commit this per http://archives.postgresql.org/pgsql-hackers/2007-03/msg01761.php (actually, there was a change in what was being done). I suspect this item isn't valid any longer. On Tue, May 15, 2007 at 07:30:58PM -0400, Bruce Momjian wrote: This has been saved for the 8.4

Re: [HACKERS] Interaction of PITR backups and Bulkoperationsavoiding WAL

2007-05-15 Thread Bruce Momjian
OK, removed. --- Jim C. Nasby wrote: Simon intended to commit this per http://archives.postgresql.org/pgsql-hackers/2007-03/msg01761.php (actually, there was a change in what was being done). I suspect this item isn't

Re: [HACKERS] Not ready for 8.3

2007-05-15 Thread Tatsuo Ishii
Stefan Kaltenbrunner wrote: They are not stable. The items should point to the archives, which are supposedly more stable. (I had already fixed one item in PatchStatus this morning). Really it would be much nicer to have links using the Message-Id but I doubt that's at all doable.

Re: [HACKERS] [PATCHES] Reviewers Guide to DeferredTransactions/TransactionGuarantee

2007-05-15 Thread Bruce Momjian
Simon Riggs wrote: On Thu, 2007-04-26 at 21:14 -0400, Bruce Momjian wrote: Simon Riggs wrote: That should go away entirely; to me the main point of the separate wal-writer process is to take over responsibility for not letting too many dirty wal buffers accumulate. Yes

Re: [HACKERS] Not ready for 8.3

2007-05-15 Thread Nathan Buchanan
On 5/15/07, Tatsuo Ishii [EMAIL PROTECTED] wrote: Stefan Kaltenbrunner wrote: They are not stable. The items should point to the archives, which are supposedly more stable. (I had already fixed one item in PatchStatus this morning). Really it would be much nicer to have links using

Re: [HACKERS] [PATCHES] Reviewers Guide to Deferred Transactions/TransactionGuarantee

2007-05-15 Thread Bruce Momjian
Simon Riggs wrote: 3. Should the WALWriter also do the wal_buffers half-full write at the start of XLogInsert() ? That should go away entirely; to me the main point of the separate wal-writer process is to take over responsibility for not letting too many dirty wal buffers

Re: [HACKERS] Seq scans roadmap

2007-05-15 Thread Heikki Linnakangas
Jeff Davis wrote: On Tue, 2007-05-15 at 10:42 +0100, Heikki Linnakangas wrote: Luke Lonergan wrote: 32 buffers = 1MB with 32KB blocksize, which spoils the CPU L2 cache effect. How about using 256/blocksize? Sounds reasonable. We need to check the effect on the synchronized scans, though.

Re: [HACKERS] Not ready for 8.3

2007-05-15 Thread Bruce Momjian
Tatsuo Ishii wrote: Stefan Kaltenbrunner wrote: They are not stable. The items should point to the archives, which are supposedly more stable. (I had already fixed one item in PatchStatus this morning). Really it would be much nicer to have links using the Message-Id but I doubt

Re: [HACKERS] Not ready for 8.3

2007-05-15 Thread Robert Treat
On Tuesday 15 May 2007 16:48, Bruce Momjian wrote: Joshua D. Drake wrote: That is not fair to patch submitters, and pushes the problem to 8.4, where it will be no better. If it isn't done, it isn't done. We aren't dropping the patch. The patch has been accepted, just not reviewed. It

[HACKERS] Error correction for n_dead_tuples

2007-05-15 Thread ITAGAKI Takahiro
Tom Lane [EMAIL PROTECTED] wrote: I'm concerned that this one creates an open-loop behavior in which the n_dead_tuples estimate will diverge arbitrarily far from reality over time. I criticized the original proposal on that basis, and I'm not convinced this version fixes it, because of the

Re: [HACKERS] 8.3 pending patch queue

2007-05-15 Thread Marc G. Fournier
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - --On Tuesday, May 15, 2007 16:33:32 -0700 Joshua D. Drake [EMAIL PROTECTED] wrote: If the developers were to actually take a step back and say, Hey... instead of working on these dozen different features, I should work on three and help

Re: [HACKERS] Not ready for 8.3

2007-05-15 Thread Josh Berkus
Bruce, It seems unfair to disinguish between early/last in cycle postings. I think it's fair. A patch which was submitted for 8.2 and didn't get in should get consideration over a patch which was still in prototype form a week before feature freeze. Also, I really don't think it's a crime

Re: [HACKERS] Not ready for 8.3

2007-05-15 Thread Tatsuo Ishii
Tatsuo Ishii wrote: Stefan Kaltenbrunner wrote: They are not stable. The items should point to the archives, which are supposedly more stable. (I had already fixed one item in PatchStatus this morning). Really it would be much nicer to have links using the Message-Id but I

Re: [HACKERS] Not ready for 8.3

2007-05-15 Thread Andrew Dunstan
Josh Berkus wrote: Yea, this is just pushing off work until later, which I don't support. There is no easy out here and I am afraid we will just have to accept a 3-month feature freeze. I think that may be where we're heading. In that case, we may need to talk about branching earlier