Re: [HACKERS] 8.5 development schedule

[Simon Riggs]

On Tue, 2009-06-30 at 21:04 +0300, Heikki Linnakangas wrote:
> Merlin Moncure wrote:
> > Given that there is also a lot of work on synchronous replication, is
> > it better to get the HS in so the SR stuff can use that as a baseline,
> > or to triage in both patches together?
> 
> Whichever finishes first. Although they're very useful together, there
> is little if any code-level dependency between them. It would be
> dangerous to have one wait for the other, as one or the other could well
> be delayed for some reason. We can't even be sure that both are finished
> in time for 8.5.

Code dependency is not the main worry. Developer and committer time and
attention is our scarcest resource and I expect it to remain so.

-- 
 Simon Riggs   www.2ndQuadrant.com
 PostgreSQL Training, Services and Support


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] 8.5 development schedule

[Simon Riggs]

On Tue, 2009-06-30 at 09:35 -0400, Robert Haas wrote:

> In any case, we probably need some weigh-in from Heikki and Simon on
> their plans for Hot Standby before we make any decisions...

We discussed this at the developer meeting in May.

I gave a clear commitment to getting Hot Standby into Postgres, and a
wish to see it in 8.5.

I'm going to attempt to get Sync Rep into core first, then Hot Standby.
There are not too many people that have good insight in these areas and
I think we need them all working together to successfully commit
anything to Postgres core that we all agree with. I believe its possible
that individuals may produce working solutions on their own, though I
also believe that constructive teamwork can produce better solutions.

-- 
 Simon Riggs   www.2ndQuadrant.com
 PostgreSQL Training, Services and Support


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Extensions User Design

[Dimitri Fontaine]

Hi,

While backporting UUID stuff to 8.2 where I'll need it (I wish I could
have more impact on PostgreSQL upgrade schedules... who doesn't), I
faced a problem I didn't foresee, and that we maybe should think about.

  http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/backports/

The idea in this backport is to have UUID as an extension to 8.2, which
was plain easy to do once you remember about adding the
PG_FUNCTION_INFO_V1() macro calls where they fit. Then there's the
uuid-ossp contrib stuff, already packaged as an extension, but with code
dependancy to the UUID provided functions (uuid_in, uuid_out).

What I ended up doing was duplicating code in order not to have to tweak
local_preload_libraries, so that uuid-ossp.so is self-contained.

Any advice or missing knowledge about loading modules which depends on
code from another module not already loaded in the backend is welcome :)

Josh Berkus  writes:
>>   - dependancy graph solving and automatic installation, with depends,
>> recommends and suggest sections and with rules/setup to choose what to
>> pull in by default...
>
> Uh-huh.  That'll be the day ...

So it seems we will have to teach the extension facility about loading
dependant extensions first when calling a function, which I guess we can
do as soon as we have the dependancies information in there?

(calling a function from 'MODULE_PATHNAME' will have the .so loaded, so
 I guess than knowing it depends on another 'MODULE_PATHNAME' will
 enable us to load those first)

Regards,
-- 
dim

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] 8.5 development schedule

[Simon Riggs]

On Tue, 2009-06-30 at 08:33 +0300, Peter Eisentraut wrote:

> Now that 8.4.0 is out the door, development for 8.5devel will be
> opened any day now.  But we haven't discussed the development timeline
> so far.

This is a wonderful thing. Development opening quickly and the idea of a
discussed and explicit dev schedule are both good news.

The differences between proposed schedules seems fairly small, so I have
no comment on them other than expressing happiness that they exist.
Thanks.

-- 
 Simon Riggs   www.2ndQuadrant.com
 PostgreSQL Training, Services and Support


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] 8.5 development schedule

[Simon Riggs]

On Wed, 2009-07-01 at 02:14 -0400, Robert Haas wrote:

> Basically, if we're too quick to bump patches to the next CommitFest,
> there will be only moderate resistance for the first N-1 CommitFests,
> but then for the last CommitFest people won't want to be bumped by a
> whole major release for what are basically minor issues.

That is an important point. Remember we are talking about non-committers
here.

Each commitfest needs to be about wrangling in the patches that are
exact or nearly there. Nothing is perfect, especially when the
definition of perfection is not controlled by the patch author. How can
anybody know what will or will not be objected to until the patch is
reviewed?

Committers don't submit perfect patches, they apply them piece by piece,
with comments about "I'll get back to that" or "still thinking of best
way to do it.". Look at the way FOREIGN DATA WRAPPERS got in. Half a
feature, piece by piece (I have zero objection to that, just an
example).

Saying that non-committers need to submit perfect patches or we reject
them just ends up with a pile up. Expecting people that haven't passed a
the bar exam to provide a higher standard of code than those that have
passed the test is obviously not going to work.

-- 
 Simon Riggs   www.2ndQuadrant.com
 PostgreSQL Training, Services and Support


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] pre-proposal: permissions made easier

[Chris Browne]

and...@dunslane.net (Andrew Dunstan) writes:

> Jeff Davis wrote:
>> On Mon, 2009-06-29 at 12:55 -0400, Tom Lane wrote:
>>
>>> I think it has to be looked at in comparison to more general
>>> prospective-permissions schemes;
>>
>> When I searched google for "prospective permissions", all I found were
>> links to messages in this thread ;)
>>
>> Can you refer me to a general prospective-permissions scheme that is
>> more widely accepted? Being more widely accepted also has the benefit
>> that users will feel more comfortable with the behavior.
>>
>>
>>
>
> Think of MySQL's wildcard permissions. They apply to any object
> whether that object is created before or after the rule is set,
> AIUI. That means the wildcard pattern is applied at the time the
> permission rule is referenced, rather than when the rule is created,
> thus applying it prospectively.
>
> It's a feature many users would like to have, although, as Tom rightly
> points out, it can be a bit of a footgun if used carelessly.

I'll point out, "for posterity", that way back in yesteryear, TOPS-10
(introduced in 1967) had a "declarative permissioning" system for file
access that resembles this.

The best description I'm aware of is the following:
   http://lkml.org/lkml/1999/2/5/2

A FILDAE config file for a particular user might look like the
following:

