Jim C. Nasby wrote:
On Wed, May 16, 2007 at 07:48:10PM +0200, Magnus Hagander wrote:
Dave Page wrote:
I the current URLs represent the month, and the ID of the message as
it comes out of the mbox I believe. We could probably write a script
to dump a list of message IDs, directories and mbox
Marc G. Fournier wrote:
--On Wednesday, May 16, 2007 20:09:44 -0400 Bruce Momjian [EMAIL PROTECTED]
wrote:
I think one of the things that is preventing urgency is that everyone
knows we have large patches unapplied, so they know that their lack of
activity is not holding up the
On Wed, May 16, 2007 at 11:50:26PM -0400, Greg Smith wrote:
On Tue, 15 May 2007, Jim C. Nasby wrote:
Speaking of reviewers... should we put some thought into how we can
increase the number of people who can review code? It seems that's one
of our biggest bottlenecks...
Having recently
Magnus Hagander wrote:
Right. Grabbing the msgid alone from them shouldn't be too hard though.
It's included in the meta-headers mhonarc sticks in each file, so it
should be a simple regex to find it.
Should be easier than that - when we import the existing messages from
the mbox files we
I want to help the reviewing work of ctid chain following enhancement .
I've been studying the souce code which related with that part recently.
:-)
2007/5/17, Dave Page [EMAIL PROTECTED]:
I think we just have to accept that we're gonna have a long feature
freeze period, and ask people to help
Cui Shijun wrote:
I want to help the reviewing work of ctid chain following enhancement .
I've been studying the souce code which related with that part recently.
:-)
Please go ahead :-)
Regards Dave
---(end of broadcast)---
TIP 3: Have you
Hi,
Tom Lane wrote:
Neil Conway [EMAIL PROTECTED] writes:
When planning queries with a large IN expression in the WHERE clause,
the planner transforms the IN list into a scalar array expression. In
clause_selectivity(), we estimate the selectivity of the ScalarArrayExpr
by calling
Hi,
Tom Lane wrote:
Neil Conway [EMAIL PROTECTED] writes:
When planning queries with a large IN expression in the WHERE clause,
the planner transforms the IN list into a scalar array expression. In
clause_selectivity(), we estimate the selectivity of the ScalarArrayExpr
by calling
On 5/17/07, Cui Shijun [EMAIL PROTECTED] wrote:
I want to help the reviewing work of ctid chain following enhancement .
I've been studying the souce code which related with that part recently.
:-)
Tom had objected to this patch on the grounds that it adds complexity
without any significant
David Fetter wrote:
My main difficulty was figuring out a workable way to build a local mirror
of the code (so I could get off-line diffs), keep it in sync with the
development tree, while branching out working areas to evaluate patches or
do new development in. A good example walkthrough
On Wednesday 16 May 2007 13:02, Robert Haas wrote:
I care. I want a professional easy to understand and easy to maintain
that doesn't cause potential conflict with future and past development
syntax.
snip
If people have strong opinions about the syntax, why
were they not ALL expressed
On Thursday 17 May 2007 08:16, Andrew Dunstan wrote:
David Fetter wrote:
My main difficulty was figuring out a workable way to build a local
mirror of the code (so I could get off-line diffs), keep it in sync with
the development tree, while branching out working areas to evaluate
patches
Atul Deopujari [EMAIL PROTECTED] writes:
Hi,
Tom Lane wrote:
That's the least of the problems. We really ought to convert such cases
into an IN (VALUES(...)) type of query, since often repeated indexscans
aren't the best implementation.
I thought of giving this a shot and while I was
On Thu, 17 May 2007, Andrew Dunstan wrote:
For this item at least the work has been done in showing how to set up a
local mirror using rsync instead of CVSup...although frankly it would be
better to import the information rather than just refer to the buildfarm
HOWTO.
The information in the
Pavan Deolasee wrote:
On 5/17/07, Cui Shijun [EMAIL PROTECTED] wrote:
I want to help the reviewing work of ctid chain following enhancement .
I've been studying the souce code which related with that part recently.
:-)
Tom had objected to this patch on the grounds that it adds
Alvaro Herrera wrote:
Bruce Momjian wrote:
This has been saved for the 8.4 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
Huh, no, this is a bug and should be fixed right away.
OK, moved to the 8.3 patch queue.
On Thu, 17 May 2007, Robert Treat wrote:
And really should probably be written up into FAQ section or a full on guide
for how do i get started hacking on postgresql?
To be clear here: while there are guides for new hackers out there, they
focus on the big picture. I walked from those with
I see...
I checked part of HOT patches(patch1), and found that it involves too
many things I am not currently familar with. Maybe I should change an
item to work. :-(
Since I only studied part of source codes about transaction
processing(lmgr/MVCC/xact but without xlog.c), I want to study
Group
Greg Smith wrote:
On Thu, 17 May 2007, Andrew Dunstan wrote:
For this item at least the work has been done in showing how to set
up a local mirror using rsync instead of CVSup...although frankly it
would be better to import the information rather than just refer to
the buildfarm HOWTO.
Hi Jeff,
On 5/16/07 4:56 PM, Jeff Davis [EMAIL PROTECTED] wrote:
The main benefit of a sync scan will be the ability to start the scan where
other scans have already filled the I/O cache with useful blocks. This will
require some knowledge of the size of the I/O cache by the syncscan logic,
Cui Shijun wrote:
I see...
I checked part of HOT patches(patch1), and found that it involves too
many things I am not currently familar with. Maybe I should change an
item to work. :-(
Yeah, that's one big patch..
Since I only studied part of source codes about transaction
On Tue, May 15, 2007 at 04:52:16PM -0400, Alvaro Herrera wrote:
This is what happens with the Linux kernel. They have hundreds of
developers getting their hands dirty during a previous period. Then
2.6.20 is released; the 2.6.21 merge window opens, and all sort of
patches are flooded in.
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
---
Bruce Momjian wrote:
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
Wait a minute. Would the mentioned patch be this
Andrew Sullivan wrote:
On Tue, May 15, 2007 at 04:52:16PM -0400, Alvaro Herrera wrote:
This is what happens with the Linux kernel. They have hundreds of
developers getting their hands dirty during a previous period. Then
2.6.20 is released; the 2.6.21 merge window opens, and all sort of
Bruce Momjian [EMAIL PROTECTED] writes:
Your patch has been added to the PostgreSQL unapplied patches list at:
Please take it off again.
Jeff Davis wrote:
This thread here became a TODO item:
http://archives.postgresql.org/pgsql-hackers/2006-11/msg01011.php
During that discussion a patch
We've had ecpg regression tests being doing by the buildfarm for a
while, but they are not enabled for MSVC. Also, buildfarm has never
supported doing MBCS regression tests. In both cases the regression
tests are driven by Unix shell scripts, and in the MBCS case at least,
the script would
Joshua D. Drake wrote:
Andrew Sullivan wrote:
On Tue, May 15, 2007 at 04:52:16PM -0400, Alvaro Herrera wrote:
This is what happens with the Linux kernel. They have hundreds of
developers getting their hands dirty during a previous period. Then
2.6.20 is released; the 2.6.21 merge window
Andrew Dunstan wrote:
We've had ecpg regression tests being doing by the buildfarm for a
while, but they are not enabled for MSVC. Also, buildfarm has never
supported doing MBCS regression tests. In both cases the regression
tests are driven by Unix shell scripts, and in the MBCS case at
OK, emails moved to 8.4 queue.
---
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Your patch has been added to the PostgreSQL unapplied patches list at:
Please take it off again.
Jeff Davis wrote:
This
Dave Page wrote:
Andrew Dunstan wrote:
We've had ecpg regression tests being doing by the buildfarm for a
while, but they are not enabled for MSVC. Also, buildfarm has never
supported doing MBCS regression tests. In both cases the regression
tests are driven by Unix shell scripts, and in
Right now our roadmap lists the 8.3 release as July, 2007:
http://www.postgresql.org/developer/roadmap
While the year might be right, the month probably is not. I suggest we
remove the date and replace it with undetermined until we have a
clearer target date.
--
Bruce Momjian
Andrew Sullivan wrote:
On Tue, May 15, 2007 at 04:52:16PM -0400, Alvaro Herrera wrote:
This is what happens with the Linux kernel. They have hundreds of
developers getting their hands dirty during a previous period. Then
2.6.20 is released; the 2.6.21 merge window opens, and all sort of
Bruce Momjian wrote:
Right now our roadmap lists the 8.3 release as July, 2007:
http://www.postgresql.org/developer/roadmap
While the year might be right, the month probably is not. I suggest we
remove the date and replace it with undetermined until we have a
clearer target date.
I
Thank you for your suggestions, I am thinking about Full page writes
improvement. It seems not so complicated, just fit for a novice like
me.
I'll work on it. :-)
2007/5/17, Heikki Linnakangas [EMAIL PROTECTED]:
Cui Shijun wrote:
I see...
I checked part of HOT patches(patch1), and found
Andrew Dunstan [EMAIL PROTECTED] writes:
Back when we were thinking of supporting MSVC builds, we thought that
everything would need to be a C program, and so we rewrote the main
regression script in C, for example. However, now we have a build system
for MSVC we can see that its main
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Back when we were thinking of supporting MSVC builds, we thought that
everything would need to be a C program, and so we rewrote the main
regression script in C, for example. However, now we have a build system
for MSVC we can see
Andrew Dunstan [EMAIL PROTECTED] writes:
I don't think ECPG can use pg_regress as is, because it does more than
just run psql. We probably need to look at factoring out the common bits
into a shared lib. That's not a bad idea anyway.
A shared library is probably overkill (it has a lot more
Tom Lane wrote:
At this point it seems nothing will be done about this issue for 8.3.
* [PATCHES] plpgpsm /Pavel Stehule/
I think this has to be held for 8.4: it was submitted too late for the 8.3
feature deadline, and in fact I don't recall that there was any community
discussion/consensus
This is not ready for 8.3.
This has been saved for the 8.4 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---
Heikki Linnakangas wrote:
It's been known for years that commit_delay isn't very good
Pavan Deolasee wrote:
I suppose inserting HOT tuples without index maintenance is useful
even if no
changes to the space allocation is made is useful. It won't get the
space
usage but it would save on index thrashing. But that still implies
all the
code to handle
Joshua D. Drake wrote:
Tom Lane wrote:
At this point it seems nothing will be done about this issue for 8.3.
* [PATCHES] plpgpsm /Pavel Stehule/
I think this has to be held for 8.4: it was submitted too late for the 8.3
feature deadline, and in fact I don't recall that there was
On 5/17/07, Joshua D. Drake [EMAIL PROTECTED] wrote:
Pavan Deolasee wrote:
There are few things that we can separate easily, like CREATE INDEX
related changes, VACUUM and VACUUM FULL related changed, space
reuse related changes etc. Let me give it a shot.
Did we ever get a broken up
Joshua D. Drake wrote:
Pavan Deolasee wrote:
I suppose inserting HOT tuples without index maintenance is useful
even if no
changes to the space allocation is made is useful. It won't get the
space
usage but it would save on index thrashing. But that still implies
all
Andrew Dunstan wrote:
That's a good point. So, do we want/need the same for MBCS and ECPG tests?
It would be nice for ECPG. I wasn't even aware of the MBCS stuff - if it
will exercise the unicode sorting which is a little different on Windows
iirc (due to the lack of full native UTF-8
Heikki Linnakangas wrote:
There are few things that we can separate easily, like CREATE INDEX
related changes, VACUUM and VACUUM FULL related changed, space
reuse related changes etc. Let me give it a shot.
Did we ever get a broken up patch for this?
Yes:
Hi,
Tom Lane wrote:
Atul Deopujari [EMAIL PROTECTED] writes:
Hi,
Tom Lane wrote:
That's the least of the problems. We really ought to convert such cases
into an IN (VALUES(...)) type of query, since often repeated indexscans
aren't the best implementation.
I thought of giving this a shot
Hello,
It seems that it may be useful to allow something like:
DROP INDEX NOWAIT.
The idea being, that the terminal will come back, the index will be
dropped in the background. If it doesn't drop, it rollback like normal
and logs.
I bring this up now, as an idea. We can argue about it
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
- --On Thursday, May 17, 2007 09:20:30 -0700 Joshua D. Drake
[EMAIL PROTECTED] wrote:
I say we wait until we actually know where we are at. How is that comparative
from Tom's triage to my email coming?
I agree ... a date gives ppl something to
Andrew Dunstan wrote:
We've had ecpg regression tests being doing by the buildfarm for a
while, but they are not enabled for MSVC. Also, buildfarm has never
supported doing MBCS regression tests. In both cases the regression
tests are driven by Unix shell scripts, and in the MBCS case at
Atul Deopujari [EMAIL PROTECTED] writes:
Yes, letting the planner make its own decision would seem best (in
accordance with what we do for different join paths). But for large IN
lists, a substantial part of the planner is spent in estimating the
selectivity of the ScalarArrayExpr by
OK, date remains unchanged.
---
Marc G. Fournier wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
- --On Thursday, May 17, 2007 09:20:30 -0700 Joshua D. Drake
[EMAIL PROTECTED] wrote:
I say we wait
Is there still a TODO here?
---
Tom Lane wrote:
Log Message:
---
Fix parameter recalculation for Limit nodes: during a ReScan call we must
recompute the limit/offset immediately, so that the updated values are
On Thu, May 17, 2007 at 10:14:45PM +0200, Magnus Hagander wrote:
IIRC, Joachim had started working on the ecpg part. (Which is one of the
reasons I haven't looked at it myself yet)
Joachim, did you ever get anywhere with that?
I have ecpg tests somehow running under msvc but there are still
Bruce Momjian [EMAIL PROTECTED] writes:
Is there still a TODO here?
Tom Lane wrote:
Fix parameter recalculation for Limit nodes:
No, it's fixed AFAIK. Till someone finds another bug anyway ;-)
regards, tom lane
---(end of
Is there a TODO here?
---
Russell Smith wrote:
Alvaro Herrera wrote:
Russell Smith wrote:
Alvaro Herrera wrote:
Alvaro Herrera wrote:
2. decide that the standard is braindead and just
Bruce Momjian wrote:
Is there a TODO here?
Yes, I think so:
* Implement the SQL standard mechanism whereby REVOKE ROLE only revokes
the privilege as granted by the invoking role, and not those granted
by other roles
--
Alvaro Herrera
I have updated the patch status page:
http://developer.postgresql.org/index.php/Todo:PatchStatus#current_8.3_patch_status
I moved some patches that were clearly not ready to the 8.4 queue.
Let's see what we can get applied in the next week and review our
status then.
--
Bruce Momjian
Added to TODO:
---
Alvaro Herrera wrote:
Bruce Momjian wrote:
Is there a TODO here?
Yes, I think so:
* Implement the SQL standard mechanism whereby REVOKE ROLE only revokes
the privilege as granted by the
Yet another potential addition to the family of operators. Some guy
was asking for it on IRC so...
CREATE OR REPLACE FUNCTION interval_over_interval(interval, interval)
RETURNS float STRICT IMMUTABLE LANGUAGE sql AS $$
SELECT extract(epoch from $1)::float / extract(epoch from $2);
$$;
CREATE
Are we going to apply this? I would also like to see a comment added on
why we use SO_REUSEADDR.
---
Magnus Hagander wrote:
On Mon, May 14, 2007 at 09:34:05AM -0400, Andrew Dunstan wrote:
Magnus Hagander wrote:
Andrew Hammond [EMAIL PROTECTED] writes:
Yet another potential addition to the family of operators. Some guy
was asking for it on IRC so...
CREATE OR REPLACE FUNCTION interval_over_interval(interval, interval)
RETURNS float STRICT IMMUTABLE LANGUAGE sql AS $$
SELECT extract(epoch from
Bruce Momjian [EMAIL PROTECTED] writes:
Are we going to apply this?
Not in the form submitted so far, but I trust Magnus is working on
fixing it.
regards, tom lane
---(end of broadcast)---
TIP 6: explain analyze is your
On 5/17/07, Tom Lane [EMAIL PROTECTED] wrote:
Andrew Hammond [EMAIL PROTECTED] writes:
Yet another potential addition to the family of operators. Some guy
was asking for it on IRC so...
CREATE OR REPLACE FUNCTION interval_over_interval(interval, interval)
RETURNS float STRICT IMMUTABLE
Andrew Hammond [EMAIL PROTECTED] writes:
On 5/17/07, Tom Lane [EMAIL PROTECTED] wrote:
What are the grounds for defining it that way rather than some other
way?
The only alternative that came to mind when I wrote it was using a numeric
instead of float.
No, I'm wondering what's the
On Thu, 17 May 2007, David Fetter wrote:
Would you be interested in providing this meat? You're uniquely
qualified because your shins still smart from all the things you
barked them on :)
Unfortunately I'm temporarily on the other side of this problem; all the
time I have to spare right now
Tom Lane wrote:
Atul Deopujari [EMAIL PROTECTED] writes:
Yes, letting the planner make its own decision would seem best (in
accordance with what we do for different join paths). But for large IN
lists, a substantial part of the planner is spent in estimating the
selectivity of the
67 matches
Mail list logo
