Takahiro Itagaki wrote:
The proposal by Joe Conway is adding a new contib module.
http://archives.postgresql.org/message-id/4b959d7a.6010...@joeconway.com
http://github.com/jconway/pg_controldata
There's a second one of these floating around now too:
http://labs.omniti.com/trac/pgtreats/br
On 2010-05-31 20:38, Tom Lane wrote:
Jesper Krogh writes:
Just a small follow up. I tried out the patch (or actually a fresh git
checkout) and it now gives very accurate results for both upper and
lower end of the MCE-histogram with a lower cutoff that doesn't
approach 2.
Good. How
2010/6/1 Tom Lane :
> "David E. Wheeler" writes:
>> On May 31, 2010, at 7:40 PM, Robert Haas wrote:
>>> I was going to propose ==> across the board.
>
>> What about -> ?
>
> hstore already uses that for something else.
>
> Robert's idea isn't a bad one if we're forced to rename the operator.
> I'd
Bruce Momjian wrote:
> is_relative_to_cwd()?
../../../../some/other/place/not/under/cwd
Names are hard, but if I understood the original post, the
revised function is intended to check that the directory is
below the current working directory.
If my understanding is wrong (always possible!) a
Bruce Momjian writes:
> Tom Lane wrote:
>> I'd still like to know exactly how hard the concrete has set on the
>> SQL spec draft, first. (Peter?)
> I don't know, but based on the fact it matches Oracle, I think it is
> pretty well set by now.
Eh? The SQL committee has a very long track record
On Mon, May 31, 2010 at 11:36 PM, Tom Lane wrote:
> "David E. Wheeler" writes:
>> On May 31, 2010, at 7:40 PM, Robert Haas wrote:
>>> I was going to propose ==> across the board.
>
>> What about -> ?
>
> hstore already uses that for something else.
>
> Robert's idea isn't a bad one if we're force
Tom Lane wrote:
> "David E. Wheeler" writes:
> > On May 31, 2010, at 7:40 PM, Robert Haas wrote:
> >> I was going to propose ==> across the board.
>
> > What about -> ?
>
> hstore already uses that for something else.
>
> Robert's idea isn't a bad one if we're forced to rename the operator.
> I
"David E. Wheeler" writes:
> On May 31, 2010, at 7:40 PM, Robert Haas wrote:
>> I was going to propose ==> across the board.
> What about -> ?
hstore already uses that for something else.
Robert's idea isn't a bad one if we're forced to rename the operator.
I'd still like to know exactly how ha
On May 31, 2010, at 7:40 PM, Robert Haas wrote:
> I was going to propose ==> across the board.
What about -> ?
D
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Giles Lean wrote:
>
> Greg Stark wrote:
>
> > /* NOTE: these two functions aren't complementary under windows,
> > * be sure to use the right one */
> >
> > /* Check path always means the same thing regardless of cwd */
> > is_absolute_path()
> > /* Check that path is under cwd */
> > is_relat
Greg Stark wrote:
> /* NOTE: these two functions aren't complementary under windows,
> * be sure to use the right one */
>
> /* Check path always means the same thing regardless of cwd */
> is_absolute_path()
> /* Check that path is under cwd */
> is_relative_path()
Um ... isn't that second f
"Takahiro Itagaki" wrote:
> Bug reference: 5487
> Logged by: Takahiro Itagaki
> Email address: itagaki.takah...@oss.ntt.co.jp
> Description:dblink failed with 63 bytes connection names
> Details:
>
> Contib/dblink module seems to have a bug in handling
> connection n
On Mon, May 31, 2010 at 9:24 PM, Florian Pflug wrote:
> On Jun 1, 2010, at 0:23 , Tom Lane wrote:
>> "David E. Wheeler" writes:
>>> On May 31, 2010, at 8:56 AM, Andrew Dunstan wrote:
I don't have strong feelings about the timing - I'd be very surprised if
:= were to be used in this con
On Jun 1, 2010, at 0:23 , Tom Lane wrote:
> "David E. Wheeler" writes:
>> On May 31, 2010, at 8:56 AM, Andrew Dunstan wrote:
>>> I don't have strong feelings about the timing - I'd be very surprised if :=
>>> were to be used in this context for any other purpose, so I don't think
>>> we'd be bit
On Fri, Apr 9, 2010 at 2:16 PM, Magnus Hagander wrote:
>> I'm inclined to propose adding an additional path test operator, along
>> the lines of "has_drive_specifier(path)" (always false on non-Windows),
>> and use that where needed to reject relative-with-drive-letter paths.
>
> I think I agree w
Tom Lane wrote:
> Alvaro Herrera writes:
> > Do we really need default_only entries in user-defined reloptions?
I think we don't, but I also think we don't need it at all even in the
core because it just set a few variables to the default values with
complex code flow. Could you explain why de
Greg Sabino Mullane wrote:
-- Start of PGP signed section.
> Patch attached to show the schema *and* table name when doing
> a REINDEX DATABASE.
Yea, VACUUM VERBOSE shows the schema name, so REINDEX should as well.
Patch applied.
--
Bruce Momjian http://momjian.us
EnterpriseDB
Magnus Hagander wrote:
> Here's a thread that incorrectly started on the security list, but really is
> more about functionality. Looking for comments:
I looked into this and it seems to be a serious issue.
> The function is_absolute_path() is incorrect on Windows. As it's implemented,
> it consi
"David E. Wheeler" writes:
> On May 31, 2010, at 8:56 AM, Andrew Dunstan wrote:
>> I don't have strong feelings about the timing - I'd be very surprised if :=
>> were to be used in this context for any other purpose, so I don't think we'd
>> be biting ourselves too much by just using that now. B
On May 31, 2010, at 8:56 AM, Andrew Dunstan wrote:
> I don't have strong feelings about the timing - I'd be very surprised if :=
> were to be used in this context for any other purpose, so I don't think we'd
> be biting ourselves too much by just using that now. But if we do that, we
> should d
On May 30, 2010, at 6:53 AM, Kevin Grittner wrote:
> You would then generate a diff in context format and post to the
> -hackers list with that file as an attachment.
Here it is:
dividing-money.diff
Description: Binary data
> Don't forget to add
> it to the "CommitFest" page:
>
> https://comm
On 2010-05-31 22:09, Tom Lane wrote:
Jesper Krogh writes:
Conceptually searching for the "full dataset" would always be fastest
solved by a seq-scan. The query planner enforces this so much, so not
even "enable_seqscan=off" can convince it to to something else.
...
Would it be possible to i
I wrote:
> In particular, now that there's a distinction between smgr flush
> and relcache flush, maybe we could associate targblock reset with
> smgr flush (only) and arrange to not flush the smgr level during
> ANALYZE --- basically, smgr flush would only be needed when truncating
> or reassignin
Bruce Momjian writes:
> Tom Lane wrote:
>> Robert Haas writes:
>>> Given "Relation rel", it looks to me like rel->rd_rel->relistemp will
>>> always give the same answer as rel->rd_istemp. So why have both?
>>
>> Might be historical --- relistemp is pretty new.
> Is this a TODO or something we
Jesper Krogh writes:
> Conceptually searching for the "full dataset" would always be fastest
> solved by a seq-scan. The query planner enforces this so much, so not
> even "enable_seqscan=off" can convince it to to something else.
> ...
> Would it be possible to implement the "Filtering" using the
Tom Lane wrote:
> Robert Haas writes:
> > Given "Relation rel", it looks to me like rel->rd_rel->relistemp will
> > always give the same answer as rel->rd_istemp. So why have both?
>
> Might be historical --- relistemp is pretty new.
Is this a TODO or something we want to clean up?
--
Bruce
Jaime Casanova wrote:
> Hi,
>
> while TFM says that we can use EXECUTE 'select ' INTO instead of the
> non implemented EXECUTE 'select ... into ', the message in plpgsql
> fails to say the same thing... seems like a HINT to me
Applied with attached patch. Thanks.
--
Bruce Momjian ht
I have added this to the next commit-fest:
https://commitfest.postgresql.org/action/commitfest_view?id=6
---
Marko Tiikkaja wrote:
> Hi,
>
> This came up on IRC today and I recall several instances of this during
Hi.
The test data a set of generated terms using this perl-script
http://shrek.krogh.cc/~jesper/build-test.pl
and http://shrek.krogh.cc/~jesper/words.txt
I have generated a test dataset with an average tsvector length of
around 250 and 200.000 tuples in the dataset.
Conceptually searching for t
Pavel Stehule writes:
> it's not important in this discussion. Important is using some usual
> symbol '=' or special symbol '=>'. Our syntax is probably only one
> possible solution in this moment (there are minimum controversy), bud
> semantic isn't best. Using same operator as assign statement u
Alvaro Herrera writes:
> Excerpts from Takahiro Itagaki's message of mié may 26 03:32:56 -0400 2010:
>> The new "default_only" field can be initialized only from the internal codes
>> and is not exported to user definded reloptions. We could add an additional
>> argument to add_xxx_reloption() fu
Robert Haas wrote:
> On Sat, May 8, 2010 at 10:40 PM, Tom Lane wrote:
> > Bruce Momjian writes:
> >> Uh, did we decide that 'wal_keep_segments' was the best name for this
> >> GUC setting? ?I know we shipped beta1 using that name.
> >
> > I thought min_wal_segments was a reasonable proposal, but
Excerpts from Takahiro Itagaki's message of mié may 26 03:32:56 -0400 2010:
>
> Alvaro Herrera wrote:
>
> > Excerpts from Tom Lane's message of vie may 14 15:03:57 -0400 2010:
> >
> > > Maybe a better solution is to have some kind of notion of a default-only
> > > entry, which is sufficient to
Uh, we have three days before we package 9.0beta2. It would be good if
we could decide on the max_standby_delay issue soon.
---
Simon Riggs wrote:
> On Wed, 2010-05-26 at 16:22 -0700, Josh Berkus wrote:
> > > Just this seco
Jesper Krogh writes:
> Just a small follow up. I tried out the patch (or actually a fresh git
> checkout) and it now gives very accurate results for both upper and
> lower end of the MCE-histogram with a lower cutoff that doesn't
> approach 2.
Good. How much did the ANALYZE time change for your
On 2010-05-30 20:02, Jan Urbański wrote:
Here's a patch against recent git, but should apply to 8.4 sources as
well. It would be interesting to measure the memory and time needed to
analyse the table after applying it, because we will be now using a lot
bigger bucket size and I haven't done any p
Tom Lane wrote:
> Ian Barwick writes:
> > Apologies, slight c&p error; correct version of query:
>
> > SELECT ov.object_id
> >FROM object_version ov
> > WHERE ov.object_id = 1
> > AND ov.version =0
> > AND ov.object_status_id = (
> > SELECT MAX(ov1.object_status_id)
> > FR
Mike Fowler wrote:
> Robert Haas wrote:
> > Please email your patch to the list (replying to this email is fine)
> > and add it here:
> > https://commitfest.postgresql.org/action/commitfest_view/open
> >
> Here's my patch, developed against HEAD, that adds the function
> 'xpath_exists'. The fun
Andrew Dunstan wrote:
>
>
> Bruce Momjian wrote:
> > MSSQL? Are you sure? This is the example posted in this thread:
> >
> > EXEC dbo.GetItemPrice @ItemCode = 'GXKP', @PriceLevel = 5
> >
> > and it more matches our := syntax than => in its argument ordering.
> >
>
> I think you are seri
Bruce Momjian wrote:
MSSQL? Are you sure? This is the example posted in this thread:
EXEC dbo.GetItemPrice @ItemCode = 'GXKP', @PriceLevel = 5
and it more matches our := syntax than => in its argument ordering.
I think you are seriously confused, or else you are seriously confu
On Mon, 2010-05-31 at 11:30 -0400, Bruce Momjian wrote:
> Well, they can just grab nightly snapshots and test, right? I don't
> think a beta is fundamentally different from a nightly snapshot,
> source-code wise.
There is only one difference: the signal to re-test.
Most people read "new beta" a
2010/5/31 Bruce Momjian :
> Pavel Stehule wrote:
>> 2010/5/31 Bruce Momjian :
>> > Pavel Stehule wrote:
>> >> >> Part of the earlier discussion was about how => was a tempting
>> >> >> operator name and other users may well have chosen it precisely
>> >> >> because it's so evocative. But we don't a
On Mon, 2010-05-31 at 11:10 -0400, Tom Lane wrote:
> Simon Riggs writes:
> > We're currently at 4 weeks since last beta, with no new beta in sight.
>
> Eh?
> http://archives.postgresql.org/pgsql-hackers/2010-05/msg01649.php
> You can hardly claim to have not seen it.
Yes, completely wrong. A sun
Pavel Stehule wrote:
> 2010/5/31 Bruce Momjian :
> > Pavel Stehule wrote:
> >> >> Part of the earlier discussion was about how => was a tempting
> >> >> operator name and other users may well have chosen it precisely
> >> >> because it's so evocative. But we don't actually have any evidence of
> >>
2010/5/31 Bruce Momjian :
> Pavel Stehule wrote:
>> >> Part of the earlier discussion was about how => was a tempting
>> >> operator name and other users may well have chosen it precisely
>> >> because it's so evocative. But we don't actually have any evidence of
>> >> that. Does anyone have any ex
Pavel Stehule wrote:
> >> Part of the earlier discussion was about how => was a tempting
> >> operator name and other users may well have chosen it precisely
> >> because it's so evocative. But we don't actually have any evidence of
> >> that. Does anyone have any experience seeing => operators in
Tom Lane wrote:
Bruce Momjian writes:
Yes, but if we are going to have to honor "=>" eventually, shouldn't we
just do it now? Supporting := and => seems confusing.
Personally, I haven't accepted the "if" part of that, therefore I
feel no need to argue over the "then".
2010/5/31 Bruce Momjian :
> Greg Stark wrote:
>> On Mon, May 31, 2010 at 3:59 PM, Tom Lane wrote:
>> > Not breaking hstore, as well as any third-party modules that might be
>> > using that operator name. ?Did you not absorb any of the discussion
>> > so far?
>> >
>>
>> In fairness most of the disc
Josh Berkus wrote:
> All,
>
> Updated docs based on tracking this discussion. fsync through full page
> writes recorded below.
I have applied this doc update with the attached patch.
I added the change from "every night" to "frequently", and reworded it
slightly so it was clear it affects the e
Greg Stark writes:
> If => is sql standard syntax then perhaps that changes the calculus.
Well, it *isn't* standard, yet at least. All we have is a report of the
current wording of a draft that's at least a year from release.
regards, tom lane
--
Sent via pgsql-hackers
"Marc G. Fournier" writes:
> On Mon, 31 May 2010, Tom Lane wrote:
>> I find myself entirely unimpressed by proposals to make releases
>> according to some rigid schedule that takes no account of whether
>> packaging manpower is actually available.
> How many beta testers out there *rely* on a p
Greg Stark wrote:
> On Mon, May 31, 2010 at 3:59 PM, Tom Lane wrote:
> > Not breaking hstore, as well as any third-party modules that might be
> > using that operator name. ?Did you not absorb any of the discussion
> > so far?
> >
>
> In fairness most of the discussion about breaking hstore was p
On Mon, 31 May 2010, Tom Lane wrote:
"Marc G. Fournier" writes:
On Mon, 31 May 2010, Bruce Momjian wrote:
Well, they can just grab nightly snapshots and test, right? I don't
think a beta is fundamentally different from a nightly snapshot,
source-code wise.
doesn't really give a good refer
Hi Shrish,
I saw the excel that you sent to Heikki. Here are my comments.
1. Don't worry about comparing the results with Oracle. Just take pg-normal and
pg-enhanced. That's what the community cares about. Later we can also add
Oracle's performance.
2. In the excel sheet you have 'simple querie
On Mon, May 31, 2010 at 3:59 PM, Tom Lane wrote:
> Not breaking hstore, as well as any third-party modules that might be
> using that operator name. Did you not absorb any of the discussion
> so far?
>
In fairness most of the discussion about breaking hstore was prior to
our learning that the sq
On Mon, May 31, 2010 at 5:30 PM, Bruce Momjian wrote:
> Marc G. Fournier wrote:
>> On Mon, 31 May 2010, Tom Lane wrote:
>>
>> > I find myself entirely unimpressed by proposals to make releases
>> > according to some rigid schedule that takes no account of whether
>> > packaging manpower is actuall
On Mon, May 31, 2010 at 5:35 PM, Marc G. Fournier wrote:
> On Mon, 31 May 2010, Magnus Hagander wrote:
>
>> My guess would be "most of them".
>
> Do we not have any stats on # of beta downloads per package type? I use
> FreeBSD ports when installing production, but when testing non-released code
"Marc G. Fournier" writes:
> On Mon, 31 May 2010, Bruce Momjian wrote:
>> Well, they can just grab nightly snapshots and test, right? I don't
>> think a beta is fundamentally different from a nightly snapshot,
>> source-code wise.
> doesn't really give a good reference point for testing purposes
On Mon, 31 May 2010, Magnus Hagander wrote:
My guess would be "most of them".
Do we not have any stats on # of beta downloads per package type? I use
FreeBSD ports when installing production, but when testing non-released
code, I generally use the source code itself and build ...
Mar
On Mon, 31 May 2010, Bruce Momjian wrote:
Marc G. Fournier wrote:
On Mon, 31 May 2010, Tom Lane wrote:
I find myself entirely unimpressed by proposals to make releases
according to some rigid schedule that takes no account of whether
packaging manpower is actually available.
How many beta t
Marc G. Fournier wrote:
> On Mon, 31 May 2010, Tom Lane wrote:
>
> > I find myself entirely unimpressed by proposals to make releases
> > according to some rigid schedule that takes no account of whether
> > packaging manpower is actually available.
>
> How many beta testers out there *rely* on
Tom Lane wrote:
> Bruce Momjian writes:
> > Yes, but if we are going to have to honor "=>" eventually, shouldn't we
> > just do it now? Supporting := and => seems confusing.
>
> Personally, I haven't accepted the "if" part of that, therefore I
> feel no need to argue over the "then".
Right, I a
On Mon, 31 May 2010, Tom Lane wrote:
I find myself entirely unimpressed by proposals to make releases
according to some rigid schedule that takes no account of whether
packaging manpower is actually available.
How many beta testers out there *rely* on a package to do their testing?
I'm not s
Hi Heikki, Pgsql-Hackers,
Sometime back you have started with "Separate Heap Fetch from Index Scan" which
was planned to support partial index only scans. Are you still working on it or
do you know someone still working on it?
We did some development with Gokul's Index Only Patch and have got g
Bruce Momjian writes:
> Yes, but if we are going to have to honor "=>" eventually, shouldn't we
> just do it now? Supporting := and => seems confusing.
Personally, I haven't accepted the "if" part of that, therefore I
feel no need to argue over the "then".
regards, tom l
Tom Lane wrote:
> Bruce Momjian writes:
> > Tom Lane wrote:
> >> So as far as I can tell, no one is opposed to replacing "expr AS name"
> >> with "name := expr" in the named-parameter syntax. Obviously we had
> >> better get this done before beta2. Is anyone actually working on the
> >> code/doc
Heikki Linnakangas writes:
> The central question is whether checkpoint_segments should trigger
> restartpoints or not. When PITR and restartpoints were introduced, the
> answer was "no", on the grounds that when you're doing recovery you're
> presumably replaying the logs much faster than they
Simon Riggs writes:
> We're currently at 4 weeks since last beta, with no new beta in sight.
Eh?
http://archives.postgresql.org/pgsql-hackers/2010-05/msg01649.php
You can hardly claim to have not seen it.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-h
"Marc G. Fournier" writes:
> On Mon, 31 May 2010, Thom Brown wrote:
>> On 31 May 2010 09:33, Simon Riggs wrote:
>>> We're currently at 4 weeks since last beta, with no new beta in sight.
>>
>> My understanding was beta 2 would be out on 7th June. Is that changing?
> Yes, but Simon is correct i
2010/5/31 Tom Lane :
> Bruce Momjian writes:
>> Tom Lane wrote:
>>> So as far as I can tell, no one is opposed to replacing "expr AS name"
>>> with "name := expr" in the named-parameter syntax. Obviously we had
>>> better get this done before beta2. Is anyone actually working on the
>>> code/doc
Bruce Momjian writes:
> Tom Lane wrote:
>> So as far as I can tell, no one is opposed to replacing "expr AS name"
>> with "name := expr" in the named-parameter syntax. Obviously we had
>> better get this done before beta2. Is anyone actually working on the
>> code/docs changes? If not, I'll pic
On Mon, 2010-05-31 at 15:14 +0100, Dave Page wrote:
> On Mon, May 31, 2010 at 2:22 PM, Thom Brown wrote:
> > On 31 May 2010 09:33, Simon Riggs wrote:
> >>
> >> We're currently at 4 weeks since last beta, with no new beta in sight.
> >
> > My understanding was beta 2 would be out on 7th June. Is
2010/5/31 Bruce Momjian :
> Tom Lane wrote:
>> So as far as I can tell, no one is opposed to replacing "expr AS name"
>> with "name := expr" in the named-parameter syntax. Obviously we had
>> better get this done before beta2. Is anyone actually working on the
>> code/docs changes? If not, I'll
Tom Lane wrote:
> So as far as I can tell, no one is opposed to replacing "expr AS name"
> with "name := expr" in the named-parameter syntax. Obviously we had
> better get this done before beta2. Is anyone actually working on the
> code/docs changes? If not, I'll pick it up.
If we eventually ar
On Mon, May 31, 2010 at 2:22 PM, Thom Brown wrote:
> On 31 May 2010 09:33, Simon Riggs wrote:
>>
>> We're currently at 4 weeks since last beta, with no new beta in sight.
>
> My understanding was beta 2 would be out on 7th June. Is that changing?
No. It's very much in sight on my calendar :-)
On Mon, 31 May 2010, Thom Brown wrote:
On 31 May 2010 09:33, Simon Riggs wrote:
We're currently at 4 weeks since last beta, with no new beta in sight.
My understanding was beta 2 would be out on 7th June. Is that changing?
Yes, but Simon is correct in that 4-5 weeks between betas is a lo
On 31 May 2010 09:33, Simon Riggs wrote:
>
> We're currently at 4 weeks since last beta, with no new beta in sight.
My understanding was beta 2 would be out on 7th June. Is that changing?
Thom
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscr
On Mon, 2010-05-31 at 20:11 +0900, Fujii Masao wrote:
> On Thu, May 13, 2010 at 8:39 PM, Simon Riggs wrote:
> > Log Message:
> > ---
> > Ensure that top level aborts call XLogSetAsyncCommit(). Not doing
> > so simply leads to data waiting in wal_buffers which then causes
> > later commits
On Thu, May 13, 2010 at 8:39 PM, Simon Riggs wrote:
> Log Message:
> ---
> Ensure that top level aborts call XLogSetAsyncCommit(). Not doing
> so simply leads to data waiting in wal_buffers which then causes
> later commits to potentially do emergency writes and for all forms
> of replicat
On 31/05/10 13:20, Fujii Masao wrote:
On Mon, May 31, 2010 at 7:03 PM, Fujii Masao wrote:
This commit seems to have introduced the bug that walsender exits
before sending all the WAL up to shutdown checkpoint record when
smart shutdown is requested.
The attached patch fixes the bug and a tiny
On Mon, May 31, 2010 at 7:03 PM, Fujii Masao wrote:
> Hi,
>
> On Thu, May 27, 2010 at 7:21 AM, Heikki Linnakangas
> wrote:
>> Log Message:
>> ---
>> In walsender, don't sleep if there's outstanding WAL waiting to be sent,
>> otherwise we effectively rate-limit the streaming as pointed out
On Mon, May 31, 2010 at 6:37 PM, Heikki Linnakangas
wrote:
> The central question is whether checkpoint_segments should trigger
> restartpoints or not. When PITR and restartpoints were introduced, the
> answer was "no", on the grounds that when you're doing recovery you're
> presumably replaying t
Hi,
On Thu, May 27, 2010 at 7:21 AM, Heikki Linnakangas
wrote:
> Log Message:
> ---
> In walsender, don't sleep if there's outstanding WAL waiting to be sent,
> otherwise we effectively rate-limit the streaming as pointed out by
> Simon Riggs. Also, send the WAL in smaller chunks, to resp
On 30/05/10 06:04, Fujii Masao wrote:
On Fri, May 28, 2010 at 11:12 AM, Fujii Masao wrote:
On Thu, May 27, 2010 at 11:13 PM, Robert Haas wrote:
I guess this happens because the frequency of checkpoint on the standby is
too lower than that on the master. In the master, checkpoint occurs for ev
On Sat, 2010-05-29 at 16:19 -0400, Bruce Momjian wrote:
> Assuming we want a release Postgres 9.0 by mid-August, here is how the
> timetable would look:
>
> Need RC release to be stable for 1-2 weeks before final
> RC must be released by August 1
> Beta must be stable for
85 matches
Mail list logo