# anything in a directory named "private" is off limits
*/private/*:*:*:*:
# people in group "foo" get full (create, delete, read, write,
# execute) access to everything in the foo project directory
~/projects/foo/*:*:foo:*:cdrwx
# people playing mygame can update the high score file
~/mygame/score.dat:*:*:
~/mygame/bin/mygame:rw
# some friends have access to the RCS files for mygame
~/mygame/src/RCS/*:dennis,kevin,josh:*:
/usr/bin/ci:rw
~/mygame/src/RCS/*:dennis,kevin,josh:*:
/usr/bin/co:rw
# I'll put stuff I want everyone to read in my ~/public directory
# I'll make the public directory 744, so no one will actually have
# to check .access_list, but I'll still put in this entry for
completeness
~/public/*:*:*:*:r# anything left over gets no access*:*:*:*:

This obviously isn't notably SQL-like, but that's not the point :-).
-- 
"cbbrowne","@","cbbrowne.com"
http://www3.sympatico.ca/cbbrowne/lisp.html
Ubuntu is an ancient African word, meaning "can't configure Debian"

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] gin--a rule for function parameter

[Fly.Li]

version: PG8.2.2

MY Question:
Why must "take the same number of parameters" ?

" We can check that all the referenced instances of the same support routine 
number take the same number of parameters" ?

1 there is no results by running regress test as follow:
plsql/src/test/regress/sql/opr_sanity.sql
..
-- Unfortunately, we can't check the amproc link very well because the
-- signature of the function may be different for different support routines
-- or different base data types.
-- We can check that all the referenced instances of the same support
-- routine number take the same number of parameters, but that's about it
-- for a general check...
SELECT p1.amopclaid, p1.amprocnum,
 p2.oid, p2.proname,
 p3.opcname,
 p4.amopclaid, p4.amprocnum,
 p5.oid, p5.proname,
 p6.opcname
FROM sys_amproc AS p1, sys_proc AS p2, sys_opclass AS p3,
 sys_amproc AS p4, sys_proc AS p5, sys_opclass AS p6
WHERE p1.amopclaid = p3.oid AND p4.amopclaid = p6.oid AND
p3.opcamid = p6.opcamid AND p1.amprocnum = p4.amprocnum AND
p1.amproc = p2.oid AND p4.amproc = p5.oid AND
(p2.proretset OR p5.proretset OR p2.pronargs != p5.pronargs);

But,
contrib\tsearch2\tsearch.sql.in:
...
CREATE OPERATOR CLASS gin_tsvector_ops
DEFAULT FOR TYPE tsvector USING gin
AS
OPERATOR1   @@ (tsvector, tsquery),
OPERATOR2   @@@ (tsvector, tsquery) RECHECK,
FUNCTION1   bttextcmp(text, text),
FUNCTION2   gin_extract_tsvector(tsvector,internal),
FUNCTION3 
gin_extract_tsquery(tsquery,internal,internal),
FUNCTION4 
gin_ts_consistent(internal,internal,tsquery),
STORAGE text;

When I use tsearch2, I found that gin_extract_tsquery() has 3 parameters, it 
break the rule "take the same number of parameters".
So, who can tell me whether the rule is right?


Grateful,
Fly.Li

for example, "ginarrayextract" function has two parameters
--
 amopclaid | amprocnum | oid  |   proname   | opcname  | 
amopclaid | amprocnum | oid  |   proname   | opcname
---+---+--+-+--+---+---+--+-+--
  2771 | 3 | 2743 | ginarrayextract | _oidvector_ops



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Extensions User Design

[Tom Lane]

Dimitri Fontaine  writes:
> Any advice or missing knowledge about loading modules which depends on
> code from another module not already loaded in the backend is welcome :)

You should be able to configure the dynamic loader to do that, although
in the case of uuid I strongly doubt it's worth the trouble.
Duplicated code would be a lot simpler to manage ...

regards, tom lane

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] gin--a rule for function parameter

[Tom Lane]

"Fly.Li"  writes:
> version: PG8.2.2
> MY Question:
> Why must "take the same number of parameters" ?

Because the GIN code will call it with a particular number of arguments.

> When I use tsearch2, I found that gin_extract_tsquery() has 3 parameters, it 
> break the rule "take the same number of parameters".

3 is the correct number of parameters for an extractQuery function
(before 8.4 anyway), so I'm not clear what you are complaining about.

regards, tom lane

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Extensions User Design

[Dimitri Fontaine]

Tom Lane  writes:
> You should be able to configure the dynamic loader to do that, although
> in the case of uuid I strongly doubt it's worth the trouble.

In the context of the extensions facility, will we be able to do this
configuration automatically from the backend, or to "manually" load any
dependant .so?

> Duplicated code would be a lot simpler to manage ...

Ok, I'll keep it this way then.

Regards,
-- 
dim

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] 8.5 development schedule

[Kevin Grittner]

Bruce Momjian  wrote: 
 
> I realize there is the perception that the large patches that were
> eventually rejected held up the release, but for all the patches I
> can think of, they were not rejected immediately _because_ we had
> other valid patches to work on.  Once all valid patches were
> applied, we were quickly able to reject the large unready patches.
> 
> So, rejecting the large patches earily would not have significantly
> moved the release date earlier.
 
Like Robert, I'm extremely skeptical of this claim, for the same
reasons.
 
However, even the *possibility* that this could be true is pretty
scary.  If we need to effectively shut down new development for seven
months at the end of a release, in addition to the interim commit
fests, we'd better get a handle on why, so that can change.  To what
do you attribute the extended time needed to handle the final CF?
How can that be made better?
 
-Kevin

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Extensions User Design

[Tom Lane]

Dimitri Fontaine  writes:
> Tom Lane  writes:
>> You should be able to configure the dynamic loader to do that, although
>> in the case of uuid I strongly doubt it's worth the trouble.

> In the context of the extensions facility, will we be able to do this
> configuration automatically from the backend, or to "manually" load any
> dependant .so?

I have zero interest in trying to support either.  I doubt it's even
possible --- the backend code has no way to inform the dynamic loader
how to resolve cross-library references.  So if the DL doesn't already
understand the dependency it's never going to work.

regards, tom lane

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] Did COPY performance regression solve in 8.4rc2?

[Toshihiro Kitagawa]

COPY performance issue is discussed in the following threads,
and it seems the conclusion was 8.4rc2 has been improved.

 http://archives.postgresql.org/pgsql-hackers/2009-06/msg01133.php

However, I didn't see difference of COPY performance between 8.4rc1
and 8.4rc2.

It seems that a COPY to 8.4rc1 or 8.4rc2 using pgbench takes about 20%
longer than it does to 8.3.0.

* Test environment
- HP Proliant DL145 G3
- CentOS 5 x86_64 (kernel 2.6.18-8.1.8.el5)

* Test method
$ initdb --no-locale --encoding=UTF8
$ pg_ctl -w start
$ time pgbench -i -s 1000

* Changes of postgresql.conf
- max_connections = 200
- shared_buffers = 128MB
- logging_collector = on
- silent_mode = on

* results
8.4rc2
real28m42.437s
real28m33.411s
real28m28.136s

8.4rc1
real28m46.542s
real29m10.575s
real28m44.006s

8.3.0
real23m39.131s
real23m40.655s
real23m49.458s

Thanks,

-- 
Toshihiro Kitagawa 
SRA OSS, Inc. Japan


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Did COPY performance regression solve in 8.4rc2?

[Kevin Grittner]

Toshihiro Kitagawa  wrote: 
 
> - shared_buffers = 128MB
 
What happens with a larger value for shared_buffers?
 
-Kevin

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Extensions User Design

[Dimitri Fontaine]

Tom Lane  writes:
> I have zero interest in trying to support either.  I doubt it's even
> possible --- the backend code has no way to inform the dynamic loader
> how to resolve cross-library references.  So if the DL doesn't already
> understand the dependency it's never going to work.

Ok, that means less work for the extension facility (it was not
targetted for it's first incarnation anyway) stuff.

FWIW, I had in mind to use the dependancy information in the extension
meta-data to issue more than one "dlopen()" when a plugin function is
called. I'm being told that in my case linking uuid-ossp.so against
uuid.so should do the trick, though.

I'll drop the idea off the scope of the extension facility.

Regards,
-- 
dim

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] single bit integer (TINYINT) revisited for 8.5

[Caleb Cushing]

I'd like to see this topic revisited since as far as I can see it
hasn't been seriously discussed in years. I believe the main arguments
against are why do we need more more numeric datatypes and increased
maintenance. It would seem to me that a tinyint datatype maintenance
wise would get all the same updates as the other int types, making it
only a slight increase in maintenance. I think there was 1 more reason
but I can't find the original thread now.

most (if not all?) of posgresql's major competitor's (mysql, sql
server, db2, etc) support a single bit integer datatype. it would
bring increased compatibility with existing mysql apps esp, making
them easier to port.

It (in theory?) should also bring a speed enhancement where usable
since it would take less disk space.

A couple of times I've been told "you don't need tinyint, use boolean"
which is not true, several projects I've worked on I've needed and
integer field that supports number within a small range 0-5 1-10 1-100
or something similar. I end up using smallint but it's range is huge
for the actual requirements.
-- 
Caleb Cushing

http://xenoterracide.blogspot.com

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] 8.5 development schedule

[Josh Berkus]

Ugh, I disagree.  I agree that we were too generous with letting
people rework patches while the CommitFest was in progress (mostly, we
let people drop off the map for 3 weeks and then come back and say,
oh, here's my revised version).  But you have to allow a certain
amount of reworking as the CommitFest progresses, I think.  Otherwise,
it just takes way too long to get anything done.


Sure.  The key is "a *certain amount* of reworking".  Not failing to 
respond to review for 3 weeks at a time.  Not introducing APIs or syntax 
extensions which have never been discussed on -hackers before.  Not 
extensive performance testing.  Not saying "here's 3 parts out of 5 of 
the patch, I'll have the other two by the 15th". Not sumbitting a patch 
with no written specification or (for user-facing features) documentation.


That is, the *submitter* should at least think the patch is ready to go. 
 If people are submitting stuff they *know* isn't ready to commit, it 
should be with a "WIP" flag, which to the reviewers says "review this 
last, or not at all if we run out of time".


And, even if the submitter is being responsive, if we've spent 30 days 
being back-and-forth with the patch, it's just not ready.  Dragging that 
out to 60 days doesn't, according to our history, help.


> I also believe, although I cannot prove it, that it would have
> increased the pressure to get the remaining items dealt with.  When
> there are 100 patches, everyone can say "oh, well it doesn't matter
> whether I get this taken care of today, because there will still be 99
> other patches".  When there are 3 patches, that argument doesn't hold
> water.

I agree.  Closing out 11/08 accelerated once we were down to the last 5 
patches.


> If we need to effectively shut down new development for seven
> months at the end of a release, in addition to the interim commit
> fests, we'd better get a handle on why, so that can change.  To what
> do you attribute the extended time needed to handle the final CF?
> How can that be made better?

Exactly.  What I think we should be moving towards is the idea that 
*any* commitfest could, with another 30 days of housekeeping, become a 
final release.  The only way to release in a timely fashion is to always 
be ready to release -- this is not just my opinion, but the experience 
of the Ubuntu, Parrot, and several other projects.


Let me point out a worrisome trend:

7.2: 10 months
7.3: 9 months
7.4: 12 months
8.0: 13 months
8.1: 11 months
8.2: 13 months
8.3: 14 months
8.4: 16 months

That's a dangerous-looking progression.  What's worse is that the 
increasing time has always been associated with post feature-freeze; 
i.e. the not-fun post-development period.


Until we embrace the idea that patches will get integrated or rejected 
in a timely fashion, and that we *can* make a target release date, we 
won't.


--
Josh Berkus
PostgreSQL Experts Inc.
www.pgexperts.com

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] single bit integer (TINYINT) revisited for 8.5

[Kevin Grittner]

Caleb Cushing  wrote: 
 
> most (if not all?) of posgresql's major competitor's (mysql, sql
> server, db2, etc) support a single bit integer datatype.
 
> A couple of times I've been told "you don't need tinyint, use
> boolean" which is not true, several projects I've worked on I've
> needed and integer field that supports number within a small range
> 0-5 1-10 1-100 or something similar.
 
I think you mean byte where you've said bit.  Boolean would be
adequate for a single bit, and I haven't (so far) seen any database
which supports both a single-bit type and a boolean.  Many databases
support a TINYINT type as a single-byte value, although I'm not sure
there's consistency on whether that's a signed or unsigned value.
 
-Kevin

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] 8.5 development schedule

[Robert Haas]

On Wed, Jul 1, 2009 at 10:30 AM, Kevin
Grittner wrote:
> Bruce Momjian  wrote:
>> I realize there is the perception that the large patches that were
>> eventually rejected held up the release, but for all the patches I
>> can think of, they were not rejected immediately _because_ we had
>> other valid patches to work on.  Once all valid patches were
>> applied, we were quickly able to reject the large unready patches.
>>
>> So, rejecting the large patches earily would not have significantly
>> moved the release date earlier.
>
> Like Robert, I'm extremely skeptical of this claim, for the same
> reasons.
>
> However, even the *possibility* that this could be true is pretty
> scary.  If we need to effectively shut down new development for seven
> months at the end of a release, in addition to the interim commit
> fests, we'd better get a handle on why, so that can change.  To what
> do you attribute the extended time needed to handle the final CF?
> How can that be made better?

Hear, hear!

Tom wrote upthread:
# If you find yourself with nothing else to do except review a new patch
# during beta, then sure, go do it.  But is there *really* nothing you
# could be doing to help expedite the beta?

My honest answer to this question is that I have no idea. It was
pretty clear to me what I was supposed to be doing during CommitFest
(reviewing patches) but a lot less clear to me what I should be doing
during beta.  I know that there was an open items list, but it was
never really clear to me how I should help with that.   A lot of the
open items were pretty mushy, subjective issues, or that was how they
seemed to me - not so much "How are we going to fix this?" but "Is
this worth fixing?" and "What kind of fix is appropriate?".  IOW, what
they needed before any useful technical work could be done was
consensus.

Of course, both committers and non-committers need consensus to make
changes, but committers need a lot less consensus.  If no one strongly
objects, they just apply.  Non-committers, on the other hand, need the
affirmative support of a committer to actually perform the commit.
It's a lot easier to get to "no one things this is a really bad idea"
than it is to get to "one of these six people thinks this is a good
idea and that person is willing to devote an hour of their day (or
more) to making it happen".

It seems to me that the solution to this problem is pretty simple.
Committers need to say exactly what kind of help they want; they need
to affirmatively tell other people what to do.  If Tom wants someone
to develop a patch for bug XYZ, he should say that he is prepared to
apply such a patch and ask for volunteers.  That helps path authors in
three ways:

1. Prospective patch authors know that Tom thinks this is important
and that it could hold up the release.
2. Prospective patch authors know that this isn't something that Tom
is already working on.
3. Prospective path authors know that they have a good chance of
getting something applied quickly, without waiting 1-7 months for the
next CommitFest.

I think committers are reluctant to do this for fear of being seen as
pushy, or for fear of being seen to use their status as committers as
way to throw their weight around.  In fact, I've heard more than one
committer make statements of the form, well, we don't really have any
more weight to throw around than anyone else.  The problem with this
is that it's blatantly false, and no non-committer who has taken the
time to write a patch is under any contrary illusion.  If a hamster
and an elephant are trying to sit on the same bench, the hamster does
not want the elephant to assert that he is a hamster; he wants the
elephant to announce his choice of seat prior to putting his bottom in
it.

...Robert

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] Questions regarding PostgreSQL warm backup.

[Damon Xu]

Dear Mr. Masao

 

My name is Damon. 

 

I read your comments regarding pg_standby warm backup. "New trigger option
of pg_standby". 

 

I got several questions on this article.

 

1.   I don't know why I have to trigger twice when switching from
pg_standby status to normal status?  

I saw this Patch file, how do I use it?  Is it a trigger file? Or something
else? (

pgstandby_new_trigger_0325.patch)

 

Here's the content in the recovery.conf file:

restore_command = '/usr/local/pgsql/bin/pg_standby -l -d -s 5 -k 5 -t
/tmp/stopstandby.bin  /home/wal_log/ %f %p %r 2>>standby.log'

 

Thanks a lot.  

 

 

Damon Xu

Re: [HACKERS] Mention CITEXT in the FAQ

[David E . Wheeler]

On Feb 6, 2009, at 10:54 AM, David E. Wheeler wrote:


On Feb 6, 2009, at 9:43 AM, Bruce Momjian wrote:


Oh. That seems kind of odd?can you hang onto the patch until 8.4 is
released, then? This must happen all the time, no?


OK, I will hang on to it, but I will have to mention it is only in  
8.4

too.


Ah, yeah, I didn't put that in the patch…


Just a reminder, Bruce, to add the CITEXT bit to the FAQ when 8.4 is  
released. Is that supposed to be today?


Thanks,

David


citext_faq.patch
Description: Binary data

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Mention CITEXT in the FAQ

[Tom Lane]

"David E. Wheeler"  writes:
> Just a reminder, Bruce, to add the CITEXT bit to the FAQ when 8.4 is  
> released. Is that supposed to be today?

The FAQ is on the wiki now ... fix it yourself.

regards, tom lane

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] single bit integer (TINYINT) revisited for 8.5

[Josh Berkus]

Caleb.


I'd like to see this topic revisited since as far as I can see it
hasn't been seriously discussed in years. I believe the main arguments
against are why do we need more more numeric datatypes and increased
maintenance. It would seem to me that a tinyint datatype maintenance
wise would get all the same updates as the other int types, making it
only a slight increase in maintenance. I think there was 1 more reason
but I can't find the original thread now.


The main reason not to have one is that given byte-alignment, 95% of the 
time using a tinyint would save no actual disk space or memory over just 
using INT2 (or indeed INT4).  I'll point out that the MySQLers are 
enamored of the 3-byte integer, which even on MySQL saves zero space or 
memory over using a 4-byte.  Just because people like it doesn't mean it 
works.


So the only real point in having an INT1 would be if you had a table 
with a lot of them in a row; an unusual but not unheard-of design. 
Still, that makes this feature less-than-critical for most users.


But ... the nice thing about PostgreSQL is that data types can be loaded 
at runtime.  Which means that you don't need INT1 in core for it to be 
useful to you and others; just write the data type and put it on 
pgFoundry.  Then submit it for /contrib for 8.5, and we'll see how 
popular the idea is.


Overall, I'm not keen on it.  For the handful of times when 
peformance-optimization-by-datatype makes sense, there's a large number 
where it's develpers who have no idea what they're doing.  We should be 
moving in the direction of having the database engine take care of space 
optimizations, not having the user do it.


--
Josh Berkus
PostgreSQL Experts Inc.
www.pgexperts.com

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Mention CITEXT in the FAQ

[David E. Wheeler]

On Jul 1, 2009, at 9:07 AM, Tom Lane wrote:


Just a reminder, Bruce, to add the CITEXT bit to the FAQ when 8.4 is
released. Is that supposed to be today?


The FAQ is on the wiki now ... fix it yourself.


It is? When did that happen?

Best,

David

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] single bit integer (TINYINT) revisited for 8.5

[Tom Lane]

Josh Berkus  writes:
> But ... the nice thing about PostgreSQL is that data types can be loaded 
> at runtime.  Which means that you don't need INT1 in core for it to be 
> useful to you and others; just write the data type and put it on 
> pgFoundry.

Yeah.  The argument against that used to be that you couldn't integrate
it properly into the numeric type hierarchy, but I think that's no
longer the case now that add-on types can define which type category
they belong to.  At the very least it would be useful to try to do it
as an add-on and see if there are still any obstacles to that.

Which of course brings up the other argument against doing it, which
was that it'd possibly mess up the rather delicate arrangement of
implicit promotions among the numeric types.  That was based on very
old bad experiences, though, so I'm not certain if there's still a
problem.  Again, if there is a reason why an add-on type couldn't solve
the problem while a built-in type could, I'd be more interested in
finding and fixing that problem than in the value of INT1 per se.

regards, tom lane

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Mention CITEXT in the FAQ

[Joshua D. Drake]

On Wed, 2009-07-01 at 09:15 -0700, David E. Wheeler wrote:
> On Jul 1, 2009, at 9:07 AM, Tom Lane wrote:
> 
> >> Just a reminder, Bruce, to add the CITEXT bit to the FAQ when 8.4 is
> >> released. Is that supposed to be today?
> >
> > The FAQ is on the wiki now ... fix it yourself.
> 
> It is? When did that happen?

Quite some time ago.

Joshua D. Drake


> 
> Best,
> 
> David
> 
-- 
PostgreSQL - XMPP: jdr...@jabber.postgresql.org
   Consulting, Development, Support, Training
   503-667-4564 - http://www.commandprompt.com/
   The PostgreSQL Company, serving since 1997


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] single bit integer (TINYINT) revisited for 8.5

[Caleb Cushing]

On Wed, Jul 1, 2009 at 11:41 AM, Kevin
Grittner wrote:
> I think you mean byte where you've said bit.

you're correct. I'm being a nerf.

>  Boolean would be
> adequate for a single bit, and I haven't (so far) seen any database
> which supports both a single-bit type and a boolean.

wasn't aware of that. I'm admittedly most familiar with sqlite,
postgres, and mysql

>  Many databases
> support a TINYINT type as a single-byte value, although I'm not sure
> there's consistency on whether that's a signed or unsigned value.

wouldn't any implementation in pg support both?

-- 
Caleb Cushing

http://xenoterracide.blogspot.com

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Mention CITEXT in the FAQ

[Tom Lane]

"David E. Wheeler"  writes:
> On Jul 1, 2009, at 9:07 AM, Tom Lane wrote:
>> The FAQ is on the wiki now ... fix it yourself.

> It is? When did that happen?

http://archives.postgresql.org/pgsql-committers/2009-04/msg00111.php

regards, tom lane

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Mention CITEXT in the FAQ

[David E. Wheeler]

On Jul 1, 2009, at 9:27 AM, Tom Lane wrote:


It is? When did that happen?


http://archives.postgresql.org/pgsql-committers/2009-04/msg00111.php


Thanks. Change added to the wiki.

Best,

David

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] single bit integer (TINYINT) revisited for 8.5

[Tom Lane]

Caleb Cushing  writes:
> On Wed, Jul 1, 2009 at 11:41 AM, Kevin
> Grittner wrote:
>> Many databases
>> support a TINYINT type as a single-byte value, although I'm not sure
>> there's consistency on whether that's a signed or unsigned value.

> wouldn't any implementation in pg support both?

Introducing unsigned types into PG is a whole different discussion.
The problem there is designing reasonable automatic promotion rules.
Considering that C's rules still confuse people after nigh 40 years,
I'm not enthusiastic about it ...

regards, tom lane

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] 8.5 development schedule

[Ron Mayer]

Tom Lane wrote:

"Joshua D. Drake"  writes:

We already push and pull our release dates based are what in the queue,
we just do so informally. Why not just make it part of the process?


I think we used to do it more or less like that, but people didn't like
it because they couldn't do any long-range planning.


Does the current system help long-range planning?

I could imagine an enterprise plan that says "we'll upgrade to
the current production release in January [after christmas sales]";
or "we'll begin to upgrade the January after [feature-x] is in
production".

But in neither case does it help my long term planning to know if
the current version January release is scheduled to be called 8.4
or 8.5 or 9.1 (which is really all that the current system helps
me predict).


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] 8.5 development schedule

[Joshua Tolley]

On Wed, Jul 01, 2009 at 11:51:28AM -0400, Robert Haas wrote:
> Tom wrote upthread:
> # If you find yourself with nothing else to do except review a new patch
> # during beta, then sure, go do it.  But is there *really* nothing you
> # could be doing to help expedite the beta?
> 
> My honest answer to this question is that I have no idea. It was
> pretty clear to me what I was supposed to be doing during CommitFest
> (reviewing patches) but a lot less clear to me what I should be doing
> during beta.  I know that there was an open items list, but it was
> never really clear to me how I should help with that. 

My feelings as well. During beta, there was clearly work for those with
experience in the areas with open items, and probably for committers
generally, but each time I reviewed the open items list I found little I could
do to help. If there's something I should have found, I'd love for someone to
point it out; in the meantime I tested betas and release candidates in
situtations common to my use of PostgreSQL, and found that it worked to my
satisfaction, after which I was left trying to figure out what to do, and
started dabbling in a patch or two that interested me.

> If a hamster
> and an elephant are trying to sit on the same bench, the hamster does
> not want the elephant to assert that he is a hamster; he wants the
> elephant to announce his choice of seat prior to putting his bottom in

Thanks, Robert -- this made me giggle :)

--
Joshua Tolley / eggyknap
End Point Corporation
http://www.endpoint.com


signature.asc
Description: Digital signature

Re: [HACKERS] single bit integer (TINYINT) revisited for 8.5

[Caleb Cushing]

On Wed, Jul 1, 2009 at 12:09 PM, Josh Berkus wrote:
> The main reason not to have one is that given byte-alignment, 95% of the
> time using a tinyint would save no actual disk space or memory over just
> using INT2 (or indeed INT4).  I'll point out that the MySQLers are enamored
> of the 3-byte integer, which even on MySQL saves zero space or memory over
> using a 4-byte.  Just because people like it doesn't mean it works.
>
> So the only real point in having an INT1 would be if you had a table with a
> lot of them in a row; an unusual but not unheard-of design. Still, that
> makes this feature less-than-critical for most users.

The primary type of field that I see it used as involves some sort of
statistics collection. like ratings, or maybe "strongly agree -
strongly disagree" (this could be in hundreds of colums), even
collecting gender's is appropriate if I recall.. as the iso for
genders is an integer with like 4 possible value's. At least this is
my thought, and a lot of these things end up in the same table.

It's not critical, but I'd suggest the benefits outweigh the costs.

> But ... the nice thing about PostgreSQL is that data types can be loaded at
> runtime.  Which means that you don't need INT1 in core for it to be useful
> to you and others; just write the data type and put it on pgFoundry.  Then
> submit it for /contrib for 8.5, and we'll see how popular the idea is.

I suppose I can see what I can do to this end (since it seems to be
the consensus) although it'll take me a while given I've no idea what
I'm doing... I can read C better than I write it, which doesn't say
much. On the other hand I'd think this would be on the list of
'easiest things to do' which means I should be able to get it done.

> Overall, I'm not keen on it.  For the handful of times when
> peformance-optimization-by-datatype makes sense, there's a large number
> where it's develpers who have no idea what they're doing.  We should be
> moving in the direction of having the database engine take care of space
> optimizations, not having the user do it.

eh... not sure I agree on that 100%... but to some degree that's what
sql is for... at the same time that kinda sounds like sqlite's more
dynamic like typing. but it is another discussion

-- 
Caleb Cushing

http://xenoterracide.blogspot.com

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] 8.5 development schedule

[Kevin Grittner]

Ron Mayer  wrote: 
 
> I could imagine an enterprise plan that says "we'll upgrade to
> the current production release in January [after christmas sales]";
> or "we'll begin to upgrade the January after [feature-x] is in
> production".
> 
> But in neither case does it help my long term planning to know if
> the current version January release is scheduled to be called 8.4
> or 8.5 or 9.1 (which is really all that the current system helps
> me predict).
 
It would help with that if you didn't plan on features which had not
been committed, and the release date didn't slip.  It's been a little
embarrassing at times to have told people not to try to mitigate
performance problems on the application side because I've confirmed
that the semijoin / antijoin code already committed to the 8.4 release
solves the problem, and the release was expected around the start of
the year.
 
Ultimately, I don't know that it makes sense to plan on any
feature until its patch is accepted, so the best you can do is try to
plan on when the accepted patches will become available.  Almost by
definition, if you want a guarantee that the feature will be in some
release, the date of the release becomes unknowable in advance.
 
-Kevin

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] 8.5 development schedule

[Alvaro Herrera]

Ron Mayer wrote:

> But in neither case does it help my long term planning to know if
> the current version January release is scheduled to be called 8.4
> or 8.5 or 9.1 (which is really all that the current system helps
> me predict).

The numbering is typically decided near the end of the devel cycle; it's
not set in stone from the beginning.  Witness how 8.0 was slated to be
called 7.5 until it was almost ready ...

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

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] 8.5 development schedule

[Bruce Momjian]

Kevin Grittner wrote:
> Bruce Momjian  wrote: 
>  
> > I realize there is the perception that the large patches that were
> > eventually rejected held up the release, but for all the patches I
> > can think of, they were not rejected immediately _because_ we had
> > other valid patches to work on.  Once all valid patches were
> > applied, we were quickly able to reject the large unready patches.
> > 
> > So, rejecting the large patches earily would not have significantly
> > moved the release date earlier.
>  
> Like Robert, I'm extremely skeptical of this claim, for the same
> reasons.
>  
> However, even the *possibility* that this could be true is pretty
> scary.  If we need to effectively shut down new development for seven
> months at the end of a release, in addition to the interim commit
> fests, we'd better get a handle on why, so that can change.  To what
> do you attribute the extended time needed to handle the final CF?
> How can that be made better?

We had many patches that had been through previous commit-fests with
minor adjustments and we had to finalize them before we could close the
final commit-fest.  To be clear I am talking about patches that were
eventually applied in 8.4, not patches that were rejected for 8.4.

-- 
  Bruce Momjian  http://momjian.us
  EnterpriseDB http://enterprisedb.com

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

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] 8.3 PLpgSQL Can't Compare Records?

[David E. Wheeler]

This code:

CREATE OR REPLACE FUNCTION foo() returns boolean as $$
DECLARE
have_rec record;
want_rec record;
BEGIN
have_rec := row(1, 2);
want_rec := row(3, 5);
RETURN have_rec IS DISTINCT FROM want_rec;
END;
$$ language plpgsql;

SELECT ROW(1, 2) IS DISTINCT FROM ROW(3, 5);

SELECT foo();
DROP FUNCTION foo();

Works as expected on 8.4, outputting:

 ?column?
--
 t
(1 row)

Time: 48.626 ms
 foo
-
 t
(1 row)

On 8.3, however, the row comparisons in the SQL statement works, but  
fails in the PL/pgSQL function, with this output:


 ?column?
--
 t
(1 row)

psql:huh.sql:14: ERROR:  operator does not exist: record = record
LINE 1: SELECT   $1  IS DISTINCT FROM  $2
 ^
HINT:  No operator matches the given name and argument type(s).  
You might need to add explicit type casts.

QUERY:  SELECT   $1  IS DISTINCT FROM  $2
CONTEXT:  PL/pgSQL function "foo" line 7 at RETURN


Is this a known issue in 8.3? If so, is there a known workaround?

Thanks,

David

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] 8.5 development schedule

[Kevin Grittner]

Bruce Momjian  wrote: 
> Kevin Grittner wrote:
>> To what do you attribute the extended time needed to handle the
>> final CF? How can that be made better?
> 
> We had many patches that had been through previous commit-fests with
> minor adjustments and we had to finalize them before we could close
> the final commit-fest.  To be clear I am talking about patches that
> were eventually applied in 8.4, not patches that were rejected for
> 8.4.
 
Thanks.  That answers the first question.
 
I guess it suggests that the second question could be refined to:
 
What could have been done to finalize these patches in earlier
commit-fests or bump them to 8.5 before they dragged the process of
wrapping the release by half a year?
 
-Kevin

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] 8.5 development schedule

[Tom Lane]

Ron Mayer  writes:
> Tom Lane wrote:
>> I think we used to do it more or less like that, but people didn't like
>> it because they couldn't do any long-range planning.

> Does the current system help long-range planning?

> I could imagine an enterprise plan that says "we'll upgrade to
> the current production release in January [after christmas sales]";
> or "we'll begin to upgrade the January after [feature-x] is in
> production".

You have forgotten the context.  This discussion is not about end-user
planning, it is about developer planning.  The issue is whether a
developer should work on feature A that he thinks will take about X
months to finish, or feature B that he thinks will take Y months.
For this purpose it is useful to have an idea of how long it will
be until the next feature freeze.  How long after that the release
will actually hit the street is interesting, but not directly relevant
to whether he's got a chance to get the feature in.

regards, tom lane

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] 8.5 development schedule

[Bruce Momjian]

Kevin Grittner wrote:
> Ron Mayer  wrote: 
>  
> > I could imagine an enterprise plan that says "we'll upgrade to
> > the current production release in January [after christmas sales]";
> > or "we'll begin to upgrade the January after [feature-x] is in
> > production".
> > 
> > But in neither case does it help my long term planning to know if
> > the current version January release is scheduled to be called 8.4
> > or 8.5 or 9.1 (which is really all that the current system helps
> > me predict).
>  
> It would help with that if you didn't plan on features which had not
> been committed, and the release date didn't slip.  It's been a little
> embarrassing at times to have told people not to try to mitigate
> performance problems on the application side because I've confirmed
> that the semijoin / antijoin code already committed to the 8.4 release
> solves the problem, and the release was expected around the start of
> the year.

Where did you see 8.4 was scheduled to be released around the start of
the year?  I never never seen that and would have disputed anyone saying
it publicly.

-- 
  Bruce Momjian  http://momjian.us
  EnterpriseDB http://enterprisedb.com

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

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] 8.5 development schedule

[Joshua D. Drake]

On Wed, 2009-07-01 at 13:39 -0400, Bruce Momjian wrote:

> Where did you see 8.4 was scheduled to be released around the start of
> the year?  I never never seen that and would have disputed anyone saying
> it publicly.

As I understood it, 8.4 was supposed to released at the beginning of Q2.
I never heard or read beginning of the year either.

Joshua D. Drake

-- 
PostgreSQL - XMPP: jdr...@jabber.postgresql.org
   Consulting, Development, Support, Training
   503-667-4564 - http://www.commandprompt.com/
   The PostgreSQL Company, serving since 1997


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] 8.5 development schedule

[Kevin Grittner]

Bruce Momjian  wrote: 
> Where did you see 8.4 was scheduled to be released around the start
of
> the year?  I never never seen that and would have disputed anyone
saying
> it publicly.
 
http://archives.postgresql.org/pgsql-hackers/2008-02/msg00193.php
 
That showed a January 1 beta release and a March 1 production release.
 
-Kevin

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] 8.5 development schedule

[Joshua D. Drake]

On Wed, 2009-07-01 at 12:47 -0500, Kevin Grittner wrote:
> Bruce Momjian  wrote: 
> > Where did you see 8.4 was scheduled to be released around the start
> of
> > the year?  I never never seen that and would have disputed anyone
> saying
> > it publicly.
>  
> http://archives.postgresql.org/pgsql-hackers/2008-02/msg00193.php
>  
> That showed a January 1 beta release and a March 1 production release.

Right that would be the expectation I had.

Joshua D. Drake

-- 
PostgreSQL - XMPP: jdr...@jabber.postgresql.org
   Consulting, Development, Support, Training
   503-667-4564 - http://www.commandprompt.com/
   The PostgreSQL Company, serving since 1997


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] 8.5 development schedule

[Kevin Grittner]

"Joshua D. Drake"  wrote: 
> On Wed, 2009-07-01 at 12:47 -0500, Kevin Grittner wrote:
 
>> http://archives.postgresql.org/pgsql-hackers/2008-02/msg00193.php
>>  
>> That showed a January 1 beta release and a March 1 production
>> release.
> 
> Right that would be the expectation I had.
 
The first of March is still well into the first quarter; but I was
getting confused about beta versus production release schedules when I
said the release was six months late; it was four months late -- to
the day.
 
-Kevin

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] 8.5 development schedule

[Tom Lane]

"Kevin Grittner"  writes:
> Bruce Momjian  wrote: 
>> Where did you see 8.4 was scheduled to be released around the start of
>> the year?
 
> http://archives.postgresql.org/pgsql-hackers/2008-02/msg00193.php
> That showed a January 1 beta release and a March 1 production release.

Terminological problem.  Around here, "release" *always* means
production release.  We don't expect end users to be very interested
in pre-production versions.

regards, tom lane

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] 8.5 development schedule

[Kevin Grittner]

Tom Lane  wrote: 
> "Kevin Grittner"  writes:
>> That showed a January 1 beta release and a March 1 production
>> release.
> 
> Terminological problem.  Around here, "release" *always* means
> production release.  We don't expect end users to be very interested
> in pre-production versions.
 
Well, I actually phrased it with managers here that 8.4 was scheduled
to go to beta on January 1st, but that the actual release date was
less predictable because the PostgreSQL community worries more about
having a solid release than hitting a release date.  Based on
discussions on the hackers list, I actually had the impression that
there would be a concerted effort to hit the beta date.
 
But, yeah -- on this thread I got the dates confused a bit.  I'm happy
to see that the slippage was less severe than I had got myself
thinking it was.  A third of a year, rather than half.
 
-Kevin

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] 8.5 development schedule

[Bruce Momjian]

Kevin Grittner wrote:
> "Joshua D. Drake"  wrote: 
> > On Wed, 2009-07-01 at 12:47 -0500, Kevin Grittner wrote:
>  
> >> http://archives.postgresql.org/pgsql-hackers/2008-02/msg00193.php
> >>  
> >> That showed a January 1 beta release and a March 1 production
> >> release.
> > 
> > Right that would be the expectation I had.
>  
> The first of March is still well into the first quarter; but I was
> getting confused about beta versus production release schedules when I
> said the release was six months late; it was four months late -- to
> the day.

OK, that is more accurate, but looking at the schedule:

1st November 2008 - final commit fest begins
1st January 2009 - beta 1
1st March 2009 - 8.4.0 release

How could we have possibly completed the last commit-fest and gotten
ready for beta in two months --- that is just not realistic.  I think we
anticipated a 2x longer final commit-fest, two months, but there was no
time scheduled for actual beta preparation.  I think there was some
ideal that we wouldn't need any time to prepare for beta and that we
would have dealt with all bugs by the time the last commit-fest is
complete, but that is illusory.

-- 
  Bruce Momjian  http://momjian.us
  EnterpriseDB http://enterprisedb.com

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

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] 8.5 development schedule

[Bruce Momjian]

Kevin Grittner wrote:
> Tom Lane  wrote: 
> > "Kevin Grittner"  writes:
> >> That showed a January 1 beta release and a March 1 production
> >> release.
> > 
> > Terminological problem.  Around here, "release" *always* means
> > production release.  We don't expect end users to be very interested
> > in pre-production versions.
>  
> Well, I actually phrased it with managers here that 8.4 was scheduled
> to go to beta on January 1st, but that the actual release date was
> less predictable because the PostgreSQL community worries more about
> having a solid release than hitting a release date.  Based on
> discussions on the hackers list, I actually had the impression that
> there would be a concerted effort to hit the beta date.
>  
> But, yeah -- on this thread I got the dates confused a bit.  I'm happy
> to see that the slippage was less severe than I had got myself
> thinking it was.  A third of a year, rather than half.

And I have just posted that a lack of scheduled time for beta
preparation was one reason for the slippage.

-- 
  Bruce Momjian  http://momjian.us
  EnterpriseDB http://enterprisedb.com

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

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] 8.5 development schedule

[Ron Mayer]

Bruce Momjian wrote:

Where did you see 8.4 was scheduled to be released around the start of
the year?  I never never seen that and would have disputed anyone saying
it publicly.


I think people carefully avoided the word "scheduled", but the
press FAQ on www.postgresql.org did say to expect it in Q4 08.


http://archives.postgresql.org/pgsql-general/2009-02/msg01265.php
http://www.postgresql.org/about/press/faq
  Q: When will 8.4 come out?
  A: Historically, PostgreSQL has released approximately
 every 12 months and there is no desire in the community
 to change from that pattern. So expect 8.4 sometime in
 the fourth quarter of 2008.


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] 8.5 development schedule

[Tom Lane]

Bruce Momjian  writes:
> OK, that is more accurate, but looking at the schedule:

>   1st November 2008 - final commit fest begins
>   1st January 2009 - beta 1
>   1st March 2009 - 8.4.0 release

> How could we have possibly completed the last commit-fest and gotten
> ready for beta in two months --- that is just not realistic.

We didn't know that at the time, though.  We thought the last CF would
take a month plus.  And up till November the CFs *were* getting done
in about a month.

In retrospect, the CF idea took some of the edge off the problem of
lots of large patches arriving at the feature freeze deadline, but it
is far from having eliminated the problem.

regards, tom lane

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] 8.5 development schedule

[Bruce Momjian]

Ron Mayer wrote:
> Bruce Momjian wrote:
> > Where did you see 8.4 was scheduled to be released around the start of
> > the year?  I never never seen that and would have disputed anyone saying
> > it publicly.
> 
> I think people carefully avoided the word "scheduled", but the
> press FAQ on www.postgresql.org did say to expect it in Q4 08.
> 
> 
> http://archives.postgresql.org/pgsql-general/2009-02/msg01265.php
> http://www.postgresql.org/about/press/faq
>Q: When will 8.4 come out?
>A: Historically, PostgreSQL has released approximately
>   every 12 months and there is no desire in the community
>   to change from that pattern. So expect 8.4 sometime in
>   the fourth quarter of 2008.

OK, now that someone has brought it up --- I have been disappointed with
the anticipated release dates we broadcast to the press --- without
community approval or oversight.  This is not the first time, but
hopefully it is the last.

-- 
  Bruce Momjian  http://momjian.us
  EnterpriseDB http://enterprisedb.com

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

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] 8.5 development schedule

[Kevin Grittner]

Bruce Momjian  wrote: 
 
> How could we have possibly completed the last commit-fest and gotten
> ready for beta in two months --- that is just not realistic.  I
> think we anticipated a 2x longer final commit-fest, two months, but
> there was no time scheduled for actual beta preparation.
 
For my edification, could you point me at something which identifies
the work needed after everything is committed and before the first
beta is released?  (I can't remember reading anything like that, but
it may have fallen through the cracks.)
 
If no such page exists, could you sketch out a brief outline?
 
> I think there was some ideal that we wouldn't need any time to
> prepare for beta and that we would have dealt with all bugs by the
> time the last commit-fest is complete, but that is illusory.
 
I thought one of the purposes of the two-month beta testing phase on
the calendar was to find and fix bugs.  That was in addition to the
two month final commit-fest.
 
-Kevin

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] 8.5 development schedule

[Tom Lane]

Ron Mayer  writes:
> Bruce Momjian wrote:
>> Where did you see 8.4 was scheduled to be released around the start of
>> the year?  I never never seen that and would have disputed anyone saying
>> it publicly.

> I think people carefully avoided the word "scheduled", but the
> press FAQ on www.postgresql.org did say to expect it in Q4 08.

> http://archives.postgresql.org/pgsql-general/2009-02/msg01265.php
> http://www.postgresql.org/about/press/faq
>Q: When will 8.4 come out?
>A: Historically, PostgreSQL has released approximately
>   every 12 months and there is no desire in the community
>   to change from that pattern. So expect 8.4 sometime in
>   the fourth quarter of 2008.

Whoever wrote that certainly didn't ask any of the core hackers about
the phrasing.

regards, tom lane

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] 8.5 development schedule

[Bruce Momjian]

Tom Lane wrote:
> Bruce Momjian  writes:
> > OK, that is more accurate, but looking at the schedule:
> 
> > 1st November 2008 - final commit fest begins
> > 1st January 2009 - beta 1
> > 1st March 2009 - 8.4.0 release
> 
> > How could we have possibly completed the last commit-fest and gotten
> > ready for beta in two months --- that is just not realistic.
> 
> We didn't know that at the time, though.  We thought the last CF would
> take a month plus.  And up till November the CFs *were* getting done
> in about a month.
> 
> In retrospect, the CF idea took some of the edge off the problem of
> lots of large patches arriving at the feature freeze deadline, but it
> is far from having eliminated the problem.

The beta preparation is dealing with all open issues, which is different
than the focus of the commit-fest.  Ideally we would be addressing those
open/bug issues during normal development, but for the hard problems
seem to linger and then we have to deal with them during beta
preparation, which can take 1-2 months.

-- 
  Bruce Momjian  http://momjian.us
  EnterpriseDB http://enterprisedb.com

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

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] 8.5 development schedule

[Tom Lane]

Bruce Momjian  writes:
> Tom Lane wrote:
>> In retrospect, the CF idea took some of the edge off the problem of
>> lots of large patches arriving at the feature freeze deadline, but it
>> is far from having eliminated the problem.

> The beta preparation is dealing with all open issues, which is different
> than the focus of the commit-fest.  Ideally we would be addressing those
> open/bug issues during normal development, but for the hard problems
> seem to linger and then we have to deal with them during beta
> preparation, which can take 1-2 months.

We've never scheduled a "beta preparation" phase like that before,
and I don't recall you complaining about the lack of one in the 8.4
schedule.  Personally I think the slip is entirely due to the final
CF taking five months (we closed it 25-March) where we'd expected
something closer to one month.

regards, tom lane

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] 8.5 development schedule

[Bruce Momjian]

Kevin Grittner wrote:
> Bruce Momjian  wrote: 
>  
> > How could we have possibly completed the last commit-fest and gotten
> > ready for beta in two months --- that is just not realistic.  I
> > think we anticipated a 2x longer final commit-fest, two months, but
> > there was no time scheduled for actual beta preparation.
>  
> For my edification, could you point me at something which identifies
> the work needed after everything is committed and before the first
> beta is released?  (I can't remember reading anything like that, but
> it may have fallen through the cracks.)
>  
> If no such page exists, could you sketch out a brief outline?

I just posted on this, but the answer is that commit-fest is for getting
patches applied --- it does not address open bugs that have to be
addressed before we can go to beta.  Those bugs could be new or could be
related to previously-applied patches.  That process can take 1-2
months.

>  
> > I think there was some ideal that we wouldn't need any time to
> > prepare for beta and that we would have dealt with all bugs by the
> > time the last commit-fest is complete, but that is illusory.
>  
> I thought one of the purposes of the two-month beta testing phase on
> the calendar was to find and fix bugs.  That was in addition to the
> two month final commit-fest.

But usually by the time we finish the last commit-fest, we already have
lots of bugs we know about (usually hard to fix), and it doesn't make
sense to go into beta with known bugs.

-- 
  Bruce Momjian  http://momjian.us
  EnterpriseDB http://enterprisedb.com

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

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] 8.5 development schedule

[Bruce Momjian]

Tom Lane wrote:
> Bruce Momjian  writes:
> > Tom Lane wrote:
> >> In retrospect, the CF idea took some of the edge off the problem of
> >> lots of large patches arriving at the feature freeze deadline, but it
> >> is far from having eliminated the problem.
> 
> > The beta preparation is dealing with all open issues, which is different
> > than the focus of the commit-fest.  Ideally we would be addressing those
> > open/bug issues during normal development, but for the hard problems
> > seem to linger and then we have to deal with them during beta
> > preparation, which can take 1-2 months.
> 
> We've never scheduled a "beta preparation" phase like that before,
> and I don't recall you complaining about the lack of one in the 8.4
> schedule.  Personally I think the slip is entirely due to the final
> CF taking five months (we closed it 25-March) where we'd expected
> something closer to one month.

I didn't bring it up because the schedule was kind of a first attempt
and it didn't make sense to try and tune it at that point.

-- 
  Bruce Momjian  http://momjian.us
  EnterpriseDB http://enterprisedb.com

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

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] 8.5 development schedule

[Kevin Grittner]

Bruce Momjian  wrote: 
> The beta preparation is dealing with all open issues, which is
> different than the focus of the commit-fest.  Ideally we would be
> addressing those open/bug issues during normal development, but for
> the hard problems seem to linger and then we have to deal with them
> during beta preparation, which can take 1-2 months.
 
Is there any way to move some of that work up into the earlier commit
fests?  (I'm afraid I still don't have my head around exactly what
sorts of issues are addressed in this phase.)
 
By the way, I hope that nobody is taking any of my observations or
questions as criticism or complaint.  It seems pretty obvious that the
process currently involves a fair amount of frustration and pain for
all involved, and I'm trying to brainstorm to help.  Don't think for a
minute that I forget or fail to appreciate the tremendous work you do,
along with that done by everyone else.
 
-Kevin

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] 8.3 PLpgSQL Can't Compare Records?

[Merlin Moncure]

On Wed, Jul 1, 2009 at 1:35 PM, David E. Wheeler wrote:
> This code:
>
>    CREATE OR REPLACE FUNCTION foo() returns boolean as $$
>    DECLARE
>        have_rec record;
>        want_rec record;
>    BEGIN
>        have_rec := row(1, 2);
>        want_rec := row(3, 5);
>        RETURN have_rec IS DISTINCT FROM want_rec;
>    END;
>    $$ language plpgsql;
>
>    SELECT ROW(1, 2) IS DISTINCT FROM ROW(3, 5);
>
>    SELECT foo();
>    DROP FUNCTION foo();
>
> Works as expected on 8.4, outputting:
>
>     ?column?
>    --
>     t
>    (1 row)
>
>    Time: 48.626 ms
>     foo
>    -
>     t
>    (1 row)
>
> On 8.3, however, the row comparisons in the SQL statement works, but fails
> in the PL/pgSQL function, with this output:
>
>     ?column?
>    --
>     t
>    (1 row)
>
>    psql:huh.sql:14: ERROR:  operator does not exist: record = record
>    LINE 1: SELECT   $1  IS DISTINCT FROM  $2
>                         ^
>    HINT:  No operator matches the given name and argument type(s). You might
> need to add explicit type casts.
>    QUERY:  SELECT   $1  IS DISTINCT FROM  $2
>    CONTEXT:  PL/pgSQL function "foo" line 7 at RETURN
>
>
> Is this a known issue in 8.3? If so, is there a known workaround?
>

fyi: works in 8.4, as part of a broad fix of composite type comparison ops

merlin

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] 8.3 PLpgSQL Can't Compare Records?

[Merlin Moncure]

On Wed, Jul 1, 2009 at 2:45 PM, Merlin Moncure wrote:
> On Wed, Jul 1, 2009 at 1:35 PM, David E. Wheeler wrote:
>> This code:
>>
>>    CREATE OR REPLACE FUNCTION foo() returns boolean as $$
>>    DECLARE
>>        have_rec record;
>>        want_rec record;
>>    BEGIN
>>        have_rec := row(1, 2);
>>        want_rec := row(3, 5);
>>        RETURN have_rec IS DISTINCT FROM want_rec;
>>    END;
>>    $$ language plpgsql;
>>
>>    SELECT ROW(1, 2) IS DISTINCT FROM ROW(3, 5);
>>
>>    SELECT foo();
>>    DROP FUNCTION foo();
>>
>> Works as expected on 8.4, outputting:
>>
>>     ?column?
>>    --
>>     t
>>    (1 row)
>>
>>    Time: 48.626 ms
>>     foo
>>    -
>>     t
>>    (1 row)
>>
>> On 8.3, however, the row comparisons in the SQL statement works, but fails
>> in the PL/pgSQL function, with this output:
>>
>>     ?column?
>>    --
>>     t
>>    (1 row)
>>
>>    psql:huh.sql:14: ERROR:  operator does not exist: record = record
>>    LINE 1: SELECT   $1  IS DISTINCT FROM  $2
>>                         ^
>>    HINT:  No operator matches the given name and argument type(s). You might
>> need to add explicit type casts.
>>    QUERY:  SELECT   $1  IS DISTINCT FROM  $2
>>    CONTEXT:  PL/pgSQL function "foo" line 7 at RETURN
>>
>>
>> Is this a known issue in 8.3? If so, is there a known workaround?
>>
>
> fyi: works in 8.4, as part of a broad fix of composite type comparison ops

whoops, you knew that already :-).  one possible workaround is:

select $1::text is distinct from $2::text;

merlin

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] 8.5 development schedule

[Bruce Momjian]

Kevin Grittner wrote:
> Bruce Momjian  wrote: 
> > The beta preparation is dealing with all open issues, which is
> > different than the focus of the commit-fest.  Ideally we would be
> > addressing those open/bug issues during normal development, but for
> > the hard problems seem to linger and then we have to deal with them
> > during beta preparation, which can take 1-2 months.
>  
> Is there any way to move some of that work up into the earlier commit
> fests?  (I'm afraid I still don't have my head around exactly what
> sorts of issues are addressed in this phase.)

Basically when someone reports a bug against CVS HEAD we try to fix it
but if the fix is complex, we usually just leave it for later, hence the
beta preparation time.  I think we assume some ideal fix will occur to
us but once we are near beta, we have no more time so we fix it as best
we can.

> By the way, I hope that nobody is taking any of my observations or
> questions as criticism or complaint.  It seems pretty obvious that the
> process currently involves a fair amount of frustration and pain for
> all involved, and I'm trying to brainstorm to help.  Don't think for a
> minute that I forget or fail to appreciate the tremendous work you do,
> along with that done by everyone else.

We understand your motivation.

-- 
  Bruce Momjian  http://momjian.us
  EnterpriseDB http://enterprisedb.com

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

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] 8.3 PLpgSQL Can't Compare Records?

[David E. Wheeler]

On Jul 1, 2009, at 11:47 AM, Merlin Moncure wrote:

fyi: works in 8.4, as part of a broad fix of composite type  
comparison ops


whoops, you knew that already :-).  one possible workaround is:

select $1::text is distinct from $2::text


Yes, and that's what I'm doing, although it is significantly less  
precise, in that:


* Columns with different types may successfully compare (e.g., NULL  
and '')

* No (easy) way to tell if two records have different numbers of columns

But it's good enough for 8.3 if there is no other workaround.

Thanks,

David

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] resetxlog bug

[Lorraine Mancuso]

Hi,

  I am currently running PG version 8.3.1. I am working in a test 
environment. I have a situation where the WAL file needed at startup no 
longer exists and I really don't care about it, therefore, I just want 
to reset the logs and go from there. However, after the pg_resetxlog, PG 
is still looking for the old file in the pg_xlog directory. Has this bug 
been fixed in a version beyond 8.3.1?


Thanks for your help!

 



   pg_resetxlog bug?



   * *From*: Fujii Masao 
   * *To*: PostgreSQL-development 
   * *Subject*: pg_resetxlog bug?
   * *Date*: Fri, 1 May 2009 00:07:26 +0900
   * *Message-id*:
 <3f0b79eb0904300807y43a96717ued641f6624c2...@mail.gmail.com
 
>
 http://archives.postgresql.org/msgtxt.php?id=3f0b79eb0904300807y43a96717ued641f6624c2...@mail.gmail.com>>

Re: [HACKERS] resetxlog bug

[Alvaro Herrera]

Lorraine Mancuso wrote:
> Hi,
>
>   I am currently running PG version 8.3.1. I am working in a test  
> environment. I have a situation where the WAL file needed at startup no  
> longer exists and I really don't care about it,

This is never true -- if you lose a WAL file, there is potential
corruption in the system catalogs.  So you always care about it.

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

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] 8.5 development schedule

[Tom Lane]

Bruce Momjian  writes:
> Kevin Grittner wrote:
>> However, even the *possibility* that this could be true is pretty
>> scary.  If we need to effectively shut down new development for seven
>> months at the end of a release, in addition to the interim commit
>> fests, we'd better get a handle on why, so that can change.  To what
>> do you attribute the extended time needed to handle the final CF?
>> How can that be made better?

> We had many patches that had been through previous commit-fests with
> minor adjustments and we had to finalize them before we could close the
> final commit-fest.  To be clear I am talking about patches that were
> eventually applied in 8.4, not patches that were rejected for 8.4.

I think this is simply not in agreement with the facts.  The patches
that caused the greatest amount of delay for 8.4 were the ones that
ultimately got rejected --- notably hot standby, sync rep, and
sepostgres.  Now the fact that everybody knew they would take awhile
provided some "cover" for other patches that weren't quite ready.
If we had bounced those three on Nov. 1 the commit fest would've been
a lot shorter.  Probably some other things that did get in would've
gotten bounced too, but on the whole I think the project would have been
better off.

The long and the short of it is that there is always tremendous pressure
to include patches that are on the edge of being ready, because we all
know that bouncing them to the next release cycle will mean an extra
year before they're available in production.  The dynamic in 8.4 was
exactly the same as it's been in the prior release cycles: we keep
slipping the possible release date and trying to get those patches
ready, and we don't give up until everyone agrees the release is just
hopelessly late.  As long as we keep behaving that way, no amount of
schedule-setting or rule-making is going to change anything.

It comes down to somebody having the willingness to say "no" and the
authority to make it stick.  Robert mentioned upthread that the
committers don't want to be seen as throwing their weight around,
which is quite true, but I have also noticed in the past that saying
"no" does not convince whoever is arguing that "this release will suck
if it doesn't have this feature".  And there's always somebody arguing
that side --- usually several people.

regards, tom lane

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] 8.5 development schedule

[Joshua D. Drake]

On Wed, 2009-07-01 at 17:01 -0400, Tom Lane wrote:

> It comes down to somebody having the willingness to say "no" and the
> authority to make it stick.  Robert mentioned upthread that the
> committers don't want to be seen as throwing their weight around,

Is that the purpose of core? To make exactly those decisions? 

Sincerely,

Joshua D. Drake

-- 
PostgreSQL - XMPP: jdr...@jabber.postgresql.org
   Consulting, Development, Support, Training
   503-667-4564 - http://www.commandprompt.com/
   The PostgreSQL Company, serving since 1997


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] 8.5 development schedule

[Tom Lane]

"Joshua D. Drake"  writes:
> On Wed, 2009-07-01 at 17:01 -0400, Tom Lane wrote:
>> It comes down to somebody having the willingness to say "no" and the
>> authority to make it stick.  Robert mentioned upthread that the
>> committers don't want to be seen as throwing their weight around,

> Is that the purpose of core? To make exactly those decisions? 

Core has never seen itself as intended to make feature-by-feature
decisions.  People seem to be willing to defer to us on release
schedule-setting, but it's not clear to me that the community has
delegated us more authority than that.

regards, tom lane

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] 8.5 development schedule

[Joshua D. Drake]

On Wed, 2009-07-01 at 17:13 -0400, Tom Lane wrote:
> "Joshua D. Drake"  writes:
> > On Wed, 2009-07-01 at 17:01 -0400, Tom Lane wrote:
> >> It comes down to somebody having the willingness to say "no" and the
> >> authority to make it stick.  Robert mentioned upthread that the
> >> committers don't want to be seen as throwing their weight around,
> 
> > Is that the purpose of core? To make exactly those decisions? 
> 
> Core has never seen itself as intended to make feature-by-feature
> decisions.  People seem to be willing to defer to us on release
> schedule-setting, but it's not clear to me that the community has
> delegated us more authority than that.

I would agree that having core decide on specific features is probably a
stretch but having core set a cut date to which *all* patches that don't
make that date? That seems within purview.

Sincerely,

Joshua D. Drake
 

-- 
PostgreSQL - XMPP: jdr...@jabber.postgresql.org
   Consulting, Development, Support, Training
   503-667-4564 - http://www.commandprompt.com/
   The PostgreSQL Company, serving since 1997


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] 8.5 development schedule

[Bruce Momjian]

Joshua D. Drake wrote:
> On Wed, 2009-07-01 at 17:13 -0400, Tom Lane wrote:
> > "Joshua D. Drake"  writes:
> > > On Wed, 2009-07-01 at 17:01 -0400, Tom Lane wrote:
> > >> It comes down to somebody having the willingness to say "no" and the
> > >> authority to make it stick.  Robert mentioned upthread that the
> > >> committers don't want to be seen as throwing their weight around,
> > 
> > > Is that the purpose of core? To make exactly those decisions? 
> > 
> > Core has never seen itself as intended to make feature-by-feature
> > decisions.  People seem to be willing to defer to us on release
> > schedule-setting, but it's not clear to me that the community has
> > delegated us more authority than that.
> 
> I would agree that having core decide on specific features is probably a
> stretch but having core set a cut date to which *all* patches that don't
> make that date? That seems within purview.

Define "make that date"?  That is the problem.

-- 
  Bruce Momjian  http://momjian.us
  EnterpriseDB http://enterprisedb.com

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

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] 8.5 development schedule

[Andrew Dunstan]

Tom Lane wrote:

"Joshua D. Drake"  writes:
  

On Wed, 2009-07-01 at 17:01 -0400, Tom Lane wrote:


It comes down to somebody having the willingness to say "no" and the
authority to make it stick.  Robert mentioned upthread that the
committers don't want to be seen as throwing their weight around,
  


  
Is that the purpose of core? To make exactly those decisions? 



Core has never seen itself as intended to make feature-by-feature
decisions.  People seem to be willing to defer to us on release
schedule-setting, but it's not clear to me that the community has
delegated us more authority than that.


  



You have correctly identified the requirement in the sentence quoted 
above. I for one am quite prepared to support core or some person 
designated by core having such authority. I agree with you that without 
something like that not much will improve.


cheers

andrew

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] 8.5 development schedule

[Robert Haas]

On Wed, Jul 1, 2009 at 5:01 PM, Tom Lane wrote:
> Bruce Momjian  writes:
>> Kevin Grittner wrote:
>>> However, even the *possibility* that this could be true is pretty
>>> scary.  If we need to effectively shut down new development for seven
>>> months at the end of a release, in addition to the interim commit
>>> fests, we'd better get a handle on why, so that can change.  To what
>>> do you attribute the extended time needed to handle the final CF?
>>> How can that be made better?
>
>> We had many patches that had been through previous commit-fests with
>> minor adjustments and we had to finalize them before we could close the
>> final commit-fest.  To be clear I am talking about patches that were
>> eventually applied in 8.4, not patches that were rejected for 8.4.
>
> I think this is simply not in agreement with the facts.  The patches
> that caused the greatest amount of delay for 8.4 were the ones that
> ultimately got rejected --- notably hot standby, sync rep, and
> sepostgres.  Now the fact that everybody knew they would take awhile

This is also how I remember it.

> provided some "cover" for other patches that weren't quite ready.
> If we had bounced those three on Nov. 1 the commit fest would've been
> a lot shorter.  Probably some other things that did get in would've
> gotten bounced too, but on the whole I think the project would have been
> better off.

It wasn't just the big patches that dragged on forever: for example,
updateable views got submitted literally hours before the start of the
CommitFest in a state where it did not even pass regression tests, I
reviewed it, there was a lng delay before resubmit, then it got
committed, then it got reverted.  If we had ejected that patch from
the queue (for non-resubmission, if nothing else) early on in the
process, it would have freed up at least three people's time (Tom's,
mine, Peter's) to work on other patches that were in better shape and
submitted sooner.

One of the WORST mistakes that we made with the November CommitFest
was to only assign reviewers to the small patches, figuring that the
committers would look at the big ones.  SE-PostgreSQL was not given a
reasonable review for a very long time.  What we need to do this time
is start with the biggest patches and assign the most capable
reviewers (committers, preferably) to those patches and then work down
the list.  This is another example of the uncomfortable dynamic
between committers and everyone else: non-committers don't feel
comfortable assigning committers to review patches, because who are we
to tell the commiters what to do?  But when the committers are the
only ones competent to do that review, the result is a huge vacuum.
We need to put some structure around this that works.

I do agree, however, that rejecting more patches sooner (in
particular, the ones that had been reviewed and found wanting) would
have been the way to go and good for the project.

> The long and the short of it is that there is always tremendous pressure
> to include patches that are on the edge of being ready, because we all
> know that bouncing them to the next release cycle will mean an extra
> year before they're available in production.  The dynamic in 8.4 was
> exactly the same as it's been in the prior release cycles: we keep
> slipping the possible release date and trying to get those patches
> ready, and we don't give up until everyone agrees the release is just
> hopelessly late.  As long as we keep behaving that way, no amount of
> schedule-setting or rule-making is going to change anything.

Yep.

> It comes down to somebody having the willingness to say "no" and the
> authority to make it stick.  Robert mentioned upthread that the
> committers don't want to be seen as throwing their weight around,
> which is quite true, but I have also noticed in the past that saying
> "no" does not convince whoever is arguing that "this release will suck
> if it doesn't have this feature".  And there's always somebody arguing
> that side --- usually several people.

Yep.  But having a review that clearly enumerates the reasons WHY the
patch needs to be rejected is certainly more compelling than a blanket
statement that the patch is big and invasive and therefore must have
bugs, even if we haven't looked at it enough to find them.  The
blanket statement may be quite true, but it doesn't provide feedback
to the patch author and so fails to accomplish one of the main
purposes of the CommitFests, at least IMO.

...Robert

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] 8.5 development schedule

[Kevin Grittner]

Bruce Momjian  wrote: 
 
> Define "make that date"?  That is the problem.
 
Not committed by that date.  I guess that leaves the issue of picking
a particular time in a particular time zone, but it doesn't otherwise
seem ambiguous.
 
Picture the New York Subway system.  You're coming down the stairs and
the train is in sight.  You either make it through the doors before
they close, or you don't.  If you don't, you wait for the next train. 
The system would never work if they held up the train for everyone in
sight of the train who hoped to get on to avoid the wait.  Nobody is
throwing their weight around when those doors close; it's just how the
system works.
 
-Kevin

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] 8.5 development schedule

[Bruce Momjian]

Kevin Grittner wrote:
> Bruce Momjian  wrote: 
>  
> > Define "make that date"?  That is the problem.
>  
> Not committed by that date.  I guess that leaves the issue of picking
> a particular time in a particular time zone, but it doesn't otherwise
> seem ambiguous.
>  
> Picture the New York Subway system.  You're coming down the stairs and
> the train is in sight.  You either make it through the doors before
> they close, or you don't.  If you don't, you wait for the next train. 
> The system would never work if they held up the train for everyone in
> sight of the train who hoped to get on to avoid the wait.  Nobody is
> throwing their weight around when those doors close; it's just how the
> system works.

The problem is that the committers control the commit date, but the one
seen as punished for a rejected patch is not the committers but the
submitter.

-- 
  Bruce Momjian  http://momjian.us
  EnterpriseDB http://enterprisedb.com

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

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] 8.5 development schedule

[Greg Stark]

On Tue, Jun 30, 2009 at 5:11 PM, Tom Lane wrote:

> I'm also not prepared to push a large and unstable feature into the tree
> on the hope that it will get fixed.

I didn't have the impression it had any known problems, Simon and
others spent a lot of time testing it already. The improvements Heikki
was asking for were simplifications or cleanup type changes and every
time he asked for something Simon had it done within a day or two.

The problem is I think this will *always* be a "large unstable
feature" just because it's large. If we aren't happy having it in the
tree for alpha releases then there's no circumstance we'll ever be
happy having it in a real release. I think it's a *lot* better having
it in the alpha releases when if we find problems we can revert it or
fix the problems than dropping it at the last second before the betas
when it has to be perfect and there's no second chances.

-- 
greg
http://mit.edu/~gsstark/resume.pdf

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] pg_migrator versus inherited columns

[Tom Lane]

I was testing pg_migrator the other day on the regression database,
and found out that it doesn't work:

Restoring database schema   
psql:/home/postgres/pg_migrator_dump_db.sql:4545: ERROR:  column 
"pg.dropped.1" of relation "dropcolumnchild" does not exist

Some investigation found out the reason.  pg_migrator needs to be able
to create tables that exactly match the physical column layout of the
old database, including dropped columns if any.  The way that it does
this is that the --binary-upgrade switch added to pg_dump causes pg_dump
to go ahead and include dropped columns in CREATE TABLE commands, and
then immediately drop them.  That's okay for simple tables, but it's
got exactly zero hope of working in inheritance scenarios.  A column
that was created and later dropped in a parent table might or might not
exist (though now dropped) in child tables.

More generally, the approach is fatally broken for inheritance children
even if they contain no dropped columns.  Adding a column to a parent
table results in child-table column ordering that is different from what
you get after a dump and reload, for example after

create table p (f1 int, f2 int);
create table c (f3 int) inherits (p);
alter table p add column f4 int;

the column order in c is f1,f2,f3,f4 ... but after dump and reload
it will be f1,f2,f4,f3, because f4 will be part of the initial
definition of p rather than getting tacked on later.

We understood years ago that pg_dump has to take extra measures to deal
with this --- that's why it has to use COPY with a column list.

The only solution I can see that has a chance of working without a
massive amount of new logic in pg_dump is to change the way that
inheritance is managed.  Instead of dumping the above situation as

create table p (f1 int, f2 int, f4 int);
create table c (f3 int) inherits (p);

I propose that when --binary-upgrade is active, it should be dumped as

create table p (f1 int, f2 int, f4 int);
create table c (f1 int, f2 int, f4 int, f3 int);
alter table c add inherit p;

(It's a good thing we added ADD INHERIT in 8.4, or we'd be completely
up the creek here.)  In this way we can ensure that the physical order
of columns really is what it needs to be in the child table.  Dropped
columns can then be managed in the same way as the current code does,
but it'll actually work.  (We have to drop them before doing the
ADD INHERIT of course.)

Comments?

regards, tom lane

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] 8.5 development schedule

[Kevin Grittner]

Bruce Momjian  wrote:
 
> The problem is that the committers control the commit date, but the
> one seen as punished for a rejected patch is not the committers but
> the submitter.
 
Well, it would seem odd for anyone to feel "punished".
 
If the patch isn't submitted in good form with the issues hashed out
in prior discussion, and the reviewer(s) and committer(s) can't
resolve the issues prior to the cutoff -- well, try to address those
issues for the next release.  Maybe submit with a bit more lead time
next time around.
 
As is often pointed out here, nothing stops you from using your own
patch if you need to.  We did so here, for example, with the standard
character string literals.  Had that patch never been accepted, we'd
still be patching new releases.  I'm sure that's not always an option,
but I'll bet it often is.
 
If the submitter is anxious to make a particular release, they should
be motivated to submit early, turn around quickly, and raise a fuss if
the patch seems to be wanting for attention.
 
One possible solution would be to have trains leaving the station more
often.  I know that the idea of more frequent releases has been
proposed and rejected before, but that option is sort of screaming to
be considered again in all of this.  Are the mentions of alpha
releases a way to edge into this area -- a feature which misses a
major release could be available to the intrepid within a month or
two, should it then be finished and committed, in a semi-formal way?
 
-Kevin

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] 8.5 development schedule

[Bruce Momjian]

bruce wrote:
> I realize there is the perception that the large patches that were
> eventually rejected held up the release, but for all the patches I can
> think of, they were not rejected immediately _because_ we had other
> valid patches to work on.  Once all valid patches were applied, we were
> quickly able to reject the large unready patches.
> 
> So, rejecting the large patches early would not have significantly
> moved the release date earlier.

I see no one agrees with my analysis --- no matter;  if I unreservedly
agreed with others, I wouldn't be here.  ;-)

There has been discussion about how to be more hard-nosed about
rejecting patches.  I think it has to start with us being more
hard-nosed about giving patches feedback --- the very idea we had to
create commit-fests reflects that we historically have not done an
organized job of processing patches.

If we review patches as soon as they appear, and give rapid feedback, we
can easily reject patches that take more than a few days for the patch
author to resolve, and there would be little slippage;  the same goes
for dealing with known bugs.  I know it can be done, but I don't promise
it would be pleasant.

-- 
  Bruce Momjian  http://momjian.us
  EnterpriseDB http://enterprisedb.com

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

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] 8.5 development schedule

[Bruce Momjian]

Greg Stark wrote:
> On Tue, Jun 30, 2009 at 5:11 PM, Tom Lane wrote:
> 
> > I'm also not prepared to push a large and unstable feature into the tree
> > on the hope that it will get fixed.
> 
> I didn't have the impression it had any known problems, Simon and
> others spent a lot of time testing it already. The improvements Heikki
> was asking for were simplifications or cleanup type changes and every
> time he asked for something Simon had it done within a day or two.
> 
> The problem is I think this will *always* be a "large unstable
> feature" just because it's large. If we aren't happy having it in the
> tree for alpha releases then there's no circumstance we'll ever be
> happy having it in a real release. I think it's a *lot* better having
> it in the alpha releases when if we find problems we can revert it or
> fix the problems than dropping it at the last second before the betas
> when it has to be perfect and there's no second chances.

By that logic we would never have accepted large patches, but we have,
often.

-- 
  Bruce Momjian  http://momjian.us
  EnterpriseDB http://enterprisedb.com

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

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] 8.5 development schedule

[Tom Lane]

Greg Stark  writes:
> On Tue, Jun 30, 2009 at 5:11 PM, Tom Lane wrote:
>> I'm also not prepared to push a large and unstable feature into the tree
>> on the hope that it will get fixed.

> I didn't have the impression it had any known problems, Simon and
> others spent a lot of time testing it already.

If it didn't have known problems it would have been committed in 8.4.

regards, tom lane

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] HEAD is open for 8.5 development

[Tom Lane]

Let the breakage begin ...

regards, tom lane

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] 8.5 development schedule

[Robert Haas]

On Wed, Jul 1, 2009 at 6:53 PM, Kevin
Grittner wrote:
> Bruce Momjian  wrote:
>
>> The problem is that the committers control the commit date, but the
>> one seen as punished for a rejected patch is not the committers but
>> the submitter.
>
> Well, it would seem odd for anyone to feel "punished".

Depends on who the patch submitter thinks is at fault.  Sometimes,
patches legitimately don't get reviewed as much as would be good.
Other times, the submitter just thinks the committer is nitpicking.  I
think Bruce summarized it pretty well.

Really, when you get right down to it, you can guarantee that all
patches get a certain amount of review, or you can guarantee that the
CommitFest ends by a certain date, but not both, because you can't
force other people to spend more time on PostgreSQL than they have to
spend.  At best, you can get them to spend the time that they do have
on the right sort of things (e.g. reviewing rather than developing new
patches during CommitFest).

Of course, since you want both of those things to happen, it's a balancing act.

...Robert

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [PATCH] [v8.5] Security checks on largeobjects

[KaiGai Kohei]

I could find one more issue when we apply largeobject-style interfaces
on generic toasted varlena data.

When we fetch a toasted datum, it scans the pg_toast_%u with SnapshotToast,
because it assumes any toasted chunks don't have multiple versions, and
visibility of the toast pointer always means visibility of the toast chunks.

However, if we provide largeobject-style interfaces which allow partial
updates on toasted varlena, it seems to me this assumption will get being
incorrect.

Is there any good idea?

KaiGai Kohei wrote:
> I concluded that the following issues should be solved when we apply
> largeobject-like interfaces on the big toasted data within general
> relations, not only pg_largeobject system catalog.
> 
> At first, we need to add a new strategy to store the given varlena data
> on the external toast relation.
> If we try to seek and fetch a certain data chunk, it is necessary to be
> computable what chunk stores the required data specified by offset and
> length. So, the external chunks should be uncompressed always. It is a
> common requirement for both of read and write operations.
> If we try to update a part of the toasted data chunks, it should not be
> inlined independent from length of the datum, because we need to update
> whole the tuple which contains inlined toasted chunks in this case.
> If we open the toasted varlena with read-only mode, inlined one does not
> prevent anything. It is an issue for only write operation.
> 
> I would like to add a new strategy on pg_type.typstorage with the following
> characteristics:
>  1. It always stores the given varlena data without any compression.
> So, the given data is stored as a set of fixed-length chunks.
>  2. It always stores the given varlena data on external toast relation.
> 
> I suggest a new built-in type named BLOB which has an identical definition
> to BYTEA type, expect for its attstorage.
> 
> Next, a different version of lo_open() should be provided to accept
> BLOB type as follows:
> 
>   SELECT pictname, lo_open(pictdata, x'2'::int) FROM my_picture;
> 
> It will allocate a largeobject descriptor for the given BLOB data,
> and user can read and write using loread() and lowrite() interfaces.
> 
> issue:
>   In this case, should it hold the relation handler and locks on the
>   "my_picture" relation, not only its toast relation?
> issue:
>   Should the lo_open() with read-only mode be available on the existing
>   TEXT or BYTEA types? I could not find any reason to deny them.
> 
> Next, pg_largeobject system catalog can be redefined using the BLOB
> type as follows:
> 
>   CATALOG(pg_largeobject,2613)
>   {
>   Oid loowner;/* OID of the largeobject owner */
>   Oid lonsp;  /* OID of the largeobject namespace */
>   aclitem loacl[1];   /* access permissions */
>   bloblodata; /* contents of the largeobject */
>   } FormData_pg_largeobject;
> 
> The existing largeobject interfaces perform on pg_largeobject.lodata
> specified by largeobject identifier.
> Rest of metadata can be used for access control purpose.
> 
> Thanks,
> 
> KaiGai Kohei wrote:
>> Tom Lane wrote:
>>> Bernd Helmle  writes:
 It might be interesting to dig into your proposal deeper in conjunction 
 with TOAST (you've already mentioned this TODO). Having serial access with 
 a nice interface into TOAST would be eliminating the need for 
 pg_largeobject completely (i'm not a big fan of this one-big-system-table 
 approach the old LO interface currently is).
>>> Yeah, it would be more useful probably to fix that than to add
>>> decoration to the LO facility.  Making LO more usable is just going to
>>> encourage people to bump into its other limitations (32-bit OIDs,
>>> 32-bit object size, finite maximum size of pg_largeobject, lack of
>>> dead-object cleanup, etc etc).
>> The reason why I tried to mention the named largeobject feature is
>> that dac security checks on largeobject require them to belong to
>> a certain schema, so I thought it is quite natural to have a string
>> name. However, obviously, it is not a significant theme for me.
>>
>> I can also agree your opinion that largeobject interfaces should be
>> redefined to access partial stuff of TOAST'ed verlena data structure,
>> not only pg_largeobject.
>>
>> In this case, we will need a new pg_type.typstorage option which
>> force to put the given verlena data on external relation without
>> compression, because we cannot estimate the data offset in inlined
>> or compressed external verlena data.
>>
>> I'll try to submit a design within a few days.
>> Thanks,
> 
> 


-- 
OSS Platform Development Division, NEC
KaiGai Kohei 

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] pg_migrator versus inherited columns

