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 2-3
On 30/05/10 06:04, Fujii Masao wrote:
On Fri, May 28, 2010 at 11:12 AM, Fujii Masaomasao.fu...@gmail.com wrote:
On Thu, May 27, 2010 at 11:13 PM, Robert Haasrobertmh...@gmail.com wrote:
I guess this happens because the frequency of checkpoint on the standby is
too lower than that on the
Hi,
On Thu, May 27, 2010 at 7:21 AM, Heikki Linnakangas
hei...@postgresql.org 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
On Mon, May 31, 2010 at 6:37 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com 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
On Mon, May 31, 2010 at 7:03 PM, Fujii Masao masao.fu...@gmail.com wrote:
Hi,
On Thu, May 27, 2010 at 7:21 AM, Heikki Linnakangas
hei...@postgresql.org wrote:
Log Message:
---
In walsender, don't sleep if there's outstanding WAL waiting to be sent,
otherwise we effectively
On 31/05/10 13:20, Fujii Masao wrote:
On Mon, May 31, 2010 at 7:03 PM, Fujii Masaomasao.fu...@gmail.com 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
On Thu, May 13, 2010 at 8:39 PM, Simon Riggs sri...@postgresql.org 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
On Mon, 2010-05-31 at 20:11 +0900, Fujii Masao wrote:
On Thu, May 13, 2010 at 8:39 PM, Simon Riggs sri...@postgresql.org wrote:
Log Message:
---
Ensure that top level aborts call XLogSetAsyncCommit(). Not doing
so simply leads to data waiting in wal_buffers which then causes
On 31 May 2010 09:33, Simon Riggs si...@2ndquadrant.com 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
On Mon, 31 May 2010, Thom Brown wrote:
On 31 May 2010 09:33, Simon Riggs si...@2ndquadrant.com 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
On Mon, May 31, 2010 at 2:22 PM, Thom Brown thombr...@gmail.com wrote:
On 31 May 2010 09:33, Simon Riggs si...@2ndquadrant.com 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
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 are going
2010/5/31 Bruce Momjian br...@momjian.us:
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,
On Mon, 2010-05-31 at 15:14 +0100, Dave Page wrote:
On Mon, May 31, 2010 at 2:22 PM, Thom Brown thombr...@gmail.com wrote:
On 31 May 2010 09:33, Simon Riggs si...@2ndquadrant.com wrote:
We're currently at 4 weeks since last beta, with no new beta in sight.
My understanding was beta 2
Bruce Momjian br...@momjian.us 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
2010/5/31 Tom Lane t...@sss.pgh.pa.us:
Bruce Momjian br...@momjian.us 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
Marc G. Fournier scra...@hub.org writes:
On Mon, 31 May 2010, Thom Brown wrote:
On 31 May 2010 09:33, Simon Riggs si...@2ndquadrant.com 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?
Simon Riggs si...@2ndquadrant.com 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
Heikki Linnakangas heikki.linnakan...@enterprisedb.com 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
Tom Lane wrote:
Bruce Momjian br...@momjian.us 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
Bruce Momjian br...@momjian.us 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.
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
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
Tom Lane wrote:
Bruce Momjian br...@momjian.us 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
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 a
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
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 ...
Marc
Marc G. Fournier scra...@hub.org 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
On Mon, May 31, 2010 at 5:35 PM, Marc G. Fournier scra...@hub.org 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
On Mon, May 31, 2010 at 5:30 PM, Bruce Momjian br...@momjian.us 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
On Mon, May 31, 2010 at 3:59 PM, Tom Lane t...@sss.pgh.pa.us 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
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
On Mon, 31 May 2010, Tom Lane wrote:
Marc G. Fournier scra...@hub.org 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
Greg Stark wrote:
On Mon, May 31, 2010 at 3:59 PM, Tom Lane t...@sss.pgh.pa.us 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
Marc G. Fournier scra...@hub.org 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*
Greg Stark gsst...@mit.edu 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
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 entire
2010/5/31 Bruce Momjian br...@momjian.us:
Greg Stark wrote:
On Mon, May 31, 2010 at 3:59 PM, Tom Lane t...@sss.pgh.pa.us 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
Tom Lane wrote:
Bruce Momjian br...@momjian.us 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.
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 the wild?
2010/5/31 Bruce Momjian br...@momjian.us:
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
Pavel Stehule wrote:
2010/5/31 Bruce Momjian br...@momjian.us:
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
On Mon, 2010-05-31 at 11:10 -0400, Tom Lane wrote:
Simon Riggs si...@2ndquadrant.com 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,
2010/5/31 Bruce Momjian br...@momjian.us:
Pavel Stehule wrote:
2010/5/31 Bruce Momjian br...@momjian.us:
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
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 as
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
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 seriously confused,
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 function is a
Tom Lane wrote:
Ian Barwick barw...@gmail.com writes:
Apologies, slight cp 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)
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
Jesper Krogh jes...@krogh.cc 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
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 second
Excerpts from Takahiro Itagaki's message of mié may 26 03:32:56 -0400 2010:
Alvaro Herrera alvhe...@commandprompt.com 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
Robert Haas wrote:
On Sat, May 8, 2010 at 10:40 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Bruce Momjian br...@momjian.us 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
Alvaro Herrera alvhe...@commandprompt.com 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
Pavel Stehule pavel.steh...@gmail.com 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
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
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
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
Tom Lane wrote:
Robert Haas robertmh...@gmail.com 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?
Jesper Krogh jes...@krogh.cc 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
Bruce Momjian br...@momjian.us writes:
Tom Lane wrote:
Robert Haas robertmh...@gmail.com 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
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 reassigning
On 2010-05-31 22:09, Tom Lane wrote:
Jesper Kroghjes...@krogh.cc 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
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:
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
David E. Wheeler da...@kineticode.com 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
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
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 br...@momjian.ushttp://momjian.us
Tom Lane t...@sss.pgh.pa.us wrote:
Alvaro Herrera alvhe...@commandprompt.com 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
On Fri, Apr 9, 2010 at 2:16 PM, Magnus Hagander mag...@hagander.net 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
On Jun 1, 2010, at 0:23 , Tom Lane wrote:
David E. Wheeler da...@kineticode.com 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
On Mon, May 31, 2010 at 9:24 PM, Florian Pflug f...@phlo.org wrote:
On Jun 1, 2010, at 0:23 , Tom Lane wrote:
David E. Wheeler da...@kineticode.com 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
Takahiro Itagaki itagaki.takah...@oss.ntt.co.jp 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
Greg Stark gsst...@mit.edu 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
Giles Lean wrote:
Greg Stark gsst...@mit.edu 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 */
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
David E. Wheeler da...@kineticode.com 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
Tom Lane wrote:
David E. Wheeler da...@kineticode.com 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.
On Mon, May 31, 2010 at 11:36 PM, Tom Lane t...@sss.pgh.pa.us wrote:
David E. Wheeler da...@kineticode.com 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
Bruce Momjian br...@momjian.us 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
Bruce Momjian br...@momjian.us 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
2010/6/1 Tom Lane t...@sss.pgh.pa.us:
David E. Wheeler da...@kineticode.com 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
On 2010-05-31 20:38, Tom Lane wrote:
Jesper Kroghjes...@krogh.cc 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.
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:
85 matches
Mail list logo
