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

[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 both pgsql and buildfarm that should in
> combination cure this, I hope. Please test - there might still be loose
> ends hanging around.

OK, thanks.

Regards, Dave.

---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate

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

[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 strong opinion on the matter, my opinion is we
do (2) which is the easiest.



Here is a patch implementing this idea, vaguely based on Russell's.
  


I haven't had time to finalize my research about this, but the admin 
option with revoke doesn't appear to work as expected.


Here is my sample SQL for 8.2.4

create table test (x integer);
\z
create role test1 noinherit;
create role test2 noinherit;
grant select on test to test1 with grant option;
grant select on test to test2;
\z test
set role test1;
revoke select on test from test2;
\z test
set role test2;
select * from test;
reset role;
revoke all on test from test2;
revoke all on test from test1;
drop role test2;
drop role test1;
drop table test;
\q


The privilege doesn't appear to be revoked by test1 from test2.  I'm not 
sure if this is related, but I wanted to bring it up in light of the 
options we have for grantor.



---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings

Re: [HACKERS] Seq scans roadmap

[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 differently sized rings.


I said earlier that it'd be invasive change to see if a buffer needs a 
WAL flush and choose another victim if that's the case. I looked at it 
again and found a pretty clean way of doing that, so I took that 
approach for seq scans.


1. For VACUUM, use a ring of 32 buffers. 32 buffers is small enough to 
give the L2 cache benefits and keep cache pollution low, but at the same 
time it's large enough that it keeps the need to WAL flush reasonable 
(1/32 of what we do now).


2. For sequential scans, also use a ring of 32 buffers, but whenever a 
buffer in the ring would need a WAL flush to recycle, we throw it out of 
the buffer ring instead. On read-only scans (and scans that only update 
hint bit) this gives the L2 cache benefits and doesn't pollute the 
buffer cache. On bulk updates, it's effectively the current behavior. On 
scans that do some updates, it's something in between. In all cases it 
should be no worse than what we have now. 32 buffers should be large 
enough to leave a "cache trail" for Jeff's synchronized scans to work.


3. For COPY that doesn't write WAL, use the same strategy as for 
sequential scans. This keeps the cache pollution low and gives the L2 
cache benefits.


4. For COPY that writes WAL, use a large ring of 2048-4096 buffers. We 
want to use a ring that can accommodate 1 WAL segment worth of data, to 
avoid having to do any extra WAL flushes, and the WAL segment size is 
2048 pages in the default configuration.


Some alternatives I considered but rejected:

* Instead of throwing away dirtied buffers in seq scans, accumulate them 
in another fixed sized list. When the list gets full, do a WAL flush and 
put them to the shared freelist or a backend-private freelist. That 
would eliminate the cache pollution of bulk DELETEs and bulk UPDATEs, 
and it could be used for vacuum as well. I think this would be the 
optimal algorithm but I don't feel like inventing something that 
complicated at this stage anymore. Maybe for 8.4.


* Using a different sized ring for 1st and 2nd vacuum phase. Decided 
that it's not worth the trouble, the above is already an order of 
magnitude better than the current behavior.



I'm going to rerun the performance tests I ran earlier with new patch, 
tidy it up a bit, and submit it in the next few days. This turned out to 
be even more laborious patch to review than I thought. While the patch 
is short and in the end turned out to be very close to Simon's original 
patch, there's many different usage scenarios that need to be catered 
for and tested.


I still need to check the interaction with Jeff's patch. This is close 
enough to Simon's original patch that I believe the results of the tests 
Jeff ran earlier are still valid.


--
  Heikki Linnakangas
  EnterpriseDB   http://www.enterprisedb.com

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster

Re: [HACKERS] Seq scans roadmap

[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: PostgreSQL-development
> Cc: Simon Riggs; Zeugswetter Andreas ADI SD; CK.Tan; Luke 
> Lonergan; Jeff Davis
> Subject: Re: [HACKERS] Seq scans roadmap
> 
> 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 
> differently sized rings.
> 
> I said earlier that it'd be invasive change to see if a 
> buffer needs a WAL flush and choose another victim if that's 
> the case. I looked at it again and found a pretty clean way 
> of doing that, so I took that approach for seq scans.
> 
> 1. For VACUUM, use a ring of 32 buffers. 32 buffers is small 
> enough to give the L2 cache benefits and keep cache pollution 
> low, but at the same time it's large enough that it keeps the 
> need to WAL flush reasonable
> (1/32 of what we do now).
> 
> 2. For sequential scans, also use a ring of 32 buffers, but 
> whenever a buffer in the ring would need a WAL flush to 
> recycle, we throw it out of the buffer ring instead. On 
> read-only scans (and scans that only update hint bit) this 
> gives the L2 cache benefits and doesn't pollute the buffer 
> cache. On bulk updates, it's effectively the current 
> behavior. On scans that do some updates, it's something in 
> between. In all cases it should be no worse than what we have 
> now. 32 buffers should be large enough to leave a "cache 
> trail" for Jeff's synchronized scans to work.
> 
> 3. For COPY that doesn't write WAL, use the same strategy as 
> for sequential scans. This keeps the cache pollution low and 
> gives the L2 cache benefits.
> 
> 4. For COPY that writes WAL, use a large ring of 2048-4096 
> buffers. We want to use a ring that can accommodate 1 WAL 
> segment worth of data, to avoid having to do any extra WAL 
> flushes, and the WAL segment size is
> 2048 pages in the default configuration.
> 
> Some alternatives I considered but rejected:
> 
> * Instead of throwing away dirtied buffers in seq scans, 
> accumulate them in another fixed sized list. When the list 
> gets full, do a WAL flush and put them to the shared freelist 
> or a backend-private freelist. That would eliminate the cache 
> pollution of bulk DELETEs and bulk UPDATEs, and it could be 
> used for vacuum as well. I think this would be the optimal 
> algorithm but I don't feel like inventing something that 
> complicated at this stage anymore. Maybe for 8.4.
> 
> * Using a different sized ring for 1st and 2nd vacuum phase. 
> Decided that it's not worth the trouble, the above is already 
> an order of magnitude better than the current behavior.
> 
> 
> I'm going to rerun the performance tests I ran earlier with 
> new patch, tidy it up a bit, and submit it in the next few 
> days. This turned out to be even more laborious patch to 
> review than I thought. While the patch is short and in the 
> end turned out to be very close to Simon's original patch, 
> there's many different usage scenarios that need to be 
> catered for and tested.
> 
> I still need to check the interaction with Jeff's patch. This 
> is close enough to Simon's original patch that I believe the 
> results of the tests Jeff ran earlier are still valid.
> 
> -- 
>Heikki Linnakangas
>EnterpriseDB   http://www.enterprisedb.com
> 
> 


---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
   choose an index scan if your joining column's datatypes do not
   match

Re: [HACKERS] Seq scans roadmap

[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

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings

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

[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 the error code is comming from and I'm trying
to narrow it down a bit.

Thanks.

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 PROTECTED]
Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!
--- pgtypeslib/datetime.c	2006-10-04 09:37:59.0 +0200
+++ datetime.c	2007-05-15 12:31:56.0 +0200
@@ -74,6 +74,7 @@
 		errno = PGTYPES_DATE_BAD_DATE;
 		return INT_MIN;
 	}
+	printf("1: errno = %d\n", errno);
 
 	if (ParseDateTime(str, lowstr, field, ftype, MAXDATEFIELDS, &nf, ptr) != 0 ||
 	DecodeDateTime(field, ftype, nf, &dtype, tm, &fsec, &tzp, EuroDates) != 0)
@@ -81,6 +82,7 @@
 		errno = PGTYPES_DATE_BAD_DATE;
 		return INT_MIN;
 	}
+	printf("2: errno = %d\n", errno);
 
 	switch (dtype)
 	{
@@ -95,8 +97,10 @@
 			errno = PGTYPES_DATE_BAD_DATE;
 			return INT_MIN;
 	}
+	printf("3: errno = %d\n", errno);
 
 	dDate = (date2j(tm->tm_year, tm->tm_mon, tm->tm_mday) - date2j(2000, 1, 1));
+	printf("4: errno = %d\n", errno);
 
 	return dDate;
 }

---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org

[HACKERS] Invalid magic number in log file?

[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 PROTECTED]:~$ /usr/local/pgsql/bin/postgres -D /var/tmp/db
LOG:  database system was shut down at 2007-05-14 19:47:51 BST
LOG:  invalid magic number D061 in log file 0, segment 0, offset 0
LOG:  invalid primary checkpoint record
LOG:  invalid magic number D061 in log file 0, segment 0, offset 0
LOG:  invalid secondary checkpoint record
PANIC:  could not locate a valid checkpoint record
LOG:  startup process (PID 9590) was terminated by signal 6: Aborted
LOG:  aborting startup due to startup process failure


-- 
  Gregory Stark
  EnterpriseDB  http://www.enterprisedb.com


---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org

[HACKERS] fixing uuid-ossp

[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 
to
 #include 

People who *do* have it installed in such a directory can add to the 
build with a --with-includes configure directive.


If someone feels like fixing this using some configure magic calling 
uuid-config in a similar way to the way we use tclConfig.sh, that might 
be nice, but I don't have time right now.


cheers

andrew

---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at

   http://www.postgresql.org/about/donate

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

[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 version number?
> 
> [EMAIL PROTECTED]:~$ /usr/local/pgsql/bin/postgres -D /var/tmp/db
> LOG:  database system was shut down at 2007-05-14 19:47:51 BST
> LOG:  invalid magic number D061 in log file 0, segment 0, offset 0
> LOG:  invalid primary checkpoint record
> LOG:  invalid magic number D061 in log file 0, segment 0, offset 0
> LOG:  invalid secondary checkpoint record
> PANIC:  could not locate a valid checkpoint record
> LOG:  startup process (PID 9590) was terminated by signal 6: Aborted
> LOG:  aborting startup due to startup process failure

Huh, works for me, what versions were those?

-- 
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings

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

[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
> >>decide; if no one has a strong opinion on the matter, my opinion is we
> >>do (2) which is the easiest.
> >
> >Here is a patch implementing this idea, vaguely based on Russell's.
> 
> I haven't had time to finalize my research about this, but the admin 
> option with revoke doesn't appear to work as expected.
> 
> Here is my sample SQL for 8.2.4
> 
> create table test (x integer);
> \z
> create role test1 noinherit;
> create role test2 noinherit;
> grant select on test to test1 with grant option;
> grant select on test to test2;
> \z test
> set role test1;
> revoke select on test from test2;
> \z test
> set role test2;
> select * from test;
> reset role;
> revoke all on test from test2;
> revoke all on test from test1;
> drop role test2;
> drop role test1;
> drop table test;
> \q
> 
> 
> The privilege doesn't appear to be revoked by test1 from test2.  I'm not 
> sure if this is related, but I wanted to bring it up in light of the 
> options we have for grantor.

Humm, but the privilege was not granted by test1, but by the user you
were using initially.  The docs state in a note that

A user can only revoke privileges that were granted directly by
that user.

I understand that this would apply to the grantor stuff being discussed
in this thread as well, but I haven't seen anyone arguing that we should
implement that for GRANT ROLE (and I asked three times if people felt it
was important and nobody answered).

-- 
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
   subscribe-nomail command to [EMAIL PROTECTED] so that your
   message can get through to the mailing list cleanly

Re: [HACKERS] Managing the community information stream

[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 some code,
do we create a tracker item for that or do we have a developer email
list to discuss such issues?  And if we have a developer email list, how
do we make sure everything that happens there gets into the tracker if
needed?

Basically, right now, the steam ignores non-TODO items that are
discussed, while with a trackers, I am afraid you have to explicitly
mark every discussion thread as uninteresting/closed, and I am worried
about the manpower and participant overhead of doing that.

---

bruce wrote:
> Let me give you my approach to tracking.  It might help set the stage
> for moving forward.  My goal has always been to foster discussion and
> pull as many TODO items and patches from the discussion as possible (and
> others do that as well by saying "Please add to TODO" or applying
> patches).
> 
> I see the process much more as pulling things from a stream of data,
> rather than tracking every event.  We already record everything in the
> archive.  The current discussion is how and who should summarize/track
> that information.
> 
> Right now, the TODO list is a good summary, and URLs help to give
> detail.  I am not sure seeing all treads of a TODO item would help.  In
> a way, the summarization is more valuable than the details for most
> people.  Again, the question is what is the cost of summarizing the
> stream at a more detailed level vs. its value.
> 
> Because I see us operating on a stream, it is unclear when to
> pull an item from the stream and track it off-stream, such as in a bug
> tracker database.  I am also concerned that tracking itself not inhibit
> the volume of the stream, particularly if discussion participants have
> to do something more difficult than what they do now.
> 
> The idea of the patch number in the subject line works with that
> streaming model because it merely marks streams so they can be grouped.
> The defining event that marks the stream is a post to the patches list.
> We already number posts to the bugs list, so in a way we could improve
> tracking there and somehow link it to TODO items and patch submissions,
> but because many TODO items are not the result of bug reports but come
> out of general discussions, I am not sure tracking would work as well
> there.  And what about features?  Do you start assigning numbers there,
> and what is your trigger event?  In my opinion, as you start trying to
> place more structure on the stream, the stream itself starts to degrade
> in its dynamism and ease of use.  To me, that is the fundamental issue,
> and risk.
> 
> I think a lot of this relates to the volume of work we do per
> participant.  I think we are probably near the top for open source
> projects, and while more detailed tracking might help, it also might
> hurt.  
> 
> I am hoping the "stream" analogy might help people understand why we do
> what we do, why we are so successful, and how we can improve what we
> currently have.
> 
> --
>   Bruce Momjian  <[EMAIL PROTECTED]>  http://momjian.us
>   EnterpriseDB   http://www.enterprisedb.com
> 
>   + If your life is a hard drive, Christ can be your backup. +

-- 
  Bruce Momjian  <[EMAIL PROTECTED]>  http://momjian.us
  EnterpriseDB   http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster

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

[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
>> earlier errors firing from the control file version number?
>> 
>> [EMAIL PROTECTED]:~$ /usr/local/pgsql/bin/postgres -D /var/tmp/db
>> LOG:  database system was shut down at 2007-05-14 19:47:51 BST
>> LOG:  invalid magic number D061 in log file 0, segment 0, offset 0
>> LOG:  invalid primary checkpoint record
>> LOG:  invalid magic number D061 in log file 0, segment 0, offset 0
>> LOG:  invalid secondary checkpoint record
>> PANIC:  could not locate a valid checkpoint record
>> LOG:  startup process (PID 9590) was terminated by signal 6: Aborted
>> LOG:  aborting startup due to startup process failure
>
> Huh, works for me, what versions were those?

Well it's cvs HEAD and a checkout from May 1st.


-- 
  Gregory Stark
  EnterpriseDB  http://www.enterprisedb.com


---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
   subscribe-nomail command to [EMAIL PROTECTED] so that your
   message can get through to the mailing list cleanly

[HACKERS] Not ready for 8.3

[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 10x more
progress than we have had, which is unlikely.

We could ship what is in CVS now, but that just pushes the patches for
8.4, and isn't fair to patch submitters.  We could shove what we have
now into CVS, but that is unwise.

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 many more new
large patches, but several small ones we could deal with while we
whittle away at the larger patches during the next few months.

The question is whether it is healthy for us to remain in feature freeze
for months, and if it is unhealthy, what are our options?

Patch status:

http://developer.postgresql.org/index.php/Todo:PatchStatus

-- 
  Bruce Momjian  <[EMAIL PROTECTED]>  http://momjian.us
  EnterpriseDB   http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
   subscribe-nomail command to [EMAIL PROTECTED] so that your
   message can get through to the mailing list cleanly

[HACKERS] Bulk inserts and usage_count

[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 activity. It also affects tables like TPC-C order_line where a 
tuples are always inserted and updated in groups.


To demonstrate:

postgres=# truncate foo; TRUNCATE TABLE
postgres=# COPY foo FROM '/tmp/foo.data'; COPY 1000
postgres=# SELECT c.relname, bufferid, relblocknumber, isdirty, 
usagecount FROM pg_buffercache bc, pg_class c WHERE c.relfilenode = 
bc.relfilenode and c.relname='foo';

 relname | bufferid | relblocknumber | isdirty | usagecount
-+--++-+
 foo |   105078 |  4 | f   |  5
 foo |   105079 |  3 | f   |  5
 foo |   105080 |  2 | f   |  5
 foo |   105081 |  1 | f   |  5
 foo |   105082 |  0 | f   |  5
(5 rows)

A fix for COPY will fall naturally out of the buffer ring patch, but not 
for INSERT.


A more general fix would be to somehow keep the last insertion page 
pinned across calls to heap_insert.


--
  Heikki Linnakangas
  EnterpriseDB   http://www.enterprisedb.com

---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
  subscribe-nomail command to [EMAIL PROTECTED] so that your
  message can get through to the mailing list cleanly

Re: [HACKERS] Not ready for 8.3

[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 wouldn't have many more new
> large patches, but several small ones we could deal with while we
> whittle away at the larger patches during the next few months.
>
> The question is whether it is healthy for us to remain in feature freeze
> for months, and if it is unhealthy, what are our options?

I don't see any reason development has to stop while the tree is in feature
freeze. If it led to patches being ready for review and getting reviewed and
committed early in the cycle rather than just before release I think it would
actually be extremely healthy.

-- 
  Gregory Stark
  EnterpriseDB  http://www.enterprisedb.com


---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings

Re: [HACKERS] Not ready for 8.3

[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 anywhere near July, we need 10x more
progress than we have had, which is unlikely.


Or we have another short release cycle, basically accepting what we have 
now that can be worked through in the next 3 weeks and committed. If it 
can't be done in that time, it waits. Then we have beta etc...




We could ship what is in CVS now, but that just pushes the patches for
8.4, and isn't fair to patch submitters.  We could shove what we have
now into CVS, but that is unwise.


Sure it is, if we have a short release cycle. There are plenty of things 
out there that are not quite ready yet, that could be if we released 
again next January...





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


Gah, that sounds like a horrible solution. Sorry Bruce.



The question is whether it is healthy for us to remain in feature freeze
for months, and if it is unhealthy, what are our options?

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 patches that have confirmed reviewers to be worked 
through.


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.


Sincerely,

Joshua D. Drake




---(end of broadcast)---
TIP 4: Have you searched our list archives?

  http://archives.postgresql.org

Re: [HACKERS] Concurrently updating an updatable view

[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 suspicious if UPDATABLE VIEWS can be implemented
 using the rule system.


Remember this affects all self-referential joins on an UPDATE (and 
DELETE?) not just views. It's just that a rule is more likely to produce 
that type of query.


--
  Richard Huxton
  Archonet Ltd

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings

Re: [HACKERS] Managing the community information stream

[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 warrants a todo, we create a todo.



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 we general do it, is to create a ticket basic 
on a topic, that ticket cc's a mailing list and discussion happens in 
reply to that cc. So the workflow doesn't actually change. Once 
everything is decided we may update the ticket with the final solution, 
and then when the work is done we close the ticket.


However, we do it the way we do, because we don't have email 
integration. Supposedly (which a small group is currently reviewing) BZ 
3.0 does have email integration so this may change a bit.



And if we have a developer email list, how
do we make sure everything that happens there gets into the tracker if
needed?


See above.



Basically, right now, the steam ignores non-TODO items that are
discussed, while with a trackers, I am afraid you have to explicitly
mark every discussion thread as uninteresting/closed, and I am worried
about the manpower and participant overhead of doing that.


Oh good lord, yeah I wouldn't want to do that either. Email is obviously 
going to be the predominant medium of communication. I think what would 
end up happening, if we were able to tightly integrate with email and bz 
would that at some point all discussions die off, it would be up to the 
person that opened the discussion or an bz admin to close or change the 
status of the ticket.


The nice thing is if someone comes back to the thread at any point 
(which happens all the time) the ticket should automatically re-open.


Joshua D. Drake




---

bruce wrote:

Let me give you my approach to tracking.  It might help set the stage
for moving forward.  My goal has always been to foster discussion and
pull as many TODO items and patches from the discussion as possible (and
others do that as well by saying "Please add to TODO" or applying
patches).

I see the process much more as pulling things from a stream of data,
rather than tracking every event.  We already record everything in the
archive.  The current discussion is how and who should summarize/track
that information.

Right now, the TODO list is a good summary, and URLs help to give
detail.  I am not sure seeing all treads of a TODO item would help.  In
a way, the summarization is more valuable than the details for most
people.  Again, the question is what is the cost of summarizing the
stream at a more detailed level vs. its value.

Because I see us operating on a stream, it is unclear when to
pull an item from the stream and track it off-stream, such as in a bug
tracker database.  I am also concerned that tracking itself not inhibit
the volume of the stream, particularly if discussion participants have
to do something more difficult than what they do now.

The idea of the patch number in the subject line works with that
streaming model because it merely marks streams so they can be grouped.
The defining event that marks the stream is a post to the patches list.
We already number posts to the bugs list, so in a way we could improve
tracking there and somehow link it to TODO items and patch submissions,
but because many TODO items are not the result of bug reports but come
out of general discussions, I am not sure tracking would work as well
there.  And what about features?  Do you start assigning numbers there,
and what is your trigger event?  In my opinion, as you start trying to
place more structure on the stream, the stream itself starts to degrade
in its dynamism and ease of use.  To me, that is the fundamental issue,
and risk.

I think a lot of this relates to the volume of work we do per
participant.  I think we are probably near the top for open source
projects, and while more detailed tracking might help, it also might
hurt.  


I am hoping the "stream" analogy might help people understand why we do
what we do, why we are so successful, and how we can improve what we
currently have.

--
  Bruce Momjian  <[EMAIL PROTECTED]>  http://momjian.us
  EnterpriseDB   http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +





---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
  subscribe-nomail command to [EMAIL PROTECTED] so that your
  message can get through to the mailing list cleanly

Re: [HACKERS] Concurrently updating an updatable view

[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
 kind of updates. I'm suspicious if UPDATABLE VIEWS can be implemented
 using the rule system.


Remember this affects all self-referential joins on an UPDATE (and 
DELETE?) not just views. It's just that a rule is more likely to produce 
that type of query.


Is there consensus what the correct behaviour should be for
self-referential updates in read-committed mode? Does the SQL Spec
have anything to say about this?

greetings, Florian Pflug


---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
  subscribe-nomail command to [EMAIL PROTECTED] so that your
  message can get through to the mailing list cleanly

Re: [HACKERS] Not ready for 8.3

[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.
> > 
> > Basically, to make a release anywhere near July, we need 10x more
> > progress than we have had, which is unlikely.
> 
> Or we have another short release cycle, basically accepting what we have 
> now that can be worked through in the next 3 weeks and committed. If it 
> can't be done in that time, it waits. Then we have beta etc...

That is not fair to patch submitters, and pushes the problem to 8.4,
where it will be no better.

> > We could ship what is in CVS now, but that just pushes the patches for
> > 8.4, and isn't fair to patch submitters.  We could shove what we have
> > now into CVS, but that is unwise.
> 
> Sure it is, if we have a short release cycle. There are plenty of things 
> out there that are not quite ready yet, that could be if we released 
> again next January...

Huh, you didn't answer my issue about unfair.

> > The question is whether it is healthy for us to remain in feature freeze
> > for months, and if it is unhealthy, what are our options?
> > 
> > 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 patches that have confirmed reviewers to be worked 
> through.
> 
> 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.

Fairness and not pushing our problems out to the future --- address
those issues.

-- 
  Bruce Momjian  <[EMAIL PROTECTED]>  http://momjian.us
  EnterpriseDB   http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq

Re: [HACKERS] Not ready for 8.3

[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 patches that have confirmed reviewers to be worked 
> through.
> 
> 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.

I did one of those for previous releases.  I guess you forgot.  It was
done by someone else this time only because I was going to be traveling.

-- 
  Bruce Momjian  <[EMAIL PROTECTED]>  http://momjian.us
  EnterpriseDB   http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

---(end of broadcast)---
TIP 6: explain analyze is your friend

Re: [HACKERS] Managing the community information stream

[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 we general do it, is to create a ticket basic 
> on a topic, that ticket cc's a mailing list and discussion happens in 
> reply to that cc. So the workflow doesn't actually change. Once 
> everything is decided we may update the ticket with the final solution, 
> and then when the work is done we close the ticket.
> 
> However, we do it the way we do, because we don't have email 
> integration. Supposedly (which a small group is currently reviewing) BZ 
> 3.0 does have email integration so this may change a bit.

Well, with email integration (as I am envisioning -- I don't know what
BZ actually implements) it is even better, because you just create a
ticket, and that sends an email to the list.  Other people can respond
to that email, which gets saved into the bug without need for further
action.

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 in
the bug, and you can see all those messages in the bug report.  I
ass-ume that BZ 3.0 does something similar.

-- 
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
   subscribe-nomail command to [EMAIL PROTECTED] so that your
   message can get through to the mailing list cleanly

Re: [HACKERS] Not ready for 8.3

[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
>> > radically change our work process.
>> > 
>> > Basically, to make a release anywhere near July, we need 10x more
>> > progress than we have had, which is unlikely.
>> 
>> Or we have another short release cycle, basically accepting what we have 
>> now that can be worked through in the next 3 weeks and committed. If it 
>> can't be done in that time, it waits. Then we have beta etc...
>
> That is not fair to patch submitters, and pushes the problem to 8.4,
> where it will be no better.

It's nice to be fair but it's not really the goal here.

However I think the latter point is key. This *was* a short release cycle. If
we push off these patches to later there's no reason to think the situation
will be any different in a few months.

I suspect as much as Tom finds reviewing boring he would rather get it out of
the way and then have a chance to do development before more major patches
arrive than start the new cycle with major patches sitting in the review queue
and spend the whole cycle reviewing them.

As much as I hate that the patches sit in the queue until feature freeze
there's nothing else that will really force us to make a yea or nay decision
on them. If we start the next release with things in the patch queue they're
liable to sit there with no feedback for months again.

I think the key here is to give feedback for the authors but not allow the
time to respond to that feedback to grow. If you review a patch and find
problems with it and there's only three weeks for the author to deal with
those problems and it's not enough time then he can deal with them and submit
it for next release. But letting the patch ride over without giving any
feedback just seems pointless.

-- 
  Gregory Stark
  EnterpriseDB  http://www.enterprisedb.com


---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
   choose an index scan if your joining column's datatypes do not
   match

Re: [HACKERS] Not ready for 8.3

[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 simply went ahead and did it:

http://archives.postgresql.org/pgsql-hackers/2007-05/msg00265.php


Stefan

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster

Re: [HACKERS] Managing the community information stream

[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 
> > isn't how CMD does it. How we general do it, is to create a ticket basic 
> > on a topic, that ticket cc's a mailing list and discussion happens in 
> > reply to that cc. So the workflow doesn't actually change. Once 
> > everything is decided we may update the ticket with the final solution, 
> > and then when the work is done we close the ticket.
> > 
> > However, we do it the way we do, because we don't have email 
> > integration. Supposedly (which a small group is currently reviewing) BZ 
> > 3.0 does have email integration so this may change a bit.
> 
> Well, with email integration (as I am envisioning -- I don't know what
> BZ actually implements) it is even better, because you just create a
> ticket, and that sends an email to the list.  Other people can respond
> to that email, which gets saved into the bug without need for further
> action.
> 
> 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 in
> the bug, and you can see all those messages in the bug report.  I
> ass-ume that BZ 3.0 does something similar.

But often a TODO item has multiple threads containing details (often
months apart), and it isn't obvious at the time the thread is started
that this will happen.  Note the number of TODO items that now have
multiple URLs.  How is that handled?

-- 
  Bruce Momjian  <[EMAIL PROTECTED]>  http://momjian.us
  EnterpriseDB   http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
   subscribe-nomail command to [EMAIL PROTECTED] so that your
   message can get through to the mailing list cleanly

Re: [HACKERS] Seq scans roadmap

[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 little worried that there will be greater differences in position
as the number of scans increase. If we have only 8 buffers and several
scans progressing, will they all be able to stay within a few buffers of
eachother at any given time?

Also, with 8 buffers, that means each scan must report every 4 pages at
most (and maybe every page), which increases lock contention (the new
design Heikki and I discussed requires a lock every time a backend
reports its position).

Regards,
Jeff Davis


---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster

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

[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 too. Shouldn't there be some
> >> earlier errors firing from the control file version number?
> >> 
> >> [EMAIL PROTECTED]:~$ /usr/local/pgsql/bin/postgres -D /var/tmp/db
> >> LOG:  database system was shut down at 2007-05-14 19:47:51 BST
> >> LOG:  invalid magic number D061 in log file 0, segment 0, offset 0
> >> LOG:  invalid primary checkpoint record
> >> LOG:  invalid magic number D061 in log file 0, segment 0, offset 0
> >> LOG:  invalid secondary checkpoint record
> >> PANIC:  could not locate a valid checkpoint record
> >> LOG:  startup process (PID 9590) was terminated by signal 6: Aborted
> >> LOG:  aborting startup due to startup process failure
> >
> > Huh, works for me, what versions were those?
> 
> Well it's cvs HEAD and a checkout from May 1st.

It was changed in 1.20 of xlog_internal.h.  That particular changeset
didn't include a catversion bump nor pg_control magic version change.
I think the rationale here is that it was only a change in WAL format,
so it shouldn't affect either -- it did change the WAL magic.

Maybe the thing to do here is to disallow running a postmaster when the
data dir is using a different WAL magic (forcing you to pg_resetxlog or
initdb).  Does it work if you do a pg_resetxlog and restart?


2007-04-30 17:01  tgl

* src/: backend/access/transam/twophase.c (1.30),
  backend/access/transam/xact.c (1.242),
  backend/access/transam/xlog.c (1.268),
  backend/utils/adt/timestamp.c (1.176), include/access/xact.h
  (1.87), include/access/xlog_internal.h (1.20),
  include/utils/timestamp.h (1.69):

Change the timestamps recorded in transaction commit/abort xlog records
from time_t to TimestampTz representation.  This provides full gettimeofday()
resolution of the timestamps, which might be useful when attempting to
do point-in-time recovery --- previously it was not possible to specify
the stop point with sub-second resolution.  But mostly this is to get
rid of TimestampTz-to-time_t conversion overhead during commit.  Per my
proposal of a day or two back.



-- 
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster

Re: [HACKERS] Managing the community information stream

[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 PROTECTED] and it gets tracked in
> > the bug, and you can see all those messages in the bug report.  I
> > ass-ume that BZ 3.0 does something similar.
> 
> But often a TODO item has multiple threads containing details (often
> months apart), and it isn't obvious at the time the thread is started
> that this will happen.  Note the number of TODO items that now have
> multiple URLs.  How is that handled?

Just add the bug address to CC and reply to it, just like when you reply
to say "added to TODO", only that you don't need to manually go and
modify the TODO file by hand.  The bug tracking system puts that mail
into the bug report.  Subsequent followups keep the bug address in CC
and thus the whole discussion is saved in the bug report.

This is even better than our archives due to the problem that the
archives don't have links to messages crossing month boundaries.  Have
you noticed that if you go to the archives, some discussions appear
truncated at a point, but you can go to the archive for the next month
and it continues there?  I find that artifact somewhat annoying.  The
bug report would continue receiving the CC'ed mails, so it would record
them all in a single place.

-- 
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org

Re: [HACKERS] Not ready for 8.3

[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 cycle somewhat, I'm for that ... feature 
freeze in Feburary would be even better than April, because it means we could 
be in Beta for the May-June-July conferences, and increase our probability of 
being able to release at a major conference or PostgreSQL conference.

Obviously for 8.4 reviewers need to start reviewing stuff from the first week 
of the development cycle.  I also don't actually see anything wrong with a 
3-month feature freeze if we can somehow branch development earlier.  Easy 
for me to say, I know. 

-- 
Josh Berkus
PostgreSQL @ Sun
San Francisco

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings

Re: [HACKERS] pg_comparator table diff/sync

[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 everyone uses and I just don't know
about.


Slony? But perhaps I'm not understanding what pg_comparator does.


Erik was talking about 

It just compares table contents (not schema), to point out differing 
tuples in two remote locations. Next step is to use the information to 
generate the appropriate insert/update/delete statements to resynchronize 
the tables, if they are out of sync for some reason and you do not want to 
dump/restore the whole stuff.


--
Fabien.

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster

Re: [HACKERS] Not ready for 8.3

[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 of things 
out there that are not quite ready yet, that could be if we released 
again next January...


Huh, you didn't answer my issue about unfair.


Sure I did see above :). Unfair would be to let go all together. We are 
just delaying. If we don't have reviewers, we don't have reviewers and 
as I look at the open list we have more reviewers than we did for 8.2 so 
I would suspect that 8.4 is going to go smoother as it is.


Leaving only those patches that have confirmed reviewers to be worked 
through.


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.


Fairness and not pushing our problems out to the future --- address
those issues.


Life isn't fair. It isn't like we are telling these people to bugger 
off. We are just delaying the review to what is a reasonable workload 
for the current set of reviewers.


Life... is a perpetual problem. We do what we can, when we can, and the 
best that we can.


Taking my suggestion above for leaving patches that don't have reviewers 
 let's look at some of them.


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.


HOT is a huge patch that has gone round and round and round. Lots of 
people want it, including me but it is invasive enough to where it may 
due it good to work through another cycle.


Grouped Index Tuples. I like the result of this patch. I tested the 
performance and it did work as advertised but we didn't get much 
feedback as a whole from known hackers. Either there isn't much interest 
 or we are too busy. Either way it is certainly not a critical patch 
and can be pushed.


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 text matching performance improvements (todo wiki link broke), so I 
don't have much comment.


On Disk Bitmap indexes (todo wiki link broke): Doesn't support Vacuum 
(to my knowledge), community member tested, reported problems... no 
response yet from author. The author is known to be time constrained, 
boot it till 8.4.


Posix shared memory, not usable in current state per Tom's comments and 
Apples, agreement. Dumped till 8.4 or further.


Stream bitmaps, apparently needed more info from Gavin (see previous 
comment about author's time). No feed back since March 9th. Dumped till 8.4.


Bitmapscan change, this one is unfortunate because at the time Heikki 
had resources and desire but was basically ignored. Sometimes we have to 
punt although Heikki is doing patch review right now and it is not 
unheard of for a patch reviewer to commit his own patch (in this case we 
would need a comitter to actually accept it.).


Updateable cursors, apparently breaks explain and patch has been 
updated. Punt!


Group Commit, Heikki has already suggested that it may be a good idea to 
push for 8.4 on this patch: http://momjian.us/mhonarc/patches/msg00127.html


Index Advisor.. I think the link is wrong:

http://momjian.us/mhonarc/patches/msg00119.html

Ctid chain patch, apparently no discussion since last January even 
though requests had been made to change the patch to some degree. Punt.
I will note that no one was negative about the patch, it just doesn't 
appear that the requests were ever finished.


Error correct for n_dead_tuples, patch was requested for hold in Feb. No 
discussion since. Punt!


DSM, apparently includes n_dead_tuples, please remove n_dead_tuples line 
on todo. Significant memory allocation enhancements are expected in 8.4 
for this. Discussion died in April. Concerns were raised about how 
memory is allocated (fixed, shared) which author already admints to 
wanting to change for 8.4.


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.


So there ya go... thoughts, flames?

Sincerely,

Joshua D. Drake











---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
  subscribe-nomail command to [EMAIL PROTECTED] so that your
  message can get through to the mailing list cleanly

Re: [HACKERS] Not ready for 8.3

[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, so the hope is that we wouldn't have many more new
large patches, but several small ones we could deal with while we
whittle away at the larger patches during the next few months.

The question is whether it is healthy for us to remain in feature freeze
for months, and if it is unhealthy, what are our options?



I don't see any reason development has to stop while the tree is in feature
freeze. If it led to patches being ready for review and getting reviewed and
committed early in the cycle rather than just before release I think it would
actually be extremely healthy.

  


If we had multiple dev branches it might be more possible. That has its 
own costs, of course - having a single dev branch makes management much 
easier, and we never have to worry about things like merging.


Patches seem to be getting larger, more complex, and harder to review. 
That is stressing our processes more than somewhat.


Short cycles would only make matters worse - the frictional cost of each 
dev cycle is growing. I think at least we have learned not to repeat 
this exercise.


cheers

andrew

---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
  subscribe-nomail command to [EMAIL PROTECTED] so that your
  message can get through to the mailing list cleanly

Re: [HACKERS] Managing the community information stream

[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 in
the bug, and you can see all those messages in the bug report.  I
ass-ume that BZ 3.0 does something similar.


But often a TODO item has multiple threads containing details (often
months apart), and it isn't obvious at the time the thread is started
that this will happen.  Note the number of TODO items that now have
multiple URLs.  How is that handled?


Well you can certainly merge tickets, but one of the ideas would be to 
help stop that :)...


Hey what about foo... oh we discussed that *here*...

Joshua D. Drake






---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings

Re: [HACKERS] Not ready for 8.3

[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 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 10x more
progress than we have had, which is unlikely.


Or we have another short release cycle, basically accepting what we have now 
that can be worked through in the next 3 weeks and committed. If it can't be 
done in that time, it waits. Then we have beta etc...




We could ship what is in CVS now, but that just pushes the patches for
8.4, and isn't fair to patch submitters.  We could shove what we have
now into CVS, but that is unwise.


Sure it is, if we have a short release cycle. There are plenty of things out 
there that are not quite ready yet, that could be if we released again next 
January...





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


Gah, that sounds like a horrible solution. Sorry Bruce.



The question is whether it is healthy for us to remain in feature freeze
for months, and if it is unhealthy, what are our options?

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 patches that have confirmed reviewers to be worked 
through.


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.


Sincerely,

Joshua D. Drake




---(end of broadcast)---
TIP 4: Have you searched our list archives?

 http://archives.postgresql.org



Regards,
Oleg
_
Oleg Bartunov, Research Scientist, Head of AstroNet (www.astronet.ru),
Sternberg Astronomical Institute, Moscow University, Russia
Internet: [EMAIL PROTECTED], http://www.sai.msu.su/~megera/
phone: +007(495)939-16-83, +007(495)939-23-83

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings

Re: [HACKERS] Not ready for 8.3

[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 unfair).
>
> If that means shortening the 8.4 cycle somewhat, I'm for that
> ... feature freeze in Feburary would be even better than April,
> because it means we could be in Beta for the May-June-July
> conferences, and increase our probability of being able to release
> at a major conference or PostgreSQL conference.

If we're pushing stuff planned for 8.3 off into 8.4, then doesn't that
mean that we'd be inclined to _lengthen_ the 8.4 cycle?

If we were to shorten the 8.4 cycle, that seems likely to me to worsen
the problem, so that I'd expect to see even more stuff deferred for
8.5 than was the case with 8.3...

> Obviously for 8.4 reviewers need to start reviewing stuff from the
> first week of the development cycle.  I also don't actually see
> anything wrong with a 3-month feature freeze if we can somehow
> branch development earlier.  Easy for me to say, I know.

Well, if people are essentially already working on patches for 8.4
*now*, but just deferring merging until after 8.3 is committed +
released, then we've got 8.4 work underway already.

Unfortunately, that's also likely to worsen the problem of the
reviewers' queues being even more overflowing.

I'd sorta like to see the Tom Lanes and Bruce Momjians of the project
getting to have some time to work on things that *they'd* like add, as
opposed to turning things into a spiral cycle where they keep spending
more and more of their time reviewing patches, as opposed to doing
things they find neat and new.  Too many iterations of that sort of
thing, and they'll not want to ever see a patch again...

-- 
output = ("cbbrowne" "@" "linuxdatabases.info")
http://cbbrowne.com/info/wp.html
"...It is also  possible to post imbecilic  articles with any browser,
especially when you  toppostand omit snippage."--   CBFalconer
<[EMAIL PROTECTED]> - seen on comp.lang.c 

---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq

Re: [HACKERS] fixing uuid-ossp

[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 
to
 #include 

People who *do* have it installed in such a directory can add to the 
build with a --with-includes configure directive.


If someone feels like fixing this using some configure magic calling 
uuid-config in a similar way to the way we use tclConfig.sh, that 
might be nice, but I don't have time right now.





I have committed this now.

cheers

andrew

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings

Re: [HACKERS] Not ready for 8.3

[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 issues with the patch ? Our patch is several months old. We permanently

keep it in sync with CVS HEAD, latest version is 0.47.

We're really bored with the whole process of development. We're not
full-time developers, we just devote our spare time which we withdraw from 
time we should spend on many other things. We have no time even to discuss

those very useful threads about community management, patches, etc. We just
rely on community decision.

Regards,
Oleg
_
Oleg Bartunov, Research Scientist, Head of AstroNet (www.astronet.ru),
Sternberg Astronomical Institute, Moscow University, Russia
Internet: [EMAIL PROTECTED], http://www.sai.msu.su/~megera/
phone: +007(495)939-16-83, +007(495)939-23-83

---(end of broadcast)---
TIP 6: explain analyze is your friend

Re: [HACKERS] Not ready for 8.3

[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 text matching performance improvements (todo wiki link broke), so I
> don't have much comment.

url should be fixed now

> 
> On Disk Bitmap indexes (todo wiki link broke): Doesn't support Vacuum
> (to my knowledge), community member tested, reported problems... no
> response yet from author. The author is known to be time constrained,
> boot it till 8.4.

url fixed too


> 
> Bitmapscan change, this one is unfortunate because at the time Heikki
> had resources and desire but was basically ignored. Sometimes we have to
> punt although Heikki is doing patch review right now and it is not
> unheard of for a patch reviewer to commit his own patch (in this case we
> would need a comitter to actually accept it.).
> 
> Updateable cursors, apparently breaks explain and patch has been
> updated. Punt!
> 
> Group Commit, Heikki has already suggested that it may be a good idea to
> push for 8.4 on this patch: http://momjian.us/mhonarc/patches/msg00127.html
> 
> Index Advisor.. I think the link is wrong:
> 
> http://momjian.us/mhonarc/patches/msg00119.html

url fixed

> 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 pointing
to the patch list bruce maintains - are the urls to the mails there not
stable somehow ?


Stefan

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster

Re: [HACKERS] Not ready for 8.3

[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 understand you mean 
there are issues with the patch ? Our patch is several months old. We 
permanently

keep it in sync with CVS HEAD, latest version is 0.47.


http://archives.postgresql.org/pgsql-hackers/2007-01/msg01172.php

Sincerely,

Joshua D. Drake

---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
  choose an index scan if your joining column's datatypes do not
  match

Re: [HACKERS] Not ready for 8.3

[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 of them and all those pointing
> to the patch list bruce maintains - are the urls to the mails there not
> stable somehow ?

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.

-- 
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org

Re: [HACKERS] Not ready for 8.3

[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 why we had so much of them and all those pointing
to the patch list bruce maintains - are the urls to the mails there not
stable somehow ?


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 think we discussed it once... I don't remember the reason why we 
didn't go that direction.


Joshua D. Drake






---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
  subscribe-nomail command to [EMAIL PROTECTED] so that your
  message can get through to the mailing list cleanly

Re: [HACKERS] Not ready for 8.3

[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 why we had so much of them and all those pointing
>> to the patch list bruce maintains - are the urls to the mails there not
>> stable somehow ?
> 
> 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 - I see so is there a particular reason for that behaviour ?

I will work on pointing to the archives tomorrow ...


Stefan

---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
   subscribe-nomail command to [EMAIL PROTECTED] so that your
   message can get through to the mailing list cleanly

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

[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 has a strong opinion on the matter, my opinion is we
> > do (2) which is the easiest.
> 
> Here is a patch implementing this idea, vaguely based on Russell's.

Applied to CVS HEAD, 8.2 and 8.1.

If we want to start tracking the grantor as a shared dependency, and
have REVOKE work per spec (i.e. only revoke the privileges actually
granted by the role executing REVOKE), those are separate patches (and
they should be applied only to HEAD).  This patch merely fixes the fact
that pg_dumpall failed to work for busted databases.

-- 
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings

Re: [HACKERS] Not ready for 8.3

[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:
http://news.gmane.org/find-root.php?message_id=$MSGID

It uses non-PostgreSQL infrastructure, but hey, I think gmane does list
archives better than PostgreSQL right now ;-)

Try it:
http://news.gmane.org/[EMAIL PROTECTED]

a.

-- 
Aidan Van Dyk Create like a god,
[EMAIL PROTECTED]   command like a king,
http://www.highrise.ca/   work like a slave.


signature.asc
Description: Digital signature

Re: [HACKERS] Not ready for 8.3

[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 outside of core.
> >> url fixed - I wonder why we had so much of them and all those pointing
> >> to the patch list bruce maintains - are the urls to the mails there not
> >> stable somehow ?
> > 
> > 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 - I see so is there a particular reason for that behaviour ?
> 
> I will work on pointing to the archives tomorrow ...

Bruce adds and removes emails from the "pgpatches" inbox and I assume he
regenerates the MHonarc archives when he does, which may change the URL
for each specific item.  I don't think it was ever intended that the
URLs were to be stable.

-- 
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate

Re: [HACKERS] Not ready for 8.3

[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 - I see so is there a particular reason for that behaviour ?

They're stable until Bruce removes something from the queue. When
something is removed, it's renumbered.

It's how mhonarc works. It's the same with the archives - if we delete a
mail, they get renumbered. So we never should delete, we should just
blank out, but it has happened a couple of times.

//Magnus

---(end of broadcast)---
TIP 6: explain analyze is your friend

Re: [HACKERS] Managing the community information stream

[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, and send messages to [EMAIL PROTECTED] and it gets tracked in
> > > the bug, and you can see all those messages in the bug report.  I
> > > ass-ume that BZ 3.0 does something similar.
> > 
> > But often a TODO item has multiple threads containing details (often
> > months apart), and it isn't obvious at the time the thread is started
> > that this will happen.  Note the number of TODO items that now have
> > multiple URLs.  How is that handled?
> 
> Just add the bug address to CC and reply to it, just like when you reply
> to say "added to TODO", only that you don't need to manually go and
> modify the TODO file by hand.  The bug tracking system puts that mail
> into the bug report.  Subsequent followups keep the bug address in CC
> and thus the whole discussion is saved in the bug report.

Right, but you are adding the bug addresss at the end of the email
thread.  How do you point to the email you want to reference?

> This is even better than our archives due to the problem that the
> archives don't have links to messages crossing month boundaries.  Have
> you noticed that if you go to the archives, some discussions appear
> truncated at a point, but you can go to the archive for the next month
> and it continues there?  I find that artifact somewhat annoying.  The
> bug report would continue receiving the CC'ed mails, so it would record
> them all in a single place.

Not crossing month boundaries is super-annoying.

-- 
  Bruce Momjian  <[EMAIL PROTECTED]>  http://momjian.us
  EnterpriseDB   http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster

Re: [HACKERS] Managing the community information stream

[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 PROTECTED] and it gets tracked in
> >> the bug, and you can see all those messages in the bug report.  I
> >> ass-ume that BZ 3.0 does something similar.
> > 
> > But often a TODO item has multiple threads containing details (often
> > months apart), and it isn't obvious at the time the thread is started
> > that this will happen.  Note the number of TODO items that now have
> > multiple URLs.  How is that handled?
> 
> Well you can certainly merge tickets, but one of the ideas would be to 
> help stop that :)...
> 
> Hey what about foo... oh we discussed that *here*...

Our thought process is not linear --- often an item changes as our
surrounding code changes too.  The multiple URLs are not because no one
knows about the previous discussion.

-- 
  Bruce Momjian  <[EMAIL PROTECTED]>  http://momjian.us
  EnterpriseDB   http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
   subscribe-nomail command to [EMAIL PROTECTED] so that your
   message can get through to the mailing list cleanly

Re: [HACKERS] Not ready for 8.3

[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 this all the time:
>   http://news.gmane.org/find-root.php?message_id=$MSGID
> 
> It uses non-PostgreSQL infrastructure, but hey, I think gmane does list
> archives better than PostgreSQL right now ;-)
> 
> Try it:
>   http://news.gmane.org/[EMAIL PROTECTED]

Wow, this is really nice, thanks.

-- 
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings

Re: [HACKERS] Not ready for 8.3

[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 know about these reservations. If I understand you mean there 
are issues with the patch ? Our patch is several months old. We permanently

keep it in sync with CVS HEAD, latest version is 0.47.


http://archives.postgresql.org/pgsql-hackers/2007-01/msg01172.php


there are several others threads.

well, we did answer all raised questions and I don't want to begin
another wave. The only problem I see is that some people doesn't like
introducing SQL syntax, they claim functions would be enough. SQL is a
nice language to manipulate db objects, finally. 
Also, select to fts_create_dictionary(bla-bla) looks pretty ugly,

pretty artificial.

CREATE FULLTEXT DICTIONARY dictname 
[{   INIT  init_function

| LEXIZE  lexize_function
| OPTION opt_text } 
[ ... ]] LIKE template_dictname;


select



Sincerely,

Joshua D. Drake



Regards,
Oleg
_
Oleg Bartunov, Research Scientist, Head of AstroNet (www.astronet.ru),
Sternberg Astronomical Institute, Moscow University, Russia
Internet: [EMAIL PROTECTED], http://www.sai.msu.su/~megera/
phone: +007(495)939-16-83, +007(495)939-23-83

---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at

   http://www.postgresql.org/about/donate

Re: [HACKERS] Not ready for 8.3

[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 started, so the hope is that we wouldn't have many more new
> > large patches, but several small ones we could deal with while we
> > whittle away at the larger patches during the next few months.
> >
> > The question is whether it is healthy for us to remain in feature freeze
> > for months, and if it is unhealthy, what are our options?
> 
> I don't see any reason development has to stop while the tree is in feature
> freeze. If it led to patches being ready for review and getting reviewed and
> committed early in the cycle rather than just before release I think it would
> actually be extremely healthy.

So you are saying just let people keep developing for 8.4 and we will
use it as soon as we start for 8.4.  OK.  We might get to a point where
we can just open development for 8.4, apply outstanding patches, and
head for beta.  ;-)

-- 
  Bruce Momjian  <[EMAIL PROTECTED]>  http://momjian.us
  EnterpriseDB   http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster

Re: [HACKERS] Not ready for 8.3

[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 unfair to disinguish between early/last in cycle postings.

> If that means shortening the 8.4 cycle somewhat, I'm for that ... feature 
> freeze in Feburary would be even better than April, because it means we could 
> be in Beta for the May-June-July conferences, and increase our probability of 
> being able to release at a major conference or PostgreSQL conference.
> 
> Obviously for 8.4 reviewers need to start reviewing stuff from the first week 
> of the development cycle.  I also don't actually see anything wrong with a 
> 3-month feature freeze if we can somehow branch development earlier.  Easy 
> for me to say, I know. 

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.

-- 
  Bruce Momjian  <[EMAIL PROTECTED]>  http://momjian.us
  EnterpriseDB   http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
   subscribe-nomail command to [EMAIL PROTECTED] so that your
   message can get through to the mailing list cleanly

Re: [HACKERS] Not ready for 8.3

[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 accepted either.  I see that as
unfair to patch submitters, and not making things any easier.  It just
pushes our problem into 8.4.

> >> Sure it is, if we have a short release cycle. There are plenty of things 
> >> out there that are not quite ready yet, that could be if we released 
> >> again next January...
> > 
> > Huh, you didn't answer my issue about unfair.
> 
> Sure I did see above :). Unfair would be to let go all together. We are 
> just delaying. If we don't have reviewers, we don't have reviewers and 
> as I look at the open list we have more reviewers than we did for 8.2 so 
> I would suspect that 8.4 is going to go smoother as it is.

And even more patches for 8.4.

Given your list below, let me match it up with Tom's comments and see if
I can defer some patches that are not ready for application.  I think
bitmapped indexes are one of them.

---


> >> Leaving only those patches that have confirmed reviewers to be worked 
> >> through.
> >>
> >> 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.
> > 
> > Fairness and not pushing our problems out to the future --- address
> > those issues.
> 
> Life isn't fair. It isn't like we are telling these people to bugger 
> off. We are just delaying the review to what is a reasonable workload 
> for the current set of reviewers.

Again, it just pushed things off.  I see just keeping going as a better
approach.

> Life... is a perpetual problem. We do what we can, when we can, and the 
> best that we can.

Yea, but we have to do that best we can, not give up and hope something
improves for 8.4, because I see no basis for such a belief.

> Taking my suggestion above for leaving patches that don't have reviewers 
>   let's look at some of them.
> 
> 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.
> 
> HOT is a huge patch that has gone round and round and round. Lots of 
> people want it, including me but it is invasive enough to where it may 
> due it good to work through another cycle.
> 
> Grouped Index Tuples. I like the result of this patch. I tested the 
> performance and it did work as advertised but we didn't get much 
> feedback as a whole from known hackers. Either there isn't much interest 
>   or we are too busy. Either way it is certainly not a critical patch 
> and can be pushed.
> 
> 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 text matching performance improvements (todo wiki link broke), so I 
> don't have much comment.
> 
> On Disk Bitmap indexes (todo wiki link broke): Doesn't support Vacuum 
> (to my knowledge), community member tested, reported problems... no 
> response yet from author. The author is known to be time constrained, 
> boot it till 8.4.
> 
> Posix shared memory, not usable in current state per Tom's comments and 
> Apples, agreement. Dumped till 8.4 or further.
> 
> Stream bitmaps, apparently needed more info from Gavin (see previous 
> comment about author's time). No feed back since March 9th. Dumped till 8.4.
> 
> Bitmapscan change, this one is unfortunate because at the time Heikki 
> had resources and desire but was basically ignored. Sometimes we have to 
> punt although Heikki is doing patch review right now and it is not 
> unheard of for a patch reviewer to commit his own patch (in this case we 
> would need a comitter to actually accept it.).
> 
> Updateable cursors, apparently breaks explain and patch has been 
> updated. Punt!
> 
> Group Commit, Heikki has already suggested that it may be a good idea to 
> push for 8.4 on this patch: http://momjian.us/mhonarc/patches/msg00127.html
> 
> Index Advisor.. I think the link is wrong:
> 
> http://momjian.us/mhonarc/patches/msg00119.html
> 
> Ctid chain patch, apparently no discussion since last January even 
> though requests had been made to change the patch to some degree. Punt.
> I will note that no one was negative about the patch, it just doesn't 
> appear that the requests were ever finished.
> 
> Error correct for n_dead_tuples, patch was requested for hold in Feb. No 
> discussion since. Punt!
> 
> DSM, apparently includes n_dead_tuples, please remove n_dead_tuples line 
> on todo. Significant memory allocation enhancements are e

Re: [HACKERS] Not ready for 8.3

[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 many more new
> >> large patches, but several small ones we could deal with while we
> >> whittle away at the larger patches during the next few months.
> >>
> >> The question is whether it is healthy for us to remain in feature freeze
> >> for months, and if it is unhealthy, what are our options?
> >> 
> >
> > I don't see any reason development has to stop while the tree is in feature
> > freeze. If it led to patches being ready for review and getting reviewed and
> > committed early in the cycle rather than just before release I think it 
> > would
> > actually be extremely healthy.
> >
> >   
> 
> If we had multiple dev branches it might be more possible. That has its 
> own costs, of course - having a single dev branch makes management much 
> easier, and we never have to worry about things like merging.
> 
> Patches seem to be getting larger, more complex, and harder to review. 
> That is stressing our processes more than somewhat.
> 
> Short cycles would only make matters worse - the frictional cost of each 
> dev cycle is growing. I think at least we have learned not to repeat 
> this exercise.

Agreed.  Good summary.  Let's look at our problems honestly now and find
a direction, rather than pushing them off for later.

-- 
  Bruce Momjian  <[EMAIL PROTECTED]>  http://momjian.us
  EnterpriseDB   http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

---(end of broadcast)---
TIP 6: explain analyze is your friend

Re: [HACKERS] Not ready for 8.3

[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 months
> > > before 8.3 started, so the hope is that we wouldn't have many more new
> > > large patches, but several small ones we could deal with while we
> > > whittle away at the larger patches during the next few months.
> > >
> > > The question is whether it is healthy for us to remain in feature freeze
> > > for months, and if it is unhealthy, what are our options?
> > 
> > I don't see any reason development has to stop while the tree is in feature
> > freeze. If it led to patches being ready for review and getting reviewed and
> > committed early in the cycle rather than just before release I think it 
> > would
> > actually be extremely healthy.
> 
> So you are saying just let people keep developing for 8.4 and we will
> use it as soon as we start for 8.4.  OK.  We might get to a point where
> we can just open development for 8.4, apply outstanding patches, and
> head for beta.  ;-)

This is what happens with the Linux kernel.  They have hundreds of
developers getting their hands dirty during a previous period.  Then
2.6.20 is released; the 2.6.21 "merge window" opens, and all sort of
patches are flooded in.  The merge window closes some time after that
(it's something like 2 or 3 weeks), and the stabilization period follows
(2 months?), during which 2.6.21-rc1, -rc2 etc are released.  When
stability is reached, 2.6.21 is released, and the cycle starts again.

Sadly, we are missing the hundreds of developers.  We are nowhere near
the scale of Linux.

-- 
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate

Re: [HACKERS] Not ready for 8.3

[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 to whom it would be unfair).
> >
> > If that means shortening the 8.4 cycle somewhat, I'm for that
> > ... feature freeze in Feburary would be even better than April,
> > because it means we could be in Beta for the May-June-July
> > conferences, and increase our probability of being able to release
> > at a major conference or PostgreSQL conference.
> 
> If we're pushing stuff planned for 8.3 off into 8.4, then doesn't that
> mean that we'd be inclined to _lengthen_ the 8.4 cycle?
> 
> If we were to shorten the 8.4 cycle, that seems likely to me to worsen
> the problem, so that I'd expect to see even more stuff deferred for
> 8.5 than was the case with 8.3...

And, as I remember, we already deferred some stuff during 8.2 for 8.3. 
:-(

> > Obviously for 8.4 reviewers need to start reviewing stuff from the
> > first week of the development cycle.  I also don't actually see
> > anything wrong with a 3-month feature freeze if we can somehow
> > branch development earlier.  Easy for me to say, I know.
> 
> Well, if people are essentially already working on patches for 8.4
> *now*, but just deferring merging until after 8.3 is committed +
> released, then we've got 8.4 work underway already.
> 
> Unfortunately, that's also likely to worsen the problem of the
> reviewers' queues being even more overflowing.
> 
> I'd sorta like to see the Tom Lanes and Bruce Momjians of the project
> getting to have some time to work on things that *they'd* like add, as
> opposed to turning things into a spiral cycle where they keep spending
> more and more of their time reviewing patches, as opposed to doing
> things they find neat and new.  Too many iterations of that sort of
> thing, and they'll not want to ever see a patch again...

Another good summary.

Myself, I have always done what no one wanted to do so that more people
can do what they want to do, and I am OK with that.  It helps the
project move forward faster than if I did only what I wanted to do.

-- 
  Bruce Momjian  <[EMAIL PROTECTED]>  http://momjian.us
  EnterpriseDB   http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
   subscribe-nomail command to [EMAIL PROTECTED] so that your
   message can get through to the mailing list cleanly

Re: [HACKERS] Not ready for 8.3

[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 resolved.


We'd like to know about these reservations. If I understand you mean 
there are issues with the patch ? Our patch is several months old. We 
permanently

keep it in sync with CVS HEAD, latest version is 0.47.


http://archives.postgresql.org/pgsql-hackers/2007-01/msg01172.php


there are several others threads.

well, we did answer all raised questions and I don't want to begin
another wave.


Did you address them? For example:

http://archives.postgresql.org/pgsql-hackers/2007-03/msg00914.php

Sincerely,

Joshua d. drake


 The only problem I see is that some people doesn't like

introducing SQL syntax, they claim functions would be enough. SQL is a
nice language to manipulate db objects, finally. Also, select to 
fts_create_dictionary(bla-bla) looks pretty ugly,

pretty artificial.

CREATE FULLTEXT DICTIONARY dictname [{   INIT  init_function
| LEXIZE  lexize_function
| OPTION opt_text } [ ... ]] LIKE template_dictname;

select



Sincerely,

Joshua D. Drake



Regards,
Oleg
_
Oleg Bartunov, Research Scientist, Head of AstroNet (www.astronet.ru),
Sternberg Astronomical Institute, Moscow University, Russia
Internet: [EMAIL PROTECTED], http://www.sai.msu.su/~megera/
phone: +007(495)939-16-83, +007(495)939-23-83

---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at

   http://www.postgresql.org/about/donate




---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster

Re: [HACKERS] Not ready for 8.3

[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 these reservations. If I understand you mean 
> > there are issues with the patch ? Our patch is several months old. We 
> > permanently
> > keep it in sync with CVS HEAD, latest version is 0.47.
> 
> http://archives.postgresql.org/pgsql-hackers/2007-01/msg01172.php

Oleg has been producing new versions of his patch, and no one has
objected to any of it, so I assume all the issues were addressed.

As far was whether tsearch2 should be in core, I think most agreed that
SQL support for full-text would make it easier to use, and that it is a
fundamental technology.  As I remember, the only holdback was full
multi-byte support, but that is done.

-- 
  Bruce Momjian  <[EMAIL PROTECTED]>  http://momjian.us
  EnterpriseDB   http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq

Re: [HACKERS] Not ready for 8.3

[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 knowledge those reservations 
have not been resolved.


We'd like to know about these reservations. If I understand you mean 
there are issues with the patch ? Our patch is several months old. We 
permanently

keep it in sync with CVS HEAD, latest version is 0.47.


http://archives.postgresql.org/pgsql-hackers/2007-01/msg01172.php


there are several others threads.

well, we did answer all raised questions and I don't want to begin
another wave.


Did you address them? For example:

http://archives.postgresql.org/pgsql-hackers/2007-03/msg00914.php


we added support of gin index for text data type, so one could just

create index fts_idx on TABLE using gin(body);

and should be able to do full-text search. Of course, ranking is not
available, since index doesn't store positional information.


 About this syntax see
http://archives.postgresql.org/pgsql-hackers/2007-03/msg00936.php



Sincerely,

Joshua d. drake


The only problem I see is that some people doesn't like

introducing SQL syntax, they claim functions would be enough. SQL is a
nice language to manipulate db objects, finally. Also, select to 
fts_create_dictionary(bla-bla) looks pretty ugly,

pretty artificial.

CREATE FULLTEXT DICTIONARY dictname [{   INIT  init_function
| LEXIZE  lexize_function
| OPTION opt_text } [ ... ]] LIKE template_dictname;

select



Sincerely,

Joshua D. Drake



Regards,
Oleg
_
Oleg Bartunov, Research Scientist, Head of AstroNet (www.astronet.ru),
Sternberg Astronomical Institute, Moscow University, Russia
Internet: [EMAIL PROTECTED], http://www.sai.msu.su/~megera/
phone: +007(495)939-16-83, +007(495)939-23-83

---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at

   http://www.postgresql.org/about/donate





Regards,
Oleg
_
Oleg Bartunov, Research Scientist, Head of AstroNet (www.astronet.ru),
Sternberg Astronomical Institute, Moscow University, Russia
Internet: [EMAIL PROTECTED], http://www.sai.msu.su/~megera/
phone: +007(495)939-16-83, +007(495)939-23-83

---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
  choose an index scan if your joining column's datatypes do not
  match

Re: [HACKERS] Not ready for 8.3

[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 understand you mean there 
> are issues with the patch ? Our patch is several months old. We permanently
> keep it in sync with CVS HEAD, latest version is 0.47.
> 
> We're really bored with the whole process of development. We're not
> full-time developers, we just devote our spare time which we withdraw from 
> time we should spend on many other things. We have no time even to discuss
> those very useful threads about community management, patches, etc. We just
> rely on community decision.

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.

One good thing is that we have community discussion this now, so at
least we are focusing on it.

-- 
  Bruce Momjian  <[EMAIL PROTECTED]>  http://momjian.us
  EnterpriseDB   http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
   subscribe-nomail command to [EMAIL PROTECTED] so that your
   message can get through to the mailing list cleanly

Re: [HACKERS] Not ready for 8.3

[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 pointing
> to the patch list bruce maintains - are the urls to the mails there not
> stable somehow ?

Yep, the URLs are unstable.  I am using mhonarc and regenerate the page
when the patches mbox file changes.  When I append to the mailbox, the
URLs don't change, but when I delete, they do.

Does anyone know a way to make those URLs stable?

-- 
  Bruce Momjian  <[EMAIL PROTECTED]>  http://momjian.us
  EnterpriseDB   http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate

Re: [HACKERS] Not ready for 8.3

[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 advantage of facilities outside of core.
> > >> url fixed - I wonder why we had so much of them and all those pointing
> > >> to the patch list bruce maintains - are the urls to the mails there not
> > >> stable somehow ?
> > > 
> > > 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 - I see so is there a particular reason for that behaviour ?
> > 
> > I will work on pointing to the archives tomorrow ...
> 
> Bruce adds and removes emails from the "pgpatches" inbox and I assume he
> regenerates the MHonarc archives when he does, which may change the URL
> for each specific item.  I don't think it was ever intended that the
> URLs were to be stable.

Right.  Is there no way to make the mhonarc URLs stable?

-- 
  Bruce Momjian  <[EMAIL PROTECTED]>  http://momjian.us
  EnterpriseDB   http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
   choose an index scan if your joining column's datatypes do not
   match

Re: [HACKERS] Not ready for 8.3

[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 of them and all those pointing
> > to the patch list bruce maintains - are the urls to the mails there not
> > stable somehow ?
> 
> Yep, the URLs are unstable.  I am using mhonarc and regenerate the page
> when the patches mbox file changes.  When I append to the mailbox, the
> URLs don't change, but when I delete, they do.
> 
> Does anyone know a way to make those URLs stable?

Does it matter?  I assume that we should not consider pgpatches to be a
stable source anyway ... those emails are there just as a reminder for
short-lived information anyway, so why bother?

-- 
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster

Re: [HACKERS] Not ready for 8.3

[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 not call the sky falling just yet. We are doing what we can. There 
are several sub projects afoot trying to eliminate some of this pain. If 
you recall, Lukas and I both spent time before feature freeze helping 
keep people in communication.


Secondly and although you aren't 100% on board, there is also the 
tracker project.


Lastly, more people are starting to review code. Even people that can't 
code are starting to at least participate in testing features.




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 
reflect what size ladder or rope we need to get over it.


Joshua D. Drake


---(end of broadcast)---
TIP 4: Have you searched our list archives?

  http://archives.postgresql.org

Re: [HACKERS] Not ready for 8.3

[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 had so much of them and all those pointing
to the patch list bruce maintains - are the urls to the mails there not
stable somehow ?

Yep, the URLs are unstable.  I am using mhonarc and regenerate the page
when the patches mbox file changes.  When I append to the mailbox, the
URLs don't change, but when I delete, they do.

Does anyone know a way to make those URLs stable?


Does it matter?  I assume that we should not consider pgpatches to be a
stable source anyway ... those emails are there just as a reminder for
short-lived information anyway, so why bother?


Yeah let's just source archives, the urls are reasonable stable there.

Joshua D. Drake






---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at

   http://www.postgresql.org/about/donate

Re: [HACKERS] Not ready for 8.3

[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 the PostgreSQL project.
> 
> Let's not call the sky falling just yet. We are doing what we can. There 
> are several sub projects afoot trying to eliminate some of this pain. If 
> you recall, Lukas and I both spent time before feature freeze helping 
> keep people in communication.
> 
> Secondly and although you aren't 100% on board, there is also the 
> tracker project.
> 
> Lastly, more people are starting to review code. Even people that can't 
> code are starting to at least participate in testing features.
> 
> > 
> > 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 
> reflect what size ladder or rope we need to get over it.

Right.  I just don't want a short-term solution (push patches for 8.4)
that avoids a long-term analysis.

Lots of people complained we didn't have a patches status page.  Someone
has done that and it is current, but it is not moving us forward fast
enough.

What is our next move, or do we just keep moving and settle on August?

-- 
  Bruce Momjian  <[EMAIL PROTECTED]>  http://momjian.us
  EnterpriseDB   http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq

Re: [HACKERS] Not ready for 8.3

[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 
reflect what size ladder or rope we need to get over it.


Right.  I just don't want a short-term solution (push patches for 8.4)
that avoids a long-term analysis.

Lots of people complained we didn't have a patches status page.  Someone
has done that and it is current, but it is not moving us forward fast
enough.

What is our next move, or do we just keep moving and settle on August?


Well I think what you said about reviewing my list versus Tom's triage 
is a good start. If there are things we can push, let's push them. Plus 
based on this conversation I think we need reviewers to step up and 
say... "Hey! this is where I am at...".


Sincerely,

Joshua D. Drake




---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at

   http://www.postgresql.org/about/donate

Re: [HACKERS] Not ready for 8.3

[Bruce Momjian]

Joshua D. Drake wrote:
> 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 
> >> reflect what size ladder or rope we need to get over it.
> > 
> > Right.  I just don't want a short-term solution (push patches for 8.4)
> > that avoids a long-term analysis.
> > 
> > Lots of people complained we didn't have a patches status page.  Someone
> > has done that and it is current, but it is not moving us forward fast
> > enough.
> > 
> > What is our next move, or do we just keep moving and settle on August?
> 
> Well I think what you said about reviewing my list versus Tom's triage 
> is a good start. If there are things we can push, let's push them. Plus 
> based on this conversation I think we need reviewers to step up and 
> say... "Hey! this is where I am at...".

Agreed. I have already contacted all reviewers individually to ask them
for a status, and mentioned I was concerned.

-- 
  Bruce Momjian  <[EMAIL PROTECTED]>  http://momjian.us
  EnterpriseDB   http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq

Re: [HACKERS] 8.3 pending patch queue

[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 patches held for 8.3 this week or next, now
> > that the holiday break is over:
> > 
> > http://momjian.postgresql.org/cgi-bin/pgpatches_hold
> > 
> 
> The following patches don't appear on this list: 
> 
> Concurrent psql
> Original submission
> http://archives.postgresql.org/pgsql-patches/2006-08/msg00249.php
> Latest
> http://archives.postgresql.org/pgsql-hackers/2006-12/msg00527.php
> Described here: http://community.enterprisedb.com/concurrent/index.html
> 
> WAL Index Split
> Original submission
> http://archives.postgresql.org/pgsql-patches/2006-12/msg00045.php
> Latest
> http://archives.postgresql.org/pgsql-patches/2007-01/msg0.php
> 
> Grouped Items
> Latest
> http://archives.postgresql.org/pgsql-patches/2006-11/msg00051.php
> Described here: http://community.enterprisedb.com/git/index.html
> 
> Maintain Cluster Order
> http://archives.postgresql.org/pgsql-patches/2006-08/msg00124.php
> 
> All have been awaiting review for at least a month (though in one case
> the latest version is quite recent). They probably ought to be on the
> hold queue; all are ready to be reviewed for final
> application/rejection.
> 
> I'd hasten to add that none of those are mine. My patches have received
> good attention, so I'm not complaining just completing admin.
> 
> -- 
>   Simon Riggs 
>   EnterpriseDB   http://www.enterprisedb.com
> 
> 
> 
> ---(end of broadcast)---
> TIP 3: Have you checked our extensive FAQ?
> 
>http://www.postgresql.org/docs/faq

-- 
  Bruce Momjian  <[EMAIL PROTECTED]>  http://momjian.us
  EnterpriseDB   http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq

Re: [HACKERS] Managing the community information stream

[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 messages to [EMAIL PROTECTED] and it gets tracked in
> > the bug, and you can see all those messages in the bug report.  I
> > ass-ume that BZ 3.0 does something similar.
> 
> But often a TODO item has multiple threads containing details (often
> months apart), and it isn't obvious at the time the thread is started
> that this will happen.  Note the number of TODO items that now have
> multiple URLs.  How is that handled?

Worst-case, for those cases we add URLs to the tracker manually like you
do now. The big advantage is that most of the time that's not needed.
And in cases where it's not automatic we can grant any number of people
permission to add that information to the tracker, because that
permission wouldn't be tied to CVS commit privs.
-- 
Jim Nasby  [EMAIL PROTECTED]
EnterpriseDB  http://enterprisedb.com  512.569.9461 (cell)

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings

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

[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
decide; if no one has a strong opinion on the matter, my opinion is we
do (2) which is the easiest.
  

Here is a patch implementing this idea, vaguely based on Russell's.



Applied to CVS HEAD, 8.2 and 8.1.

If we want to start tracking the grantor as a shared dependency, and
have REVOKE work per spec (i.e. only revoke the privileges actually
granted by the role executing REVOKE), those are separate patches (and
they should be applied only to HEAD).  This patch merely fixes the fact
that pg_dumpall failed to work for busted databases.

  
Should there also be a doc patch for this, the document descriptions 
seemed different to what is actually implemented.  I'll check that 
before I make any further comments.


Russell

---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
  subscribe-nomail command to [EMAIL PROTECTED] so that your
  message can get through to the mailing list cleanly

Re: [HACKERS] Seq scans roadmap

[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 to check the effect on the synchronized 
> > scans, though.
> > 
> 
> I am a little worried that there will be greater differences in position
> as the number of scans increase. If we have only 8 buffers and several
> scans progressing, will they all be able to stay within a few buffers of
> eachother at any given time?
> 
> Also, with 8 buffers, that means each scan must report every 4 pages at
> most (and maybe every page), which increases lock contention (the new
> design Heikki and I discussed requires a lock every time a backend
> reports its position).

Given that spoiling the L2 cache is a trivial cost compared to extra
physical IO, ISTM we should go with a largish ring for sync scans. What
do you think would be the ideal size? 32 buffers?
-- 
Jim Nasby  [EMAIL PROTECTED]
EnterpriseDB  http://enterprisedb.com  512.569.9461 (cell)

---(end of broadcast)---
TIP 6: explain analyze is your friend

Re: [HACKERS] 8.3 pending patch queue

[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




---

Simon Riggs wrote:

On Mon, 2007-01-01 at 19:04 -0500, Bruce Momjian wrote:


I will start processing the patches held for 8.3 this week or next, now
that the holiday break is over:

http://momjian.postgresql.org/cgi-bin/pgpatches_hold

The following patches don't appear on this list: 


Concurrent psql
Original submission
http://archives.postgresql.org/pgsql-patches/2006-08/msg00249.php
Latest
http://archives.postgresql.org/pgsql-hackers/2006-12/msg00527.php
Described here: http://community.enterprisedb.com/concurrent/index.html

WAL Index Split
Original submission
http://archives.postgresql.org/pgsql-patches/2006-12/msg00045.php
Latest
http://archives.postgresql.org/pgsql-patches/2007-01/msg0.php

Grouped Items
Latest
http://archives.postgresql.org/pgsql-patches/2006-11/msg00051.php
Described here: http://community.enterprisedb.com/git/index.html

Maintain Cluster Order
http://archives.postgresql.org/pgsql-patches/2006-08/msg00124.php

All have been awaiting review for at least a month (though in one case
the latest version is quite recent). They probably ought to be on the
hold queue; all are ready to be reviewed for final
application/rejection.

I'd hasten to add that none of those are mine. My patches have received
good attention, so I'm not complaining just completing admin.

--
  Simon Riggs 
  EnterpriseDB   http://www.enterprisedb.com




---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq





---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster

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

[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 implemented?  I can do whatever we
decide; if no one has a strong opinion on the matter, my opinion is we
do (2) which is the easiest.


Here is a patch implementing this idea, vaguely based on Russell's.
  
I haven't had time to finalize my research about this, but the admin 
option with revoke doesn't appear to work as expected.


Here is my sample SQL for 8.2.4

create table test (x integer);
\z
create role test1 noinherit;
create role test2 noinherit;
grant select on test to test1 with grant option;
grant select on test to test2;
\z test
set role test1;
revoke select on test from test2;
\z test
set role test2;
select * from test;
reset role;
revoke all on test from test2;
revoke all on test from test1;
drop role test2;
drop role test1;
drop table test;
\q


The privilege doesn't appear to be revoked by test1 from test2.  I'm not 
sure if this is related, but I wanted to bring it up in light of the 
options we have for grantor.



Humm, but the privilege was not granted by test1, but by the user you
were using initially.  The docs state in a note that

A user can only revoke privileges that were granted directly by
that user.

I understand that this would apply to the grantor stuff being discussed
in this thread as well, but I haven't seen anyone arguing that we should
implement that for GRANT ROLE (and I asked three times if people felt it
was important and nobody answered).

  
Well, I would vote for implementing this in GRANT ROLE.  I wish to use 
it in my security model.  I don't think the spec is brain dead when you 
understand what it's trying to achieve.


Example:

2 Groups of administrators who are allowed to grant a role to users of 
the system


App_Admin_G1
App_Admin_G2
App_User

SET ROLE App_Admin_G1
GRANT App_User TO "Fred";
SET ROLE App_Admin_G2
GRANT App_User TO "John";
SET ROLE App_Admin_G1
REVOKE App_User FROM "John";

As App_Admin_G1 did not grant App_User rights to John, he should not be 
able to take them away.


I currently have a situation where I would like to be able to do the 
above.  I have two separate departments who might grant privileges for 
the same application to the same user.  One department administrator 
should not be able to revoke the privileges set by the other one.


I would expect superusers to be able to revoke from anybody, or the 
"owner".  I'm not sure what the owner is when we talk about granting roles.


Regards

Russell Smith


---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
  subscribe-nomail command to [EMAIL PROTECTED] so that your
  message can get through to the mailing list cleanly

Re: [HACKERS] 8.3 pending patch queue

[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 effectively doesn't move us
forward because we have been "pushing" for a while.

And you can't blame tracking because everyone knows what has to happen.

---


> 
> Joshua D. Drake
> 
> 
> 
> > ---
> > 
> > Simon Riggs wrote:
> >> On Mon, 2007-01-01 at 19:04 -0500, Bruce Momjian wrote:
> >>
> >>> I will start processing the patches held for 8.3 this week or next, now
> >>> that the holiday break is over:
> >>>
> >>>   http://momjian.postgresql.org/cgi-bin/pgpatches_hold
> >>>
> >> The following patches don't appear on this list: 
> >>
> >> Concurrent psql
> >> Original submission
> >> http://archives.postgresql.org/pgsql-patches/2006-08/msg00249.php
> >> Latest
> >> http://archives.postgresql.org/pgsql-hackers/2006-12/msg00527.php
> >> Described here: http://community.enterprisedb.com/concurrent/index.html
> >>
> >> WAL Index Split
> >> Original submission
> >> http://archives.postgresql.org/pgsql-patches/2006-12/msg00045.php
> >> Latest
> >> http://archives.postgresql.org/pgsql-patches/2007-01/msg0.php
> >>
> >> Grouped Items
> >> Latest
> >> http://archives.postgresql.org/pgsql-patches/2006-11/msg00051.php
> >> Described here: http://community.enterprisedb.com/git/index.html
> >>
> >> Maintain Cluster Order
> >> http://archives.postgresql.org/pgsql-patches/2006-08/msg00124.php
> >>
> >> All have been awaiting review for at least a month (though in one case
> >> the latest version is quite recent). They probably ought to be on the
> >> hold queue; all are ready to be reviewed for final
> >> application/rejection.
> >>
> >> I'd hasten to add that none of those are mine. My patches have received
> >> good attention, so I'm not complaining just completing admin.
> >>
> >> -- 
> >>   Simon Riggs 
> >>   EnterpriseDB   http://www.enterprisedb.com
> >>
> >>
> >>
> >> ---(end of broadcast)---
> >> TIP 3: Have you checked our extensive FAQ?
> >>
> >>http://www.postgresql.org/docs/faq
> > 
> 
> 
> ---(end of broadcast)---
> TIP 2: Don't 'kill -9' the postmaster

-- 
  Bruce Momjian  <[EMAIL PROTECTED]>  http://momjian.us
  EnterpriseDB   http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster

Re: [HACKERS] Not ready for 8.3

[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 patches without a 
> > reviewer as of now to 8.4.
> > 
> > Leaving only those patches that have confirmed reviewers to be worked 
> > through.
> > 
> > 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.
> 
> I did one of those for previous releases.  I guess you forgot.  It was
> done by someone else this time only because I was going to be traveling.

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.

Speaking of reviewers... should we put some thought into how we can
increase the number of people who can review code? It seems that's one
of our biggest bottlenecks...
-- 
Jim Nasby  [EMAIL PROTECTED]
EnterpriseDB  http://enterprisedb.com  512.569.9461 (cell)

---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
   subscribe-nomail command to [EMAIL PROTECTED] so that your
   message can get through to the mailing list cleanly

Re: [HACKERS] Not ready for 8.3

[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 links using the
> >> Message-Id but I doubt that's at all doable.
> > 
> > hrm - I see so is there a particular reason for that behaviour ?
> 
> They're stable until Bruce removes something from the queue. When
> something is removed, it's renumbered.
> 
> It's how mhonarc works. It's the same with the archives - if we delete a
> mail, they get renumbered. So we never should delete, we should just
> blank out, but it has happened a couple of times.

Isn't there any other archiver we could use? The lack of URL stability
in mhonarc is bad enough, but the cross-month issue is just horrible.
-- 
Jim Nasby  [EMAIL PROTECTED]
EnterpriseDB  http://enterprisedb.com  512.569.9461 (cell)

---(end of broadcast)---
TIP 6: explain analyze is your friend

Re: [HACKERS] Not ready for 8.3

[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 comment) then I suggest we push all patches without a 
> > > reviewer as of now to 8.4.
> > > 
> > > Leaving only those patches that have confirmed reviewers to be worked 
> > > through.
> > > 
> > > 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.
> > 
> > I did one of those for previous releases.  I guess you forgot.  It was
> > done by someone else this time only because I was going to be traveling.
> 
> 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.

Sure.  Good idea.  All I had to do was ask (10 times, though).  ;-)

> Speaking of reviewers... should we put some thought into how we can
> increase the number of people who can review code? It seems that's one
> of our biggest bottlenecks...

Sure.  That is going to move us forward.

-- 
  Bruce Momjian  <[EMAIL PROTECTED]>  http://momjian.us
  EnterpriseDB   http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
   choose an index scan if your joining column's datatypes do not
   match

Re: [HACKERS] Not ready for 8.3

[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 be much nicer to have links using the
> > >> Message-Id but I doubt that's at all doable.
> > > 
> > > hrm - I see so is there a particular reason for that behaviour ?
> > 
> > They're stable until Bruce removes something from the queue. When
> > something is removed, it's renumbered.
> > 
> > It's how mhonarc works. It's the same with the archives - if we delete a
> > mail, they get renumbered. So we never should delete, we should just
> > blank out, but it has happened a couple of times.
> 
> Isn't there any other archiver we could use? The lack of URL stability
> in mhonarc is bad enough, but the cross-month issue is just horrible.

Agreed.  It is just crippled.

-- 
  Bruce Momjian  <[EMAIL PROTECTED]>  http://momjian.us
  EnterpriseDB   http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

---(end of broadcast)---
TIP 6: explain analyze is your friend

Re: [HACKERS] Bulk inserts and usage_count

[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 
 
> A fix for COPY will fall naturally out of the buffer ring patch, but not 
> for INSERT.
> 
> A more general fix would be to somehow keep the last insertion page 
> pinned across calls to heap_insert.

ISTR discussion in the past about having things like COPY and INSERT
INTO ... SELECT building entire pages in one shot once they exhaust the
FSM. Not only would it address this issue, but it would probably improve
performance in many ways (less locking and unlocking, ability to
pre-sort before inserting into indexes, fewer calls to FSM, probably a
bunch of other things).
-- 
Jim Nasby  [EMAIL PROTECTED]
EnterpriseDB  http://enterprisedb.com  512.569.9461 (cell)

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster

Re: [HACKERS] Not ready for 8.3

[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.
> 
> Sure.  Good idea.  All I had to do was ask (10 times, though).  ;-)
 
Even having to ask 10 times undoubtedly was a lot faster than doing it
yourself though. :)

> > Speaking of reviewers... should we put some thought into how we can
> > increase the number of people who can review code? It seems that's one
> > of our biggest bottlenecks...
> 
> Sure.  That is going to move us forward.

So... any ideas? :)
-- 
Jim Nasby  [EMAIL PROTECTED]
EnterpriseDB  http://enterprisedb.com  512.569.9461 (cell)

---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate

Re: [HACKERS] Not ready for 8.3

[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 can update
> > > a wiki.
> > 
> > Sure.  Good idea.  All I had to do was ask (10 times, though).  ;-)
>  
> Even having to ask 10 times undoubtedly was a lot faster than doing it
> yourself though. :)

Very true.

> > > Speaking of reviewers... should we put some thought into how we can
> > > increase the number of people who can review code? It seems that's one
> > > of our biggest bottlenecks...
> > 
> > Sure.  That is going to move us forward.
> 
> So... any ideas? :)

No, that is my problem.  I was hoping others would come up with some.  I
think communicating the problem is part of the solution.

-- 
  Bruce Momjian  <[EMAIL PROTECTED]>  http://momjian.us
  EnterpriseDB   http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq

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

[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 Fri, 2007-03-09 at 11:15 -0500, Tom Lane wrote:
> > >> It strikes me that allowing archive_command to be changed on the fly
> > >> might not be such a good idea though, or at least it shouldn't be
> > >> possible to flip it from empty to nonempty during live operation.
> > 
> > > I'd rather fix it the proposed way than force a restart. ISTM wrong to
> > > have an availability feature cause downtime.
> > 
> > I don't think that people are very likely to need to turn archiving on
> > and off on-the-fly.  Your proposed solution introduces a great deal of
> > complexity (and risk of future bugs-of-omission, to say nothing of race
> > conditions) to solve a non-problem.  We have better things to be doing
> > with our development time.
> 
> It's certainly a quicker fix. Unless others object, I'll set
> archive_command to only be changeable at server startup.
> 
> -- 
>   Simon Riggs 
>   EnterpriseDB   http://www.enterprisedb.com
> 
> 
> 
> ---(end of broadcast)---
> TIP 6: explain analyze is your friend

-- 
  Bruce Momjian  <[EMAIL PROTECTED]>  http://momjian.us
  EnterpriseDB   http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq

Re: [HACKERS] 8.3 pending patch queue

[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 them for 8.4 effectively doesn't move us
forward because we have been "pushing" for a while.


Hmm, I don't agree..

Two steps forward, one step back.

You are still going forward.



And you can't blame tracking because everyone knows what has to happen.



I am not blaming the tracker, the tracker is only part of the equation. 
IMO this particular problem is about a lot of people wanting to eat ice 
cream without doing their chores first.


All due respect to all the great developers that submitted patches but 
they submitted all of these features and have reviewed few of the patches.


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 someone review another three..." We wouldn't have this 
problem.


Tom said it best (incomplete quote) a lot of people tried to run before 
they could walk.


Sincerely,

Joshua D. Drake




---



Joshua D. Drake




---

Simon Riggs wrote:

On Mon, 2007-01-01 at 19:04 -0500, Bruce Momjian wrote:


I will start processing the patches held for 8.3 this week or next, now
that the holiday break is over:

http://momjian.postgresql.org/cgi-bin/pgpatches_hold

The following patches don't appear on this list: 


Concurrent psql
Original submission
http://archives.postgresql.org/pgsql-patches/2006-08/msg00249.php
Latest
http://archives.postgresql.org/pgsql-hackers/2006-12/msg00527.php
Described here: http://community.enterprisedb.com/concurrent/index.html

WAL Index Split
Original submission
http://archives.postgresql.org/pgsql-patches/2006-12/msg00045.php
Latest
http://archives.postgresql.org/pgsql-patches/2007-01/msg0.php

Grouped Items
Latest
http://archives.postgresql.org/pgsql-patches/2006-11/msg00051.php
Described here: http://community.enterprisedb.com/git/index.html

Maintain Cluster Order
http://archives.postgresql.org/pgsql-patches/2006-08/msg00124.php

All have been awaiting review for at least a month (though in one case
the latest version is quite recent). They probably ought to be on the
hold queue; all are ready to be reviewed for final
application/rejection.

I'd hasten to add that none of those are mine. My patches have received
good attention, so I'm not complaining just completing admin.

--
  Simon Riggs 
  EnterpriseDB   http://www.enterprisedb.com




---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq


---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster





---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at

   http://www.postgresql.org/about/donate

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

[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 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 Fri, 2007-03-09 at 11:15 -0500, Tom Lane wrote:
> > > >> It strikes me that allowing archive_command to be changed on the fly
> > > >> might not be such a good idea though, or at least it shouldn't be
> > > >> possible to flip it from empty to nonempty during live operation.
> > > 
> > > > I'd rather fix it the proposed way than force a restart. ISTM wrong to
> > > > have an availability feature cause downtime.
> > > 
> > > I don't think that people are very likely to need to turn archiving on
> > > and off on-the-fly.  Your proposed solution introduces a great deal of
> > > complexity (and risk of future bugs-of-omission, to say nothing of race
> > > conditions) to solve a non-problem.  We have better things to be doing
> > > with our development time.
> > 
> > It's certainly a quicker fix. Unless others object, I'll set
> > archive_command to only be changeable at server startup.
> > 
> > -- 
> >   Simon Riggs 
> >   EnterpriseDB   http://www.enterprisedb.com
> > 
> > 
> > 
> > ---(end of broadcast)---
> > TIP 6: explain analyze is your friend
> 
> -- 
>   Bruce Momjian  <[EMAIL PROTECTED]>  http://momjian.us
>   EnterpriseDB   http://www.enterprisedb.com
> 
>   + If your life is a hard drive, Christ can be your backup. +
> 
> ---(end of broadcast)---
> TIP 3: Have you checked our extensive FAQ?
> 
>http://www.postgresql.org/docs/faq
> 

-- 
Jim Nasby  [EMAIL PROTECTED]
EnterpriseDB  http://enterprisedb.com  512.569.9461 (cell)

---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate

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

[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 valid any longer.
> 
> On Tue, May 15, 2007 at 07:30:58PM -0400, Bruce Momjian wrote:
> > 
> > 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 Fri, 2007-03-09 at 11:15 -0500, Tom Lane wrote:
> > > > >> It strikes me that allowing archive_command to be changed on the fly
> > > > >> might not be such a good idea though, or at least it shouldn't be
> > > > >> possible to flip it from empty to nonempty during live operation.
> > > > 
> > > > > I'd rather fix it the proposed way than force a restart. ISTM wrong to
> > > > > have an availability feature cause downtime.
> > > > 
> > > > I don't think that people are very likely to need to turn archiving on
> > > > and off on-the-fly.  Your proposed solution introduces a great deal of
> > > > complexity (and risk of future bugs-of-omission, to say nothing of race
> > > > conditions) to solve a non-problem.  We have better things to be doing
> > > > with our development time.
> > > 
> > > It's certainly a quicker fix. Unless others object, I'll set
> > > archive_command to only be changeable at server startup.
> > > 
> > > -- 
> > >   Simon Riggs 
> > >   EnterpriseDB   http://www.enterprisedb.com
> > > 
> > > 
> > > 
> > > ---(end of broadcast)---
> > > TIP 6: explain analyze is your friend
> > 
> > -- 
> >   Bruce Momjian  <[EMAIL PROTECTED]>  http://momjian.us
> >   EnterpriseDB   http://www.enterprisedb.com
> > 
> >   + If your life is a hard drive, Christ can be your backup. +
> > 
> > ---(end of broadcast)---
> > TIP 3: Have you checked our extensive FAQ?
> > 
> >http://www.postgresql.org/docs/faq
> > 
> 
> -- 
> Jim Nasby  [EMAIL PROTECTED]
> EnterpriseDB  http://enterprisedb.com  512.569.9461 (cell)

-- 
  Bruce Momjian  <[EMAIL PROTECTED]>  http://momjian.us
  EnterpriseDB   http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq

Re: [HACKERS] Not ready for 8.3

[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.
> > 
> > hrm - I see so is there a particular reason for that behaviour ?
> 
> They're stable until Bruce removes something from the queue. When
> something is removed, it's renumbered.
> 
> It's how mhonarc works. It's the same with the archives - if we delete a
> mail, they get renumbered. So we never should delete, we should just
> blank out, but it has happened a couple of times.

As I proposed for many times, why don't we add message number to each
subject line in mail? For example like this:

[HACKERS: 12345] Re: Not ready for 8.3

This way, we could always obtain stable (logical) pointer, without
reling on particular archival infrastructure.
--
Tatsuo Ishii
SRA OSS, Inc. Japan

---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
   choose an index scan if your joining column's datatypes do not
   match

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

[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
> > > 
> > > 
> > > I'll make the agreed changes by next Wed/Thurs. 
> > 
> > I have seen no patch yet with the agreed changes.
> 
> True, will be at least a few more days yet. 
> 
> I've got a few questions I'll post later today.

Again, I have seen no follup patch for this.  I would keep it for 8.4
but I am unsure what the issue even is, so I am deleting this message.

-- 
  Bruce Momjian  <[EMAIL PROTECTED]>  http://momjian.us
  EnterpriseDB   http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
   choose an index scan if your joining column's datatypes do not
   match

Re: [HACKERS] Not ready for 8.3

[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 the
> >> Message-Id but I doubt that's at all doable.
> >
> > hrm - I see so is there a particular reason for that behaviour ?
>
> They're stable until Bruce removes something from the queue. When
> something is removed, it's renumbered.
>
> It's how mhonarc works. It's the same with the archives - if we delete a
> mail, they get renumbered. So we never should delete, we should just
> blank out, but it has happened a couple of times.

As I proposed for many times, why don't we add message number to each
subject line in mail? For example like this:

[HACKERS: 12345] Re: Not ready for 8.3

This way, we could always obtain stable (logical) pointer, without
reling on particular archival infrastructure.



This sounds like a good idea to me - though I'm just a lurker on the list.

Nathan

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

[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 accumulate.
> 
> Yes
> 
> 
> I'll make the agreed changes by next Wed/Thurs. 

Ah, here is the item Simon was talking about.  Simon, when are we
getting the updated patch?  If not soon, the entire patch will be kept
for 8.4.

-- 
  Bruce Momjian  <[EMAIL PROTECTED]>  http://momjian.us
  EnterpriseDB   http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings

Re: [HACKERS] Seq scans roadmap

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




I am a little worried that there will be greater differences in position
as the number of scans increase. If we have only 8 buffers and several
scans progressing, will they all be able to stay within a few buffers of
eachother at any given time?


I'm not sure. Needs testing. Assuming the scan leaves behind a cache 
trail in the OS cache as well, it might not be that bad if a scan 
joining the party starts a little bit behind.



Also, with 8 buffers, that means each scan must report every 4 pages at
most (and maybe every page), which increases lock contention (the new
design Heikki and I discussed requires a lock every time a backend
reports its position).


Keep in mind that processing a 32K page takes longer than processing an 
8K page.


But we'll see..

--
  Heikki Linnakangas
  EnterpriseDB   http://www.enterprisedb.com

---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
  choose an index scan if your joining column's datatypes do not
  match

Re: [HACKERS] Not ready for 8.3

[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 that's at all doable.
> > > 
> > > hrm - I see so is there a particular reason for that behaviour ?
> > 
> > They're stable until Bruce removes something from the queue. When
> > something is removed, it's renumbered.
> > 
> > It's how mhonarc works. It's the same with the archives - if we delete a
> > mail, they get renumbered. So we never should delete, we should just
> > blank out, but it has happened a couple of times.
> 
> As I proposed for many times, why don't we add message number to each
> subject line in mail? For example like this:
> 
> [HACKERS: 12345] Re: Not ready for 8.3
> 
> This way, we could always obtain stable (logical) pointer, without
> reling on particular archival infrastructure.

While that helps, it does not actually allow software to link the
threads together, i.e. it can't tell which is the head and tail of the
thread.  The actual software needs to improve because the thread
information is already part of the email headers.

-- 
  Bruce Momjian  <[EMAIL PROTECTED]>  http://momjian.us
  EnterpriseDB   http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

---(end of broadcast)---
TIP 6: explain analyze is your friend

Re: [HACKERS] Not ready for 8.3

[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 is just delayed.
>
> Delayed isn't rejected, but it isn't accepted either.  I see that as
> unfair to patch submitters, and not making things any easier.  It just
> pushes our problem into 8.4.
>

So, I'm not sure that these are actual rules, but it's how I have always seen 
the process working:

a) if we cannot resolve a submitted patch of technical issues within a 
reasonable time, it gets pushed to the next release. 

it is at the discression of -core/reviewer to determine both what are 
unresolvable issues and what is an unreasonable time... but I think patches 
that are not making progress within a period of months probably qualify on 
both counts.   

b) the development branch for the next release is not opened until delayed 
patches are dealt with 

dealing with a patch may not mean committing it, if it determined that the 
flaws are enough that it just isnt ready, or the author decides they aren't 
ready to devote time to it. 

i think everyone understands we all want everyones patches to get in, but it 
isn't realistic to think that will happen every release.  

one of the reasons we have a feature freeze is because the community has 
decided that holding up a release for feature X isn't desirable; aiui all of 
the patches in the current queue have been given a once over, and some more 
than that; i'm sure that cycle could go on quite some time for some patches, 
so as unfortunate as it is, I think at some point you have to just suck it up 
and call it day.   all imho.

-- 
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster

[HACKERS] Error correction for n_dead_tuples

[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 fact that stats counter updates occur much later than the
> actions they count.  (My recent patch to rate-limit tabstat messages made
> that problem worse, but it existed anyway.)  What might make sense is for
> vacuum to count the number of dead-but-not-removable tuples it skips over,
> and apply that as the value of n_dead_tuples on receipt of the vacuum
> message (instead of setting to zero as now).  This is likely to be wrong
> with respect to the actions of transactions running concurrently with the
> vacuum, but I think so is the proposed patch; and at least in this form
> the error certainly cannot accumulate across vacuum cycles.

In my understanding, there are two proposal to change the way of updating
n_dead_tuples by vacuum presently:

  Set n_dead_tuples to the number of 
1. unvacuumable tuples the vacuum has seen
2. dead tuples reported to stats collector after the beginning of vacuum
  at the end of vacuum.

Both methods don't accumulate errors across vacuum cycles, because dead
tuples statistics at the beginning of vacuum is cleared in both of them.
Also, if there is no background updates, the n_dead_tuples is certainly
set to zero.

I think the 2nd is better. If we update or delete tuples in the pages
that have been already scanned by vacuum, the vaccum cannot see the
newly created dead tuples. The vacuum could report fewer number as
the unvacuumable tuples.

The following is a test with a patch of the 2nd fix. The vacuum reports
'960 dead row versions cannot be removed yet', that is used in 1st method,
but the actual dead tuples are 2000, that is used in 2nd method.
...so I'll propose the 2nd method again.

Comments welcome.


# SELECT n_live_tup, n_dead_tup FROM pg_stat_user_tables WHERE relname = 
'accounts';
 n_live_tup | n_dead_tup
+
 10 |  0

# vacuum verbose accounts; (and 'pgbench -n -N -t2000' concurrently)
INFO:  vacuuming "public.accounts"
INFO:  index "accounts_pkey" now contains 100778 row versions in 276 pages
DETAIL:  0 index row versions were removed.
0 index pages have been deleted, 0 are currently reusable.
CPU 0.00s/0.00u sec elapsed 0.70 sec.
INFO:  "accounts": found 0 removable, 100778 nonremovable row versions in 1679 
pages
DETAIL:  960 dead row versions cannot be removed yet.
There were 1626 unused item pointers.
876 pages contain useful free space.
0 pages are entirely empty.
CPU 0.00s/0.00u sec elapsed 5.78 sec.
VACUUM

# SELECT n_live_tup, n_dead_tup FROM pg_stat_user_tables WHERE relname = 
'accounts';
 n_live_tup | n_dead_tup
+
 10 |   2000

# SELECT tuple_count, dead_tuple_count FROM pgstattuple('accounts');
 tuple_count | dead_tuple_count
-+--
  10 | 2000

Regards,
---
ITAGAKI Takahiro
NTT Open Source Software Center


---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
   subscribe-nomail command to [EMAIL PROTECTED] so that your
   message can get through to the mailing list cleanly

Re: [HACKERS] 8.3 pending patch queue

[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
> someone review another three..." We wouldn't have this problem.

Isn't that the point of the feature freeze period?  To put 'development' off to 
the side and spend the time reviewing what is pending?

If ppl find it so inconviencing to not be able to submit patches becaus we're 
in a feature freeze, then won't that motivate them to do some review, get the 
patches cleared so that they *can* move on?

Someone (you, I think) advocated a '3 weeks and then dump the rest of the 
patches' (not quote as  strong of wording, but similar) ... why not split the 
patches list up:

submitted patches, not reviewed
reviewed patches, needs work, waiting on author
reviewed patches, ready for commit.

Once feature freeze started, the first list should only get small patches to 
it, easily reviewed and committed ... then, focus on reviewing list A and move 
the patch to list B or commit it ... once list A is cleared off, we go into 
Beta ... if a patch on list B gets re-submitted before Beta, it gets reviewed 
and either committed, or punt'd to the next release ...

That leaves Freeze -> Beta being as long as it takes to get thorugh List A ... 
and the only thing punt'd to the next release being that which really isn't 
ready ...


- 
Marc G. Fournier   Hub.Org Networking Services (http://www.hub.org)
Email . [EMAIL PROTECTED]  MSN . [EMAIL PROTECTED]
Yahoo . yscrappy   Skype: hub.orgICQ . 7615664
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (FreeBSD)

iD8DBQFGSnuT4QvfyHIvDvMRAmelAJ90HOW3iOYMABmA41XCjJnKV2urtwCfaFTt
nquLm5G2tVKMCH3Ld7znGQM=
=Vl54
-END PGP SIGNATURE-


---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
   subscribe-nomail command to [EMAIL PROTECTED] so that your
   message can get through to the mailing list cleanly

Re: [HACKERS] Not ready for 8.3

[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 to push 
back patches which are under active redevelopment (seqscan) if that 
redevelopment isn't a result of review neglect.

> > Obviously for 8.4 reviewers need to start reviewing stuff from the first
> > week of the development cycle.  I also don't actually see anything wrong
> > with a 3-month feature freeze if we can somehow branch development
> > earlier.  Easy for me to say, I know.
>
> 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 so that developers can work on the new version who 
are frozen out of the in-process one.

> Oleg has been producing new versions of his patch, and no one has
> objected to any of it, so I assume all the issues were addressed.
>
> As far was whether tsearch2 should be in core, I think most agreed that
> SQL support for full-text would make it easier to use, and that it is a
> fundamental technology.  As I remember, the only holdback was full
> multi-byte support, but that is done.

I'm going to echo Bruce on this; I've mentioned that TSearch was going into 
Core at conferences and the reaction from existing users has been very 
enthusiastic, ranging from "yippee!" to "about time!".  Our users hate the 
fact that FTS is a separate module.

-- 
Josh Berkus
PostgreSQL @ Sun
San Francisco

---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq

Re: [HACKERS] Not ready for 8.3

[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 doubt that's at all doable.
> > > > 
> > > > hrm - I see so is there a particular reason for that behaviour ?
> > > 
> > > They're stable until Bruce removes something from the queue. When
> > > something is removed, it's renumbered.
> > > 
> > > It's how mhonarc works. It's the same with the archives - if we delete a
> > > mail, they get renumbered. So we never should delete, we should just
> > > blank out, but it has happened a couple of times.
> > 
> > As I proposed for many times, why don't we add message number to each
> > subject line in mail? For example like this:
> > 
> > [HACKERS: 12345] Re: Not ready for 8.3
> > 
> > This way, we could always obtain stable (logical) pointer, without
> > reling on particular archival infrastructure.
> 
> While that helps, it does not actually allow software to link the
> threads together, i.e. it can't tell which is the head and tail of the
> thread.  The actual software needs to improve because the thread
> information is already part of the email headers.

I know. My point is, subject-with-sequence will guarantee at least we
do not lose the pointer completely.

Also it will help us searching particular message in the private mail
box.
--
Tatsuo Ishii
SRA OSS, Inc. Japan

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings

Re: [HACKERS] Not ready for 8.3

[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 so that developers can work on the new version who 
are frozen out of the in-process one.


  



I've argued this in the past. But be aware that it will make more work 
for committers. It is very far from cost-free.


cheers

andrew


---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at

   http://www.postgresql.org/about/donate