[Greg Stark]

On Wed, Jul 1, 2009 at 11:36 PM, Tom Lane wrote:
> (It's a good thing we added ADD INHERIT in 8.4, or we'd be completely
> up the creek here.)  In this way we can ensure that the physical order
> of columns really is what it needs to be in the child table.  Dropped
> columns can then be managed in the same way as the current code does,
> but it'll actually work.  (We have to drop them before doing the
> ADD INHERIT of course.)
>
> Comments?

Uhm, we've had ADD INHERIT since 8.2 -- that was my first patch.

This will result in all the columns being marked attislocal. Ie, if
they're dropped from the parent they won't be dropped automatically
from the children any longer.

Frankly I never really liked attislocal -- it seems to me the user
knows when he's dropping the column whether he wants it dropped from
the children and should be able to explicitly request it to cascade or
not. I can't imagine many use cases where you want it to cascade to
some children but not others based on how they were originally
created.

-- 
greg
http://mit.edu/~gsstark/resume.pdf

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] First CommitFest: July 15th

[Josh Berkus]

Folks,

There's been a lot of discussion/argument around how to handle the last 
commitfest, but there seems to be a total consensus that we want to have 
the first CF on July 15th.


I'd like Robert Haas to be the CF Manager for that commitfest if he's 
available.  I can help by running RRR or something.


