On Thu, Apr 20, 2006 at 11:56:32AM -0400, Tom Lane wrote:
Martijn van Oosterhout kleptog@svana.org writes:
About the only thing in the backend I found interesting was this:
src/backend/utils/hash/dynahash.c function hash_create
I wonder if we shouldn't just remove the hash_destroy calls in
Martijn van Oosterhout kleptog@svana.org writes:
On Thu, Apr 20, 2006 at 11:56:32AM -0400, Tom Lane wrote:
I wonder if we shouldn't just remove the hash_destroy calls in
hash_create's failure paths. hash_destroy is explicitly not gonna
work on a shared-memory hashtable, and in all other cases
On Mon, Aug 14, 2006 at 08:09:36AM -0400, Tom Lane wrote:
Any thoughts on this? Make it a TODO item, document it, or simply
ignore it?
It's like a two-line patch, so hardly worth putting in TODO ... might
as well just do it. IIRC the motivation is mostly to silence a
Coverity warning?
Martijn van Oosterhout kleptog@svana.org writes:
On Mon, Aug 14, 2006 at 08:09:36AM -0400, Tom Lane wrote:
It's like a two-line patch, so hardly worth putting in TODO ... might
as well just do it. IIRC the motivation is mostly to silence a
Coverity warning?
Well sort of. I can also just
Proposal: XMLType for PostgreSQL.
*** Minimum: ***
to have special type support for storing XML data and working with it.
This means following:
- ability to define any column of a table as of XMLType; internally,
all data is stored as VARCHAR;
- auto validation of documents against XML schema,
You need to submit this through Google.
Student FAQ:
http://code.google.com/soc/studentfaq.html
Student Sign-up:
http://code.google.com/soc/student_step1.html
On 5/2/06, Nikolay Samokhvalov [EMAIL PROTECTED] wrote:
Proposal: XMLType for PostgreSQL.
*** Minimum: ***
to have special type
Jim C. Nasby wrote:
On Mon, Apr 24, 2006 at 11:05:18PM -0400, Tom Lane wrote:
Jonah H. Harris [EMAIL PROTECTED] writes:
While the student could do some benchmarking on relatively new
hardware and make suggestions, I agree with Tom. Having to keep
support for older platforms doesn't
Jonah H. Harris [EMAIL PROTECTED] writes:
On 4/25/06, Andrew Dunstan [EMAIL PROTECTED] wrote:
Personally I would much rather see a tuning advisor tool in more general
use than just provide small/medium/large config setting files.
True dat.
One thing that has to be figured out before we can
PROTECTED]
Cc: Andrew Dunstan [EMAIL PROTECTED]; Jim C. Nasby [EMAIL PROTECTED];
John DeSoi [EMAIL PROTECTED]; Pgsql Hackers pgsql-hackers@postgresql.org
Sent: Tuesday, April 25, 2006 2:16 PM
Subject: Re: [HACKERS] Google SoC--Idea Request
Jonah H. Harris [EMAIL PROTECTED] writes:
On 4/25/06
Personally I would much rather see a tuning advisor tool in
more general
use than just provide small/medium/large config setting files.
True dat.
Maybe the SoC project here is just such a tuning advisor tool? Something
that can run pgbench repeatedly, try different settings, and compare
On 4/25/06, Bort, Paul [EMAIL PROTECTED] wrote:
Maybe the SoC project here is just such a tuning advisor tool? Something
that can run pgbench repeatedly, try different settings, and compare
results.
IIRC, that already exists. I think it was called pg_autotune or
something similar.
--
Jonah
Tom Lane wrote:
Jonah H. Harris [EMAIL PROTECTED] writes:
On 4/25/06, Andrew Dunstan [EMAIL PROTECTED] wrote:
Personally I would much rather see a tuning advisor tool in more general
use than just provide small/medium/large config setting files.
True dat.
One thing that has to be
On Tue, Apr 25, 2006 at 08:39:57AM -0400, Jonah H. Harris wrote:
On 4/25/06, Bort, Paul [EMAIL PROTECTED] wrote:
Maybe the SoC project here is just such a tuning advisor tool? Something
that can run pgbench repeatedly, try different settings, and compare
results.
IIRC, that already
Where do we stand with getting much more reasonable default values in
postgresql.conf? Maybe that should be a SoC project, or is it too small?
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
Pervasive Software http://pervasive.comwork: 512-231-6117
vcard:
Jim C. Nasby [EMAIL PROTECTED] writes:
Where do we stand with getting much more reasonable default values in
postgresql.conf? Maybe that should be a SoC project, or is it too small?
Define much more reasonable.
I doubt this is SoC material, simply because the issues have little to
do with
On 4/24/06, Tom Lane [EMAIL PROTECTED] wrote:
I doubt this is SoC material, simply because the issues have little to
do with coding and a lot to do with persuading people to drop default
support for old platforms. Which is not something a student is likely
to succeed at.
While the student
Jonah H. Harris [EMAIL PROTECTED] writes:
While the student could do some benchmarking on relatively new
hardware and make suggestions, I agree with Tom. Having to keep
support for older platforms doesn't leave much flexibility to change
the defaults.
Another point here is that the defaults
On 4/24/06, Tom Lane [EMAIL PROTECTED] wrote:
We've talked more than once about offering multiple alternative
starting-point postgresql.conf files to give people an idea of what to
do for small/medium/large installations. MySQL have done that for years
and it doesn't seem that users are
On Mon, Apr 24, 2006 at 11:05:18PM -0400, Tom Lane wrote:
Jonah H. Harris [EMAIL PROTECTED] writes:
While the student could do some benchmarking on relatively new
hardware and make suggestions, I agree with Tom. Having to keep
support for older platforms doesn't leave much flexibility to
On 4/25/06, Andrew Dunstan [EMAIL PROTECTED] wrote:
We have already done some initdb tuning improvements for 8.2
Cool, I hadn't looked at this.
I would have liked to increase max_connections too, but that would have
caused problems on OSX, apparently. See previous discussion.
Yeah, their
I hope I'm not too late.
Jonah H. Harris wrote:
On 4/19/06, John DeSoi [EMAIL PROTECTED] wrote:
Alvaro indicated he would be willing to provide direction on this
with testing support from me. He also said there are several other
possible PL/PHP issues that would warrant a SoC project.
Cool... will get them added.
On 4/23/06, Alvaro Herrera [EMAIL PROTECTED] wrote:
I hope I'm not too late.
Jonah H. Harris wrote:
On 4/19/06, John DeSoi [EMAIL PROTECTED] wrote:
Alvaro indicated he would be willing to provide direction on this
with testing support from me. He also said
Christopher Kings-Lynne wrote:
I think Martin Oosterhout's nearby email on coverity bug reports might
make a good SoC project, but should it also be added to the TODO list?
I may as well put up phpPgAdmin for it. We have plenty of projects
available in phpPgAdmin...
Same with pgAdmin3.
On Fri, Apr 21, 2006 at 10:27:48AM +0200, Andreas Pflug wrote:
Christopher Kings-Lynne wrote:
I think Martin Oosterhout's nearby email on coverity bug reports might
make a good SoC project, but should it also be added to the TODO list?
I may as well put up phpPgAdmin for it. We have
Robert and I are working on updating it ASAP.
On 4/21/06, Jim C. Nasby [EMAIL PROTECTED] wrote:
On Fri, Apr 21, 2006 at 10:27:48AM +0200, Andreas Pflug wrote:
Christopher Kings-Lynne wrote:
I think Martin Oosterhout's nearby email on coverity bug reports might
make a good SoC project, but
On Friday 21 April 2006 14:11, Jim C. Nasby wrote:
On Fri, Apr 21, 2006 at 10:27:48AM +0200, Andreas Pflug wrote:
Christopher Kings-Lynne wrote:
I think Martin Oosterhout's nearby email on coverity bug reports might
make a good SoC project, but should it also be added to the TODO list?
On Fri, Apr 21, 2006 at 05:48:33PM -0400, Robert Treat wrote:
On Friday 21 April 2006 14:11, Jim C. Nasby wrote:
On Fri, Apr 21, 2006 at 10:27:48AM +0200, Andreas Pflug wrote:
Christopher Kings-Lynne wrote:
I think Martin Oosterhout's nearby email on coverity bug reports might
make a
Jim C. Nasby wrote:
Same with pgAdmin3.
Is there a list of specific projects? I'm pretty sure we can't just say
work on (pgp)PgAdmin...
Our TODO list has some.
Regards,
Andreas
---(end of broadcast)---
TIP 1: if posting/reading
On Wednesday 19 April 2006 12:09, Jonah H. Harris wrote:
On 4/19/06, John DeSoi [EMAIL PROTECTED] wrote:
Alvaro indicated he would be willing to provide direction on this
with testing support from me. He also said there are several other
possible PL/PHP issues that would warrant a SoC
On Thu, Apr 20, 2006 at 08:51:25AM -0400, Robert Treat wrote:
On Wednesday 19 April 2006 12:09, Jonah H. Harris wrote:
On 4/19/06, John DeSoi [EMAIL PROTECTED] wrote:
Alvaro indicated he would be willing to provide direction on this
with testing support from me. He also said there are
Martijn van Oosterhout kleptog@svana.org writes:
On Thu, Apr 20, 2006 at 08:51:25AM -0400, Robert Treat wrote:
I think Martin Oosterhout's nearby email on coverity bug reports might make a
good SoC project, but should it also be added to the TODO list?
...
In any case, after you weed out the
On Thu, Apr 20, 2006 at 11:04:31AM -0400, Tom Lane wrote:
Martijn van Oosterhout kleptog@svana.org writes:
On Thu, Apr 20, 2006 at 08:51:25AM -0400, Robert Treat wrote:
I think Martin Oosterhout's nearby email on coverity bug reports might
make a
good SoC project, but should it also be
Martijn van Oosterhout kleptog@svana.org writes:
About the only thing in the backend I found interesting was this:
src/backend/utils/hash/dynahash.c function hash_create
I wonder if we shouldn't just remove the hash_destroy calls in
hash_create's failure paths. hash_destroy is explicitly not
Another idea; add the ability for buildfarm machines to do a pgbench run
to stress-test the code. Such a test would probably have found the
windows pgbench issue I reported some time ago.
This would have to be optional, as not all buildfarm machines/owners
would tolerate the benchmark.
--
Jim C.
On Sat, Apr 15, 2006 at 03:05:20PM -0400, Jonah H. Harris wrote:
Hey everyone,
I know we started a discussion a month or so ago regarding ideas for
SoC projects. However, after reading through the thread, I didn't see
us nail down any actual items.
Here's an idea: Get the ECPG test
I think Martin Oosterhout's nearby email on coverity bug reports might make a
good SoC project, but should it also be added to the TODO list?
I may as well put up phpPgAdmin for it. We have plenty of projects
available in phpPgAdmin...
Chris
---(end of
Proposed item: Improve PL/PHP support, especially installation on non-
Linux platforms. PL/PHP does not currently work on OS X (not sure
about Windows, but I doubt it).
Alvaro indicated he would be willing to provide direction on this
with testing support from me. He also said there are
On 4/19/06, John DeSoi [EMAIL PROTECTED] wrote:
Alvaro indicated he would be willing to provide direction on this
with testing support from me. He also said there are several other
possible PL/PHP issues that would warrant a SoC project.
Cool... let's get 'em all listed here so we can move
John DeSoi wrote:
Proposed item: Improve PL/PHP support, especially installation on
non-Linux platforms. PL/PHP does not currently work on OS X (not sure
about Windows, but I doubt it).
It definitely does NOT work on Windows. MacOSX is just a matter of us
having some time.
Alvaro indicated
Joshua D. Drake wrote:
John DeSoi wrote:
Proposed item: Improve PL/PHP support, especially installation on
non-Linux platforms. PL/PHP does not currently work on OS X (not sure
about Windows, but I doubt it).
It definitely does NOT work on Windows. MacOSX is just a matter of us
having
Jim C. Nasby wrote:
On Sat, Apr 15, 2006 at 03:05:20PM -0400, Jonah H. Harris wrote:
All ideas welcome!
I know it's not directly PostgreSQL related, but I'd love to see the
dbt* code improved. Items on my wish-list:
- make it easy to run the test framework and clients on a seperate
machine
On Tue, Apr 18, 2006 at 11:27:40AM -0700, Mark Wong wrote:
Jim C. Nasby wrote:
On Sat, Apr 15, 2006 at 03:05:20PM -0400, Jonah H. Harris wrote:
All ideas welcome!
I know it's not directly PostgreSQL related, but I'd love to see the
dbt* code improved. Items on my wish-list:
- make it
On 4/18/06, Jim C. Nasby [EMAIL PROTECTED] wrote:
On Tue, Apr 18, 2006 at 11:27:40AM -0700, Mark Wong wrote:
Jim C. Nasby wrote:
On Sat, Apr 15, 2006 at 03:05:20PM -0400, Jonah H. Harris wrote:
All ideas welcome!
I know it's not directly PostgreSQL related, but I'd love to see the
Jonah H. Harris wrote:
On 4/18/06, Jim C. Nasby [EMAIL PROTECTED] wrote:
On Tue, Apr 18, 2006 at 11:27:40AM -0700, Mark Wong wrote:
Jim C. Nasby wrote:
On Sat, Apr 15, 2006 at 03:05:20PM -0400, Jonah H. Harris wrote:
All ideas welcome!
I know it's not directly PostgreSQL related, but I'd
OpenMFG has done some work on getting PostgreSQL working with the Drupal CMS
and the Mantis bugtracker (and also integrating those two, btw). We're in
contact with the respective projects about getting our patches worked in, but
if anyone's keeping a tally, just wanted you to be aware.
* Jonah H. Harris ([EMAIL PROTECTED]) wrote:
I know we started a discussion a month or so ago regarding ideas for
SoC projects. However, after reading through the thread, I didn't see
us nail down any actual items.
I got an email already for a good idea, actually, which is to work on
having
On Sat, Apr 15, 2006 at 03:05:20PM -0400, Jonah H. Harris wrote:
All ideas welcome!
I know it's not directly PostgreSQL related, but I'd love to see the
dbt* code improved. Items on my wish-list:
- make it easy to run the test framework and clients on a seperate
machine from the database
-Original Message-
From: Jonah H. Harris[EMAIL PROTECTED]
Sent: 15/04/06 20:06:27
To: Pgsql Hackerspgsql-hackers@postgresql.org
Subject: [HACKERS] Google SoC--Idea Request
As such, we need to quickly put together a list of oh, 15-20 midlevel
project ideas.
Another thought - a nice C
Hey everyone,
I know we started a discussion a month or so ago regarding ideas for
SoC projects. However, after reading through the thread, I didn't see
us nail down any actual items.
As such, we need to quickly put together a list of oh, 15-20 midlevel
project ideas. I'm sure we can pull some
-Original Message-
From: Jonah H. Harris[EMAIL PROTECTED]
Sent: 15/04/06 20:06:27
To: Pgsql Hackerspgsql-hackers@postgresql.org
Subject: [HACKERS] Google SoC--Idea Request
As such, we need to quickly put together a list of oh, 15-20 midlevel
project ideas.
There's a couple
On Sat, 2006-04-15 at 21:24 +0100, Dave Page wrote:
one to allow a message to be sent with the notify, and one to move
from a table based design to shared mem/disk.
Doing the latter is a precondition for implementing the former in a
reasonable way, I believe.
BTW, these two web log entries
On 4/15/06, Neil Conway [EMAIL PROTECTED] wrote:
Doing the latter is a precondition for implementing the former in a
reasonable way, I believe.
BTW, these two web log entries summarizing Mono and Mozilla's
experiences with SoC might make interesting reading:
Thanks for the reading material.
On Saturday 15 April 2006 19:25, Jonah H. Harris wrote:
On 4/15/06, Neil Conway [EMAIL PROTECTED] wrote:
Doing the latter is a precondition for implementing the former in a
reasonable way, I believe.
BTW, these two web log entries summarizing Mono and Mozilla's
experiences with SoC
53 matches
Mail list logo
