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 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.

Well my number one issue is the build process which needs to be cleaned
up but there are other more technical issues to be resolved as well.

Joshua D. Drake

>
>
>
>
> John DeSoi, Ph.D.
> http://pgedit.com/
> Power Tools for PostgreSQL
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/docs/faq
>


--

=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/



---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

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 some time.
>
> >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.
>
> Well my number one issue is the build process which needs to be cleaned
> up but there are other more technical issues to be resolved as well.

Yeah, there are also a number of possible improvements documented as
tickets in the Trac site and others that currently exist only as very
vague noise in my head.

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

On Wednesday 19 April 2006 12:09, Jonah H. Harris wrote:
> On 4/19/06, John DeSoi <desoi@pgedit.com> 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 forward.
>

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?

--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

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 <desoi@pgedit.com> 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 forward.
> >
>
> 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?

Nice idea, though it would be much more useful if the reports could be
exported en-masse. There's an export function but it only exports the
user comments, not the error itself. So unless people signup there's no
easy way to get the info to people.

In any case, after you weed out the false-positives and exclude ECPG
you're only talking about less than 50 issues that may need to be
addressed. Hardly a project that will take any amount of time.

Have a nice day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFER5UNIB7bNG8LQkwRApJtAJ9UTNTkQzUbkWja3ogMQO WKq5dnuACfSMBy
8BjoAIBuJi+uFUE9wxhbcTI=
=bVLh
-----END PGP SIGNATURE-----

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 false-positives and exclude ECPG
> you're only talking about less than 50 issues that may need to be
> addressed. Hardly a project that will take any amount of time.

Nor one we'd be willing to wait till the summer to address, if any of
the bugs are real.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

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 mightmake a
> >> good SoC project, but should it also be added to the TODO list?
> > ...
> > In any case, after you weed out the false-positives and exclude ECPG
> > you're only talking about less than 50 issues that may need to be
> > addressed. Hardly a project that will take any amount of time.
>
> Nor one we'd be willing to wait till the summer to address, if any of
> the bugs are real.

Most of the stuff remaining is memory leaks in the src/bin directories,
and ECPG. The memory leaks are not important there (initdb leaks like a
sieve in many places).

About the only thing in the backend I found interesting was this:

src/backend/utils/hash/dynahash.c function hash_create

The numbers are line numbers. Somewhat squished version, hope I didn't
miss anything.

185 if( flags & HASH_SHARED_MEM) {
193 hashp->hcxt = NULL;
197 if (flags & HASH_ATTACH)
198 return hashp;
199 }
256 if (!init_htab(hashp, nelem))
257 {
258 hash_destroy(hashp);

hash_destroy dereferences hashp->hcxt. I don't see anything in
init_htab that special-cases shared memory hashes. The only way this
could be avoided is if HASH_SHARED_MEM was always combined with
HASH_ATTACH. But if so, why the test?

The only other thing we could do, if we were prepare to annotate the
source, is maybe teach it about our locking stuff and have it check
that. But I don't think that's suitable for mainline, more someone's
private tree...

Have a nice day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFER601IB7bNG8LQkwRAgzQAJ4i5TIxBOusxZEDonrknS GEl9618wCfT1mA
tl6MkniY5uRVtp1DaiCv8+U=
=r/TL
-----END PGP SIGNATURE-----

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 gonna
work on a shared-memory hashtable, and in all other cases I'd expect
that any already-allocated table structure will be in a palloc context
that will get cleaned up during error recovery.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

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. Nasby, Sr. Engineering Consultant jnasby@pervasive.com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

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 programs into a state that they can
be integrated into the regression tests.

There are programs already but you can't easily run them, no schema...

Have a nice day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFER/lXIB7bNG8LQkwRApcMAJ974XVtJQM9/akaUWIknOnKkg4F2QCeJytD
0uXuB42HKE1DZziwSuf5I1A=
=EBpH
-----END PGP SIGNATURE-----

> 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 broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org