Robert, I have not reviewed your software.  Do I need a login or something?

--
Josh Berkus
PostgreSQL Experts Inc.
www.pgexperts.com

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] pg_migrator versus inherited columns

[Tom Lane]

Greg Stark  writes:
> On Wed, Jul 1, 2009 at 11:36 PM, Tom Lane wrote:
>> Comments?

> Uhm, we've had ADD INHERIT since 8.2 -- that was my first patch.

Hmm, 8.3 doesn't seem to recognize the syntax:

regression=# alter table c add inherit p;
ERROR:  type "p" does not exist
LINE 1: alter table c add inherit p;
  ^

> This will result in all the columns being marked attislocal. Ie, if
> they're dropped from the parent they won't be dropped automatically
> from the children any longer.

Good point.  We could have pg_dump fix that up, I suppose.  On the other
hand, I'm not entirely sure that the current dump methodology guarantees
to preserve attislocal correctly anyway.

> Frankly I never really liked attislocal -- it seems to me the user
> knows when he's dropping the column whether he wants it dropped from
> the children and should be able to explicitly request it to cascade or
> not.

The original discussions about attislocal/attinhcount came up with some
cases that seemed to make it necessary, but I've long forgotten the
details.

regards, tom lane

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] pg_migrator versus inherited columns

