http://pqxx.org/development/libpqxx/
I'm in the process of creating a macport for libpqxx. I could use
some help from anyone with experience in building postgresql or
libpqxx on OSX, esp. against the macport libraries.
Thanks, Darren
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgr
On Fri, 2008-09-19 at 17:47 -0400, Tom Lane wrote:
> Greg Smith <[EMAIL PROTECTED]> writes:
> > On Fri, 19 Sep 2008, Greg Stark wrote:
> >> This is a good example of why running with assertions enabled on
> >> production
> >> might not be a good idea. But it's also a good example of why we shoul
On Fri, 2008-09-19 at 17:33 -0400, Greg Smith wrote:
> On Fri, 19 Sep 2008, Greg Stark wrote:
>
> > This is a good example of why running with assertions enabled on production
> > might not be a good idea. But it's also a good example of why we should do
> > our performance testing with asserti
Josh Berkus wrote:
>>> That's kind of what I'm doing now. But I'm wondering if I should
>>> bother with pgFoundry at all. It seems pretty dead (see Josh Berkus's
>>> reply).
>>>
>
> Actually, pgFoundry remains extremely popular. Currently, we're getting an
> average of 2-3 new projects a w
> C isn't going anywhere anytime soon. Look at its history, it has survived
> its 'replacements' over and over again. The most popular kernels, shells
> and applications are all still written in C (new and old). Where are the
> warning signs that it is dwindling?
To add to this:
It's easy to u
A.M. wrote:
On Sep 19, 2008, at 1:42 PM, Robert Haas wrote:
It's too early to vote. :-)
The second and third option have prerequisite.
The purpose of them is to match granularity of access controls
provided by SE-PostgreSQL and native PostgreSQL. However, I have
not seen a clear reason why th
I'm surprised no one pointed out that Postgres has *already* been ported
to a new language once. It was originally written in Lisp, and was
rewritten in C sometime in the Berkeley years. (Anyone know exactly
when or by whom? I don't.) You can still see the effects of that
origin in the system's
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Zdenek Kotala wrote:
>> Second idea is that new FSM creates heavy defragmented data and index
>> scan needs to jump from one page to another too often.
> Hmm. That's remotely plausible, I suppose. The old FSM only kept track
> of pages with more t
Thank you all for your opinion.
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> Andrew Dunstan
> Sent: Saturday, September 20, 2008 12:53 AM
> To: Gevik Babakhani
> Cc: 'Joshua Drake'; 'Jonah H. Harris'; 'Dave Page'; 'PGSQL
> Hackers'; [EMAIL
Gevik Babakhani wrote:
I think the better question about all of this is:
What is the problem we are trying to solve?
Providing solutions that are looking for problems doesn't help us.
Sincerely,
Perhaps the current codebase and design in C will serve us for years and
years to come. In
Joshua Drake wrote:
On Fri, 19 Sep 2008 23:01:15 +0200
"Gevik Babakhani" <[EMAIL PROTECTED]> wrote:
Unless I am very off. C++ is a natural choice when porting
(upgrading) ANSI C application.
As far as I know, most universities teach some sort of OO programming
language like JAVA or C# to help s
Gevik Babakhani wrote:
I think the better question about all of this is:
What is the problem we are trying to solve?
Providing solutions that are looking for problems doesn't help us.
Sincerely,
Perhaps the current codebase and design in C will serve us for years and
years to come. In fa
On Fri, Sep 19, 2008 at 10:13:43AM +0300, Heikki Linnakangas wrote:
> In addition to catalog changes, for finer grained collation you need
> changes in the planner and executor as well. In planner, to provide
> support for the concept of a sort order using a specific collation, and
> track that
> I think the better question about all of this is:
> What is the problem we are trying to solve?
> Providing solutions that are looking for problems doesn't help us.
> Sincerely,
Perhaps the current codebase and design in C will serve us for years and
years to come. In fact there is no doubt abo
All,
> I don't see how you think it will help. Most universities (here in
> the US at least), are shying away from teaching C/C++. So, in the
> long run, I don't see how that would really help us get more developer
> involvement.
Last I checked, we *weren't* having any problem recruiting develo
Greg Smith <[EMAIL PROTECTED]> writes:
> On Fri, 19 Sep 2008, Greg Stark wrote:
>> This is a good example of why running with assertions enabled on production
>> might not be a good idea. But it's also a good example of why we should do
>> our performance testing with assertions enabled if we can
Heikki Linnakangas wrote:
Here's an updated version of the stripped-down patch, now with
documentation changes, plus a couple of minor bug fixes.
Another update, marching towards committing. Now with pg_dump/pg_dumpall
support, and collation/ctype is also shown in psql \l output.
I wonder if
On Fri, 19 Sep 2008, Greg Stark wrote:
This is a good example of why running with assertions enabled on production
might not be a good idea. But it's also a good example of why we should do
our performance testing with assertions enabled if we can do it without
invalidating the results.
The
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Here's an updated version of the stripped-down patch, now with
> documentation changes, plus a couple of minor bug fixes.
> I think this is looking pretty good now, and I would appreciate review
> from others before I go ahead committing this.
I
Greg,
> I agree with this 100%, my only issue is with the method and timing of
> "making it clear". Until now, there has been zero indication from
> the release notes, the website, or the community that 7.4 will be
> soon unsupported. If we are going to announce that, we should be making
> the ann
> > That's kind of what I'm doing now. But I'm wondering if I should
> > bother with pgFoundry at all. It seems pretty dead (see Josh Berkus's
> > reply).
Actually, pgFoundry remains extremely popular. Currently, we're getting an
average of 2-3 new projects a week.
The issue with pgFoundry is
On Fri, 19 Sep 2008 23:01:15 +0200
"Gevik Babakhani" <[EMAIL PROTECTED]> wrote:
> Unless I am very off. C++ is a natural choice when porting
> (upgrading) ANSI C application.
> As far as I know, most universities teach some sort of OO programming
> language like JAVA or C# to help students underst
On Fri, Sep 19, 2008 at 09:54:53PM +0200, Gevik Babakhani wrote:
> Dear PG hackers,
>
> Has there been any idea to port PG to a more modern programming
> language like C++? Of course there are some minor obstacles like a
> new OO design, this being a gigantic task to perform and rewriting
> almost
> Already done!
>
> http://www.postgresql.org/community/weeklynews/pwn20050401
>
Yes, yes COBOL :) PostCobolSQL
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
> I don't think so. Firebird rewrote their entire kernel to be
> C++ and in doing so, lost a lot of maturity along-the-way
I would not make any sense to put/group functions in one or more classes
without using the OO patterns. I guess this is what Firebird has done.
> Similarly switching to a
On Fri, Sep 19, 2008 at 08:57:36PM +0100, Dave Page wrote:
> On Fri, Sep 19, 2008 at 8:54 PM, Gevik Babakhani <[EMAIL PROTECTED]> wrote:
> >
> > Dear PG hackers,
> >
> > Has there been any idea to port PG to a more modern programming language
> > like C++? Of course there are some minor obstacles l
On Fri, Sep 19, 2008 at 4:32 PM, Gevik Babakhani <[EMAIL PROTECTED]> wrote:
> It might look like an impossible goal to achieve.. But if there is any
> serious plan/idea/ammo for this, I believe it would be very beneficial to
> the continuity of PG.
I don't think so. Firebird rewrote their entire
On Fri, 19 Sep 2008 20:57:36 +0100
"Dave Page" <[EMAIL PROTECTED]> wrote:
> On Fri, Sep 19, 2008 at 8:54 PM, Gevik Babakhani <[EMAIL PROTECTED]> wrote:
> > Has there been any idea to port PG to a more modern programming language
> > like C++? Of course there are some minor obstacles like a new OO d
It might look like an impossible goal to achieve.. But if there is any
serious plan/idea/ammo for this, I believe it would be very beneficial to
the
continuity of PG.
Regards,
Gevik.
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Dave Page
> S
Zdenek Kotala wrote:
Zdenek Kotala napsal(a):
Heikki Linnakangas napsal(a):
Zdenek Kotala wrote:
My conclusion is that new implementation is about 8% slower in OLTP
workload.
Can you do some analysis of why that is?
I tested it several times and last test was surprise for me. I run
origin
"Merlin Moncure" <[EMAIL PROTECTED]> writes:
> On Fri, Sep 19, 2008 at 2:14 PM, Andrew Chernow <[EMAIL PROTECTED]> wrote:
>> BTW, the event system might be an alternative solution for PGNoticeHooks
>> (PGEVT_NOTICE).
> Another possible use of the event hooks -- just spitballing here -- is
> to gen
Andrew Chernow <[EMAIL PROTECTED]> writes:
> I attached a patch. You have to copy the events in PQmakeEmptyPGResult
> because there is no where else to do this, other than copyresult but
> that is different because it copies from a result not a conn.
Applied ...
> PQgetResult now calls PQfireR
On Fri, Sep 19, 2008 at 8:54 PM, Gevik Babakhani <[EMAIL PROTECTED]> wrote:
>
> Dear PG hackers,
>
> Has there been any idea to port PG to a more modern programming language
> like C++? Of course there are some minor obstacles like a new OO design,
> this being a gigantic task to perform and rewrit
Gevik Babakhani wrote:
Has there been any idea to port PG to a more modern programming language
like C++?
No.
(You can take your M16 and start shooting now)
My pleasure ;-).
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-
On Fri, 19 Sep 2008 21:54:53 +0200
"Gevik Babakhani" <[EMAIL PROTECTED]> wrote:
>
> Dear PG hackers,
>
> Has there been any idea to port PG to a more modern programming
> language like C++? Of course there are some minor obstacles like a
> new OO design, this being a gigantic task to perform and
What about Assembla? http://assembla.com/
[]'s
- Walter
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Dear PG hackers,
Has there been any idea to port PG to a more modern programming language
like C++? Of course there are some minor obstacles like a new OO design,
this being a gigantic task to perform and rewriting almost everything etc...
I am very interested to hear your opinion.
(You can take
Andrew Chernow <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> BTW, why are all the conn parameters to events declared "const"? Isn't
> Because it looked prettier? Kidding. No idea, do you want me to change
> that or do you want to?
I'll fix it; it's hardly worth passing a patch around for.
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
> I don't understand this, as soon as we released 8.0 you could take that as
> advance warning that 7.4 was going to be desupported someday. So in that sense
> they've had four years warning that this time was coming. The fact that the
> date wa
Tom Lane wrote:
BTW, why are all the conn parameters to events declared "const"? Isn't
Because it looked prettier? Kidding. No idea, do you want me to change
that or do you want to?
the reason for passing them in mainly to give the event proc a chance
to issue queries?
Partly. You a
BTW, why are all the conn parameters to events declared "const"? Isn't
the reason for passing them in mainly to give the event proc a chance
to issue queries?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
David E. Wheeler wrote:
On Sep 18, 2008, at 19:01, Alvaro Herrera wrote:
Why not host the code on (say) GitHub, and the rest of the stuff on
pgFoundry?
That's kind of what I'm doing now. But I'm wondering if I should
bother with pgFoundry at all. It seems pretty dead (see Josh Berkus's
re
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
> It's really past time to make it clear to all concerned that if they
> want continued bug fixes for 7.4, they'd better start paying somebody
> to do it.
I agree with this 100%, my only issue is with the method and timing of
"making it clear".
On Sep 19, 2008, at 1:42 PM, Robert Haas wrote:
It's too early to vote. :-)
The second and third option have prerequisite.
The purpose of them is to match granularity of access controls
provided by SE-PostgreSQL and native PostgreSQL. However, I have
not seen a clear reason why these different
greg
On 19 Sep 2008, at 20:13, Tom Lane <[EMAIL PROTECTED]> wrote:
Greg Stark <[EMAIL PROTECTED]> writes:
You'll also have to do enough empirical tests to convince people that
a --enable-cheap-casserts build really does perform the same as a
regular build.
I don't think performance is even
Greg Stark <[EMAIL PROTECTED]> writes:
> You'll also have to do enough empirical tests to convince people that
> a --enable-cheap-casserts build really does perform the same as a
> regular build.
I don't think performance is even the main issue. We have never
recommended having Asserts on in
=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= <[EMAIL PROTECTED]> writes:
> Attached is a version that stores the minimal and maximal frequencies in
> the Numbers array, has the aforementioned assertion and more nicely
> ordered functions in ts_selfuncs.c.
Applied with some small corrections.
Robert Haas wrote:
It's too early to vote. :-)
The second and third option have prerequisite.
The purpose of them is to match granularity of access controls
provided by SE-PostgreSQL and native PostgreSQL. However, I have
not seen a clear reason why these different security mechanisms
have to ha
On Fri, Sep 19, 2008 at 11:42 AM, Robert Treat <[EMAIL PROTECTED]
> wrote:
> On Friday 19 September 2008 00:23:34 Jeffrey Baker wrote:
> > Anyway, I have some issues. One, of course, is that the autovacuum
> should
> > not have been deadlocked or otherwise stalled like that. Perhaps it
> needs
>
On Friday 19 September 2008 00:23:34 Jeffrey Baker wrote:
> Anyway, I have some issues. One, of course, is that the autovacuum should
> not have been deadlocked or otherwise stalled like that. Perhaps it needs
> a watchdog of some kind. Has anyone else experienced an issue like that in
> 8.3.1?
On Fri, Sep 19, 2008 at 2:14 PM, Andrew Chernow <[EMAIL PROTECTED]> wrote:
>
> BTW, the event system might be an alternative solution for PGNoticeHooks
> (PGEVT_NOTICE).
>
Another possible use of the event hooks -- just spitballing here -- is
to generate an event when a notification comes through
On Friday 19 September 2008 14:05:36 David E. Wheeler wrote:
> On Sep 18, 2008, at 18:43, Robert Treat wrote:
> >>* Google Code
> >
> > does not offer mailing lists
>
> I get mail for the test-more project there. It's through Google
> Groups, which is a little weird, but works.
>
I didn't thin
Tom Lane wrote:
I'll go ahead and apply this patch in a little bit, but if you concur
with the above reasoning, please put together a followon patch to add
such a function.
regards, tom lane
I attached a patch. You have to copy the events in PQmakeEmptyPGResult
bec
On Fri, 19 Sep 2008 11:05:36 -0700
"David E. Wheeler" <[EMAIL PROTECTED]> wrote:
> >> * LaunchPad
> >
> > does not offer svn or git, and i think they dont offer a home page
> > service
>
> It uses Bazaar. WTF is that? I've never heard of it.
Another git/mecurial/monotone style SCM. It does
On Sep 19, 2008, at 01:25, Dimitri Fontaine wrote:
There's a french non-profit team offering those:
http://tuxfamily.org/en/main
You can even take their open source hosting facility software and
offer your
own services based on it, and/or extend their perl code to add new
features.
I trie
On Sep 18, 2008, at 19:01, Alvaro Herrera wrote:
Why not host the code on (say) GitHub, and the rest of the stuff on
pgFoundry?
That's kind of what I'm doing now. But I'm wondering if I should
bother with pgFoundry at all. It seems pretty dead (see Josh Berkus's
reply).
Best,
David
--
On Sep 18, 2008, at 18:43, Robert Treat wrote:
* Google Code
does not offer mailing lists
I get mail for the test-more project there. It's through Google
Groups, which is a little weird, but works.
* LaunchPad
does not offer svn or git, and i think they dont offer a home page
s
greg
On 19 Sep 2008, at 13:20, Tom Lane <[EMAIL PROTECTED]> wrote:
Simon Riggs <[EMAIL PROTECTED]> writes:
Can we introduce levels of assertion?
The thing that is good about Assert() is that it doesn't require a lot
of programmer effort to put one in. I'm not in favor of complexifying
it.
> It's too early to vote. :-)
>
> The second and third option have prerequisite.
> The purpose of them is to match granularity of access controls
> provided by SE-PostgreSQL and native PostgreSQL. However, I have
> not seen a clear reason why these different security mechanisms
> have to have same
Robert Haas wrote:
[2] Make a new implementation of OS-independent fine grained access control
If it is really really necessary, I may try to implement a new separated
fine-grained access control mechanism due to the CommitFest:Nov.
However, we don't have enough days to develop one more new feat
Tom Lane wrote:
=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= <[EMAIL PROTECTED]> writes:
[EMAIL PROTECTED] wrote:
Well whaddya know. It turned out that my new company has a
'Fridays-are-for-any-opensource-hacking-you-like' policy, so I got a
full day to work on the patch.
Hm, does their name start with
=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] wrote:
> Well whaddya know. It turned out that my new company has a
> 'Fridays-are-for-any-opensource-hacking-you-like' policy, so I got a
> full day to work on the patch.
Hm, does their name start with G?
> Attach
[EMAIL PROTECTED] wrote:
Quoting Tom Lane <[EMAIL PROTECTED]>:
I wrote:
... One possibly
performance-relevant point is to use DatumGetTextPP for detoasting;
you've already paid the costs by using VARDATA_ANY etc, so you might
as well get the benefit.
Actually, wait a second. That code does
Andrew Chernow <[EMAIL PROTECTED]> writes:
>> To build on this analogy, PGEVT_CONNRESET is like a realloc. Meaning,
>> the initial malloc "PGEVT_REGISTER" worked by the realloc
>> "PGEVT_CONNRESET" didn't ... you still have free "PGEVT_CONNDESTROY" the
>> initial. Its documented that way. Bas
> [2] Make a new implementation of OS-independent fine grained access control
>
> If it is really really necessary, I may try to implement a new separated
> fine-grained access control mechanism due to the CommitFest:Nov.
> However, we don't have enough days to develop one more new feature from
> t
Zdenek Kotala napsal(a):
Heikki Linnakangas napsal(a):
Zdenek Kotala wrote:
My conclusion is that new implementation is about 8% slower in OLTP
workload.
Can you do some analysis of why that is?
I tested it several times and last test was surprise for me. I run original
server (with old FS
Andrew Dunstan wrote:
>
>
> Magnus Hagander wrote:
>> I had a chat with Heikki about this, and the proper way to fix it.
>>
>> Should there actually be any reason not to *always* open our files with
>> O_BINARY? That seems to be what should mimic what Unix does, which would
>> be what we expect,
Magnus Hagander wrote:
I had a chat with Heikki about this, and the proper way to fix it.
Should there actually be any reason not to *always* open our files with
O_BINARY? That seems to be what should mimic what Unix does, which would
be what we expect, no?
If that is so, then I propose we do
Magnus Hagander wrote:
> Heikki Linnakangas wrote:
>> ITAGAKI Takahiro wrote:
>>> Tom Lane <[EMAIL PROTECTED]> wrote:
>>>
ITAGAKI Takahiro <[EMAIL PROTECTED]> writes:
> We probably need to add PG_BINARY when we open control files
> because 0x1A is an end-of-file marker on Windows.
Andrew Chernow <[EMAIL PROTECTED]> writes:
> Are there any plans to commit these libpq-events changes this fest?
Sorry about that, I got distracted. Will look at it shortly.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
Here's an updated version of the stripped-down patch, now with
documentation changes, plus a couple of minor bug fixes.
I think this is looking pretty good now, and I would appreciate review
from others before I go ahead committing this. Is there any more places
in the documentation that needs
Are there any plans to commit these libpq-events changes this fest?
http://archives.postgresql.org/pgsql-hackers/2008-09/msg01109.php
I wanted to release an updated libpqtypes but am waiting on the above
patch. If not, I'll release it now.
--
Andrew Chernow
eSilo, LLC
every bit counts
http:/
Even with that a hunk failed for bufpage.c, but I applied that part
manually to move on.
Regards
Abbas
On Thu, 2008-09-18 at 12:17 +0200, Zdenek Kotala wrote:
> Abbas napsal(a):
> > Hi,
> > I downloaded latest postgresql source code from
> > git clone git://git.postgresql.org/git/postgresql.git
>
Simon Riggs <[EMAIL PROTECTED]> writes:
> Can we introduce levels of assertion?
The thing that is good about Assert() is that it doesn't require a lot
of programmer effort to put one in. I'm not in favor of complexifying
it.
regards, tom lane
--
Sent via pgsql-hackers m
On Tue, 2008-09-09 at 09:11 +0100, Simon Riggs wrote:
> This gives us the Group Commit feature also, even if we are not using
> replication. So we can drop the commit_delay stuff.
>
> XLogBackgroundFlush() processes data page at a time if it can. That may
> not be the correct batch size for XLog
David E. Wheeler napsal(a):
Howdy,
Overall, it should be easy to find my project, and easy to download it
and build it for PostgreSQL. I've had the following suggestions for
places to try, in addition to pgFoundry:
* github
* Google Code
* LaunchPad
* WebFaction
You can try http
Quoting Tom Lane <[EMAIL PROTECTED]>:
I wrote:
... One possibly
performance-relevant point is to use DatumGetTextPP for detoasting;
you've already paid the costs by using VARDATA_ANY etc, so you might
as well get the benefit.
Actually, wait a second. That code doesn't work at all on toasted
Le jeudi 18 septembre 2008, David E. Wheeler a écrit :
> So I'm wondering, given the various discussions of PostgreSQL module
> hosting in the past, where would be a good place to put a PostgreSQL
> module project? The things I would like to have are:
>
>* SVN or git hosting (I've not used git,
Currently we have only Assert(), or a run-time test.
Can we introduce levels of assertion? That way we can choose how
paranoid a build to make, like setting log_min_messages.
We know many Assertions are costly, so we don't usually do performance
tests with --enable-cassert. But then we may not no
Jeffrey Baker wrote:
Secondly, there really does need to be an autovacuum=off,really,thanks so
that my maintenance can proceed without competition for i/o resources. Is
there any way to make that happen?
You could bump up autovacuum_freeze_max_age while you run the vacuums
manually, and then
Martijn van Oosterhout wrote:
FWIW, I disagree with the stripping down and think we should aim for
the whole patch as submitted. Historically, the hardest part of getting
collation support into postgres has been the catalog changes and easier
the support for something other than OS locales. I sup
81 matches
Mail list logo
