On Thu, Mar 6, 2008 at 11:30 PM, Tom Lane [EMAIL PROTECTED] wrote:
I think that just makes things more complex and fragile. I like
Heikki's idea, in part because it makes the normal path and the WAL
recovery path guaranteed to work alike. I'll attach my work-in-progress
patch for this
On Wed, 2008-03-05 at 20:23 -0500, Tom Lane wrote:
Not sure about a clean solution to this. I don't really want to
bastardize inval.c by making it deal with nontransactional semantics,
but there may be no other way.
Is this something that happens only with concurrent VACUUM FULLs ?
If so,
On Fri, Mar 7, 2008 at 3:42 PM, Hannu Krosing [EMAIL PROTECTED] wrote:
Is this something that happens only with concurrent VACUUM FULLs ?
No, its about VACUUM FULL on a system catalog which fails for some reason.
The VACUUM FULL may have changed CTID of a tuple because of line
pointer
Bruce Momjian wrote:
Heikki, are you going to revise this for 8.4?
Probably not. I have other features I want to work on at the moment.
---
Heikki Linnakangas wrote:
I've brought the GIT patch up-to-date with CVS head.
Pavan Deolasee [EMAIL PROTECTED] writes:
The WIP patch looks good to me. I haven't yet tested it (will wait for the
final version). The following pointer arithmetic caught my eye though.
! nunused = (end - nowunused);
Shouldn't we typecast them to (char *) first ?
No ... we want the number
Tom Lane escribió:
Not sure about a clean solution to this. I don't really want to
bastardize inval.c by making it deal with nontransactional semantics,
but there may be no other way.
FWIW IIRC we hit precisely this problem while trying to do the
pg_class_nt stuff awhile ago, so if it's
The first commitfest has been on for about a week now, but I haven't
seem much festivities going on.
Do we plan to drain Bruce's patch queue completely during this
commitfest? Or the items on the developer wiki TODO:PatchStatus list?
When do we declare the commitfest to be over?
Bruce's
It's not clear how this commitfest thing is supposed to work in
practice. May I suggest that:
1. When a patch author wants to have a patch reviewed in the next
commitfest, he posts it to pgsql-patches as usual, and then adds it to
the list on the Todo:PatchStatus page (or perhaps even better,
Heikki Linnakangas wrote:
The first commitfest has been on for about a week now, but I haven't
seem much festivities going on.
Do we plan to drain Bruce's patch queue completely during this
commitfest? Or the items on the developer wiki TODO:PatchStatus list?
When do we declare the
Jim C. Nasby wrote:
-- Start of PGP signed section.
On Wed, Jul 04, 2007 at 01:03:20PM +0200, Dawid Kuroczko wrote:
Hello.
I think it could be a nice idea to put descriptions from
http://www.postgresql.org/docs/8.2/static/catalogs.html
into system catalogs itself. I.e., make a bunch
Heikki Linnakangas [EMAIL PROTECTED] writes:
The first commitfest has been on for about a week now, but I haven't
seem much festivities going on.
Yeah, we are a bit behind on starting it :-(. Bruce was traveling
until the end of February and is still not caught up on updating
his list of open
Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
The first commitfest has been on for about a week now, but I haven't
seem much festivities going on.
Yeah, we are a bit behind on starting it :-(. Bruce was traveling
until the end of February and is still not caught up on
Bruce Momjian wrote:
Tom Lane wrote:
Right at the moment the raw data is still in Bruce's patch queue.
It's becoming increasingly obvious that that isn't going to work;
we can't have one man being a complete bottleneck for the entire
process. I concur with your other suggestion to try
Added to TODO:
o Have \l+ show database size, if permissions allow
Ideally it will not generate an error for invalid permissions
---
Tom Lane wrote:
Brendan Jurd [EMAIL PROTECTED] writes:
I'd find
Fixed for CVS HEAD and 8.3, will fix for previous versions too.
Richard Huxton wrote:
Teodor Sigaev wrote:
So - is this a bug, feature, feature?
It's definitely a bug:
select count(*), query from queries group by query;
count | query
---+--
3 | 'tender'
4 | 'tender'
Alvaro Herrera wrote:
Bruce Momjian wrote:
Tom Lane wrote:
Right at the moment the raw data is still in Bruce's patch queue.
It's becoming increasingly obvious that that isn't going to work;
we can't have one man being a complete bottleneck for the entire
process. I concur with
I assume don't want a TODO for this? (Suppress UPDATE no changed
columns)
---
Andrew Dunstan wrote:
Tom Lane wrote:
Michael Glaesemann [EMAIL PROTECTED] writes:
What would be the disadvantages of always doing
Bruce Momjian [EMAIL PROTECTED] writes:
The bottom line is that this going to be painful no matter how we go at
it:
http://momjian.us/cgi-bin/pgpatches
Yup.
There are nine pages now. The patch queue will be twice that size once
I am done. I am trying to trim but it is difficult.
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
The bottom line is that this going to be painful no matter how we go at
it:
http://momjian.us/cgi-bin/pgpatches
Yup.
There are nine pages now. The patch queue will be twice that size once
I am done. I am trying to trim
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, 7 Mar 2008 12:29:13 -0300
Alvaro Herrera [EMAIL PROTECTED] wrote:
Bruce Momjian wrote:
Tom Lane wrote:
Right at the moment the raw data is still in Bruce's patch queue.
It's becoming increasingly obvious that that isn't going to
I agree with Greg's suggested improvement, and would also like to see
the ability to drop a column or change a column's datatype. Right now
it is a pretty time consuming process to 'alter' a view (i.e. figure out
the dependent views, drop the dependent views, modify the base view, add
back
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
Bruce, you are putting too much of the work on your own shoulders and
bottlenecking the whole process. Just dump stuff into the queue, don't
trim and for heavens sake stop fixing simple things as you go. Once
the queue is there we can
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
Bruce, you are putting too much of the work on your own shoulders and
bottlenecking the whole process. Just dump stuff into the queue, don't
trim and for heavens sake stop fixing simple things as you go. Once
the
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
Since there are 19 pages and probably less than 19 interested hackers,
maybe we could just each take a page of the list as it stands and go
through it at that level? Although many of the threads cross pages, so
that's not ideal. Any
* Tom Lane [EMAIL PROTECTED] [080307 11:46]:
Since there are 19 pages and probably less than 19 interested hackers,
maybe we could just each take a page of the list as it stands and go
through it at that level? Although many of the threads cross pages, so
that's not ideal. Any other ideas?
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
Since there are 19 pages and probably less than 19 interested hackers,
maybe we could just each take a page of the list as it stands and go
through it at that level? Although many of the threads cross pages, so
Aidan Van Dyk wrote:
-- Start of PGP signed section.
* Tom Lane [EMAIL PROTECTED] [080307 11:46]:
Since there are 19 pages and probably less than 19 interested hackers,
maybe we could just each take a page of the list as it stands and go
through it at that level? Although many of the
On Fri, Mar 7, 2008 at 11:48 AM, Bruce Momjian [EMAIL PROTECTED] wrote:
Since there are 19 pages and probably less than 19 interested hackers,
maybe we could just each take a page of the list as it stands and go
through it at that level? Although many of the threads cross pages, so
Bruce Momjian wrote:
Aidan Van Dyk wrote:
-- Start of PGP signed section.
Only 150 patches in that queue, if you eliminate all the discussions
and threads:
http://people.ifax.com/~aidan/pg/patches.mbox
True, but we can't just discard all the ideas we had --- we need to
decide if
* Bruce Momjian [EMAIL PROTECTED] [080307 12:29]:
Aidan Van Dyk wrote:
-- Start of PGP signed section.
* Tom Lane [EMAIL PROTECTED] [080307 11:46]:
Since there are 19 pages and probably less than 19 interested hackers,
maybe we could just each take a page of the list as it stands and
Merlin Moncure escribió:
ISTM if we move to a 'wiki style' patch management, or something more
formal like a bug tracker the work becomes more decentralized and the
patch developer becomes more involved in keeping the patch list up to
date with the latest stuff. I think the wiki, being a
Bruce Momjian wrote:
Add:
o Add SQLSTATE severity to PGconn return status
http://archives.postgresql.org/pgsql-interfaces/2007-11/msg00015.php
Why do we keep the TODO file with the source code? Wouldn't it make
more sense to store it separately?
--
Alvaro Herrera
Aidan Van Dyk wrote:
Only 150 patches in that queue, if you eliminate all the discussions
and threads:
http://people.ifax.com/~aidan/pg/patches.mbox
True, but we can't just discard all the ideas we had --- we need to
decide if they are worth persuing or adding to TODO.
Sure,
Alvaro Herrera wrote:
Merlin Moncure escribi?:
ISTM if we move to a 'wiki style' patch management, or something more
formal like a bug tracker the work becomes more decentralized and the
patch developer becomes more involved in keeping the patch list up to
date with the latest stuff. I
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, 07 Mar 2008 14:33:02 +
Heikki Linnakangas [EMAIL PROTECTED] wrote:
It's not clear how this commitfest thing is supposed to work in
practice. May I suggest that:
1. When a patch author wants to have a patch reviewed in the next
Alvaro Herrera wrote:
Bruce Momjian wrote:
Add:
o Add SQLSTATE severity to PGconn return status
http://archives.postgresql.org/pgsql-interfaces/2007-11/msg00015.php
Why do we keep the TODO file with the source code? Wouldn't it make
more sense to store it separately?
Related to the concurrent discussion about selectivity estimations ...
What is the reason the statistics target is limited to 1000? I've seen more
than one case where increasing the statistics target to 1000 improved results
and one would have wanted to increase it further.
What's the problem
Bruce Momjian wrote:
Alvaro Herrera wrote:
Merlin Moncure escribi?:
ISTM if we move to a 'wiki style' patch management, or something more
formal like a bug tracker the work becomes more decentralized and the
patch developer becomes more involved in keeping the patch list up to
date with the
On Fri, Mar 07, 2008 at 07:25:25PM +0100, Peter Eisentraut wrote:
What's the problem with setting it to ten million if I have ten million
values
in the table and I am prepared to spend the resources to maintain those
statistics?
That it'll probably take 10 million seconds to calculate the
* Bruce Momjian [EMAIL PROTECTED] [080307 13:11]:
Ideas and discussion are important (actually vital). But the
commit-fest is a period that reviewers and committers set apart time to
process the *products* of ideas and proposals that have come about so
far.
Well, when do we make
Am Freitag, 7. März 2008 schrieb Bruce Momjian:
OK, you asked for it. All emails have been moved from pgpatches_hold to
pgpatches. There are 19 pages. Let the pain begin!
http://momjian.us/cgi-bin/pgpatches
OK, now how about moving this directory to developer.postgresql.org, do
Joshua D. Drake wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, 07 Mar 2008 14:33:02 +
Heikki Linnakangas [EMAIL PROTECTED] wrote:
It's not clear how this commitfest thing is supposed to work in
practice. May I suggest that:
1. When a patch author wants to have a patch
Peter Eisentraut wrote:
Am Freitag, 7. M?rz 2008 schrieb Bruce Momjian:
OK, you asked for it. ?All emails have been moved from pgpatches_hold to
pgpatches. ?There are 19 pages. ?Let the pain begin!
http://momjian.us/cgi-bin/pgpatches
OK, now how about moving this directory to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, 07 Mar 2008 18:46:24 +
Heikki Linnakangas [EMAIL PROTECTED] wrote:
I think we'll have more success convincing patch authors to update a
wiki page, than we'll have to convince reviewers to do so. I know
that's true at least for me. If
Added to TODO:
o Store per-table autovacuum settings in pg_class.reloptions.
http://archives.postgresql.org/pgsql-hackers/2007-02/msg01440.php
http://archives.postgresql.org/pgsql-hackers/2008-01/msg00724.php
Joshua D. Drake wrote:
On Fri, 07 Mar 2008 18:46:24 +
Heikki Linnakangas [EMAIL PROTECTED] wrote:
I think we'll have more success convincing patch authors to update a
wiki page, than we'll have to convince reviewers to do so. I know
that's true at least for me. If I want people to
Alvaro Herrera wrote:
Joshua D. Drake wrote:
On Fri, 07 Mar 2008 18:46:24 +
Heikki Linnakangas [EMAIL PROTECTED] wrote:
I think we'll have more success convincing patch authors to update a
wiki page, than we'll have to convince reviewers to do so. I know
that's true at least for me. If
Added to TODO:
* Consider allowing higher priority queries to have referenced buffer
cache pages stay in memory longer
http://archives.postgresql.org/pgsql-hackers/2007-11/msg00562.php
---
Tom Lane wrote:
Devrim
Added to TODO:
* Allow text search dictionary to filter out only stop words
http://archives.postgresql.org/pgsql-patches/2007-11/msg00081.php
---
Tom Lane wrote:
Oleg Bartunov [EMAIL PROTECTED] writes:
Let's
Heikki Linnakangas wrote:
The main point of my proposal is: let's make the *authors* who want
their stuff to be reviewed as part of a commitfest do the extra work.
There would be no extra work required for patch reviewers.
I think this makes the most sense. It distributes the work to
Added to TODO:
o Prevent autovacuum from running if an old transaction is still
running from the last vacuum
http://archives.postgresql.org/pgsql-hackers/2007-11/msg00899.php
---
Christopher
Heikki Linnakangas wrote:
Alvaro Herrera wrote:
Joshua D. Drake wrote:
On Fri, 07 Mar 2008 18:46:24 +
Heikki Linnakangas [EMAIL PROTECTED] wrote:
I think we'll have more success convincing patch authors to update a
wiki page, than we'll have to convince reviewers to do so. I know
Heikki Linnakangas wrote:
The main point of my proposal is: let's make the *authors* who want
their stuff to be reviewed as part of a commitfest do the extra work.
There would be no extra work required for patch reviewers.
I agree with Heikki that for the process to be successful, it should
Andrew Chernow wrote:
Heikki Linnakangas wrote:
The main point of my proposal is: let's make the *authors* who want
their stuff to be reviewed as part of a commitfest do the extra work.
There would be no extra work required for patch reviewers.
I think this makes the most sense. It
Bruce Momjian [EMAIL PROTECTED] writes:
Added to TODO:
* Allow text search dictionary to filter out only stop words
http://archives.postgresql.org/pgsql-patches/2007-11/msg00081.php
That's a poor description. I thought the TODO was something more like
allow dictionaries to change the
On Fri, 7 Mar 2008, Heikki Linnakangas wrote:
If I want people to review my patch, I'm ready to sing and dance if
that's what it takes.
Great timing, there's even a suitable song available for you today:
http://use.perl.org/~grantm/journal/35855
--
* Greg Smith [EMAIL PROTECTED]
Martijn van Oosterhout [EMAIL PROTECTED] writes:
On Fri, Mar 07, 2008 at 07:25:25PM +0100, Peter Eisentraut wrote:
What's the problem with setting it to ten million if I have ten million
values
in the table and I am prepared to spend the resources to maintain those
statistics?
That it'll
Bruce Momjian [EMAIL PROTECTED] writes:
Alvaro Herrera wrote:
Why do we keep the TODO file with the source code? Wouldn't it make
more sense to store it separately?
No idea --- it has always been there because it relates directly to the
source.
I kinda like the fact that the diffs get
Tom Lane wrote:
This is reasonable for the sort of medium-to-large patch that the author
has put a lot of time into. But we also get a lot of small one-off
patches where it's not so reasonable. Now of course many of those get
applied right away, but not all. One of the services that Bruce's
This is reasonable for the sort of medium-to-large patch that the author
has put a lot of time into. But we also get a lot of small one-off
patches where it's not so reasonable. Now of course many of those get
applied right away, but not all.
Just a thought... maybe a distinction should
On 08/03/2008, Heikki Linnakangas [EMAIL PROTECTED] wrote:
I think we'll have more success convincing patch authors to update a
wiki page, than we'll have to convince reviewers to do so. I know that's
true at least for me. If I want people to review my patch, I'm ready to
sing and dance if
61 matches
Mail list logo