[Greg Stark]

On Thu, Jul 2, 2009 at 1:25 AM, Tom Lane wrote:
>
> Hmm, 8.3 doesn't seem to recognize the syntax:
>
> regression=# alter table c add inherit p;
> ERROR:  type "p" does not exist
> LINE 1: alter table c add inherit p;
>                                  ^

Oh I remember being caught by this myself. The above is trying to add
a new column named "inherit". The syntax to add an inheritance parent
is just "alter table c inherit p"


-- 
greg
http://mit.edu/~gsstark/resume.pdf

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] single bit integer (TINYINT) revisited for 8.5

[Greg Stark]

Incidentally there *is* a single-byte integer data type in Postgres,
it's called "char" (the quote marks are necessary in SQL due to the
char(n) data type).

It's a bit weird though, mainly because its output format is to output
ascii characters -- kind of like how C's single-byte integer data type
is mainly used to hold ascii characters...

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Query progress indication - an implementation

[Bruce Momjian]

Tom Lane wrote:
> Joshua Tolley  writes:
> > On Mon, Jun 29, 2009 at 02:07:23PM -0400, Tom Lane wrote:
> >> I think this is pretty much nonsense --- most queries run all their plan
> >> nodes concurrently to some extent.  You can't usefully say that a query
> >> is "on" some node, nor measure progress by whether some node is "done".
> 
> > What about showing the outermost node where work has started?
> 
> That's always the outermost node; what would it tell you?

[ Repost ]

I think the only resonable solution would be to consider the estimated
cost of each node and then compute what percentage complete each node
is.

-- 
  Bruce Momjian  http://momjian.us
  EnterpriseDB http://enterprisedb.com

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

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] gin--a rule for function parameter

[Fly.Li]

1 ginarrayextract() has 2 parameters
2 gin_extract_tsquery() has 3 parameters
3 run sql(from plsql/src/test/regress/sql/opr_sanity.sql), it expect no 
results:
-
SELECT p1.amopclaid, p1.amprocnum,
 p2.oid, p2.proname,
 p3.opcname,
 p4.amopclaid, p4.amprocnum,
 p5.oid, p5.proname,
 p6.opcname
FROM pg_amproc AS p1, pg_proc AS p2, pg_opclass AS p3,
 pg_amproc AS p4, pg_proc AS p5, pg_opclass AS p6
WHERE p1.amopclaid = p3.oid AND p4.amopclaid = p6.oid AND
p3.opcamid = p6.opcamid AND p1.amprocnum = p4.amprocnum AND
p1.amproc = p2.oid AND p4.amproc = p5.oid AND
(p2.proretset OR p5.proretset OR p2.pronargs != p5.pronargs);
--
We can get results as follow:
 amopclaid | amprocnum | oid  |   proname   | opcname  | 
amopclaid | amprocnum | oid  |   proname   | opcname
---+---+--+-+--+---+---+--+-+--
  2771 | 3 | 2743 | ginarrayextract | _oidvector_ops   | 
3659 | 3 | 3657 | gin_extract_tsquery | tsvector_ops
  2759 | 3 | 2743 | ginarrayextract | _cidr_ops| 
3659 | 3 | 3657 | gin_extract_tsquery | tsvector_ops
  2768 | 3 | 2743 | ginarrayextract | _name_ops| 
3659 | 3 | 3657 | gin_extract_tsquery | tsvector_ops
..
4 But, reading "plsql/src/test/regress/sql/opr_sanity.sql", there is a 
sentence said:
" We can check that all the referenced instances of the same support routine 
number take the same number of parameters" ?

5 So, ginarrayextract() and gin_extract_tsquery() should take the same 
number of parameters?
Or, " We can check that all the referenced instances of the same support 
routine number take the same number of parameters" is not a right?

6 Actually, pgsql allow all the referenced instances of the same support 
routine number do not take the same number of parameters.

Thanks.
Fly.Li



"Tom Lane"  дÈëÓʼþÐÂÎÅ:<10550.1246457...@sss.pgh.pa.us>...
> "Fly.Li"  writes:
> > version: PG8.2.2
> > MY Question:
> > Why must "take the same number of parameters" ?
>
> Because the GIN code will call it with a particular number of arguments.
>
> > When I use tsearch2, I found that gin_extract_tsquery() has 3 
> > parameters, it
> > break the rule "take the same number of parameters".
>
> 3 is the correct number of parameters for an extractQuery function
> (before 8.4 anyway), so I'm not clear what you are complaining about.
>
>regards, tom lane
>
> -- 
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
> 


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] 8.5 development schedule

[Robert Haas]

On Wed, Jul 1, 2009 at 6:55 PM, Bruce Momjian wrote:
> bruce wrote:
>> I realize there is the perception that the large patches that were
>> eventually rejected held up the release, but for all the patches I can
>> think of, they were not rejected immediately _because_ we had other
>> valid patches to work on.  Once all valid patches were applied, we were
>> quickly able to reject the large unready patches.
>>
>> So, rejecting the large patches early would not have significantly
>> moved the release date earlier.
>
> I see no one agrees with my analysis --- no matter;  if I unreservedly
> agreed with others, I wouldn't be here.  ;-)
>
> There has been discussion about how to be more hard-nosed about
> rejecting patches.  I think it has to start with us being more
> hard-nosed about giving patches feedback --- the very idea we had to
> create commit-fests reflects that we historically have not done an
> organized job of processing patches.

Agreed.

> If we review patches as soon as they appear, and give rapid feedback, we
> can easily reject patches that take more than a few days for the patch
> author to resolve, and there would be little slippage;  the same goes
> for dealing with known bugs.  I know it can be done, but I don't promise
> it would be pleasant.

Also agreed.  It's never pleasant to have a patch rejected/postponed,
but it's tolerable if you've gotten some feedback and understand the
reasons why.  Of course there is no guarantee that you will agree with
those reasons, but that's life.  Some day you may be the committer and
have your turn to irritate patch submitters.  :-)

...Robert

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] gin--a rule for function parameter

[Tom Lane]

"Fly.Li"  writes:
> 1 ginarrayextract() has 2 parameters
> 2 gin_extract_tsquery() has 3 parameters
> 3 run sql(from plsql/src/test/regress/sql/opr_sanity.sql), it expect no 
> results:

Well, actually what's cheating here is ginarrayextract, not tsearch2.
That was fixed as of 8.3.

regards, tom lane

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] 8.5 development schedule

[Tom Lane]

Bruce Momjian  writes:
> There has been discussion about how to be more hard-nosed about
> rejecting patches.  I think it has to start with us being more
> hard-nosed about giving patches feedback --- the very idea we had to
> create commit-fests reflects that we historically have not done an
> organized job of processing patches.

> If we review patches as soon as they appear, and give rapid feedback, we
> can easily reject patches that take more than a few days for the patch
> author to resolve, and there would be little slippage;  the same goes
> for dealing with known bugs.  I know it can be done, but I don't promise
> it would be pleasant.

In other words, you propose dropping the idea of commitfests, and
expecting committers to spend *all* their time reviewing?  Tain't
happening.

regards, tom lane

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] HEAD is open for 8.5 development

[Robert Haas]

On Wed, Jul 1, 2009 at 7:30 PM, Tom Lane wrote:
> Let the breakage begin ...
>
>                        regards, tom lane

Tom - and all other committers -

In order to avoid duplication of effort, we should avoid assigning
round-robin reviewers to any patches which the committers feel that
they already have adequately covered.  In order to do that, we need to
make sure we know which ones they are.  If you are taking a look at
any of the patches submitted for this CommitFest, please put your name
next to them on the wiki.  Please ALSO add a comment saying something
like "tgl says: I am reviewing this, no need to assign a round-robin
reviewer".

During the last CommitFest, we had occasional shenanigans where
someone would stick the name of a committer or other community member
next to a patch just because they had made some comments on it.  But
the person whose name got stuck there didn't necessarily know about it
or feel any responsibility to conduct a complete review.  So it would
be helpful if everyone could make sure to add a comment when claiming
patches.

Thanks,

...Robert

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] 8.5 development schedule

[Bruce Momjian]

Robert Haas wrote:
> > If we review patches as soon as they appear, and give rapid feedback, we
> > can easily reject patches that take more than a few days for the patch
> > author to resolve, and there would be little slippage; ?the same goes
> > for dealing with known bugs. ?I know it can be done, but I don't promise
> > it would be pleasant.
> 
> Also agreed.  It's never pleasant to have a patch rejected/postponed,
> but it's tolerable if you've gotten some feedback and understand the
> reasons why.  Of course there is no guarantee that you will agree with
> those reasons, but that's life.  Some day you may be the committer and
> have your turn to irritate patch submitters.  :-)

Our only limitation is our own sense that we have been fair to patch
authors, i.e. there is no external restriction on how we handle things.

-- 
  Bruce Momjian  http://momjian.us
  EnterpriseDB http://enterprisedb.com

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

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] 8.5 development schedule

[Bruce Momjian]

Tom Lane wrote:
> Bruce Momjian  writes:
> > There has been discussion about how to be more hard-nosed about
> > rejecting patches.  I think it has to start with us being more
> > hard-nosed about giving patches feedback --- the very idea we had to
> > create commit-fests reflects that we historically have not done an
> > organized job of processing patches.
> 
> > If we review patches as soon as they appear, and give rapid feedback, we
> > can easily reject patches that take more than a few days for the patch
> > author to resolve, and there would be little slippage;  the same goes
> > for dealing with known bugs.  I know it can be done, but I don't promise
> > it would be pleasant.
> 
> In other words, you propose dropping the idea of commitfests, and
> expecting committers to spend *all* their time reviewing?  Tain't
> happening.

"I don't promise it would be pleasant."

-- 
  Bruce Momjian  http://momjian.us
  EnterpriseDB http://enterprisedb.com

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

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] 8.5 development schedule

[Robert Haas]

On Wed, Jul 1, 2009 at 7:00 PM, Tom Lane wrote:
> Greg Stark  writes:
>> On Tue, Jun 30, 2009 at 5:11 PM, Tom Lane wrote:
>>> I'm also not prepared to push a large and unstable feature into the tree
>>> on the hope that it will get fixed.
>
>> I didn't have the impression it had any known problems, Simon and
>> others spent a lot of time testing it already.
>
> If it didn't have known problems it would have been committed in 8.4.

What I've seen of Heikki's work thus far has led me to believe that
his reasons for rejecting the patch were good ones, but I don't
specifically what they were.  It would be helpful, I think, to
reiterate them or repost links to the relevant messages in the
archives; it would also be great if we could get an estimate of how
close the patch is to being committable.  Does it still need massive
work, or is it getting fairly close, or what?  Are the issues code
cleanliness/maintainability, bugs, missing functionality?

>From our conversations at the PGcon development meeting it seems as
though there are a lot of people for whom this is a high-priority
feature.  Perhaps some of them will be willing to help if we give them
enough information to work with.

...Robert

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] 8.5 development schedule

[Tom Lane]

Bruce Momjian  writes:
> Tom Lane wrote:
>> Bruce Momjian  writes:
>>> If we review patches as soon as they appear, and give rapid feedback, we
>>> can easily reject patches that take more than a few days for the patch
>>> author to resolve, and there would be little slippage;  the same goes
>>> for dealing with known bugs.  I know it can be done, but I don't promise
>>> it would be pleasant.
>> 
>> In other words, you propose dropping the idea of commitfests, and
>> expecting committers to spend *all* their time reviewing?  Tain't
>> happening.

> "I don't promise it would be pleasant."

I'm not sure which part of "no" you didn't understand, but this
committer is not buying into that proposal.

regards, tom lane

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] 8.5 development schedule

[Bruce Momjian]

Tom Lane wrote:
> Bruce Momjian  writes:
> > Tom Lane wrote:
> >> Bruce Momjian  writes:
> >>> If we review patches as soon as they appear, and give rapid feedback, we
> >>> can easily reject patches that take more than a few days for the patch
> >>> author to resolve, and there would be little slippage;  the same goes
> >>> for dealing with known bugs.  I know it can be done, but I don't promise
> >>> it would be pleasant.
> >> 
> >> In other words, you propose dropping the idea of commitfests, and
> >> expecting committers to spend *all* their time reviewing?  Tain't
> >> happening.
> 
> > "I don't promise it would be pleasant."
> 
> I'm not sure which part of "no" you didn't understand, but this
> committer is not buying into that proposal.

Again, I am pointing out it could be done, but it would be unpleasant,
as you mentioned.  We can't move make progress unless we understand the
underlying causes of our delays.  I am not suggesting we adopt it for
reasons you mentioned.

-- 
  Bruce Momjian  http://momjian.us
  EnterpriseDB http://enterprisedb.com

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

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] First CommitFest: July 15th

[Robert Haas]

On Wed, Jul 1, 2009 at 8:21 PM, Josh Berkus wrote:
> There's been a lot of discussion/argument around how to handle the last
> commitfest, but there seems to be a total consensus that we want to have the
> first CF on July 15th.
>
> I'd like Robert Haas to be the CF Manager for that commitfest if he's
> available.  I can help by running RRR or something.

Sounds great.  How do we go about putting together a list of available
reviewers?  Should we create a wikitable to which people can add
themselves?

> Robert, I have not reviewed your software.  Do I need a login or something?

Just your community login @ http://coridan.postgresql.org/ - but if
you send me your community login name I'll give you admin privs, which
will allow you to create/modify/delete commitfests and delete comments
that you yourself did not create.

The main problem is that my fine software only contains test data at
this point.  If we have any volunteers who are available to migrate
the information from the Wiki to my app (which will involve a fair
amount of legwork), then I recommend that we accept their help as it
will make things easier for the CommitFest management team...  which I
am all in favor of, especially now that I'm on that team.  On the
other hand, if we don't have any volunteers, then I recommend that we
continue to use the Wiki for this CommitFest but make sure that all
patches for the next CommitFest, and any that follow, get added via
the app.

So, any volunteers?

Thanks,

...Robert

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] First CommitFest: July 15th

[Brendan Jurd]

2009/7/2 Robert Haas :
> The main problem is that my fine software only contains test data at
> this point.  If we have any volunteers who are available to migrate
> the information from the Wiki to my app (which will involve a fair
> amount of legwork),

As the original author of the CF wiki templates I feel like this
problem belongs to me.  One of my primary goals was getting some
structure into the commitfests so that we could in fact export them to
a database at some point in the future.  I'm glad that time has
finally come!

I imagine that "migration" would basically be converting the wiki data
into SQL, so I would need the database schema underlying the new CF
app.

Cheers,
BJ

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers