On Thu, Sep 18, 2008 at 05:41:16PM +0300, Heikki Linnakangas wrote:
Attached is an updated version of the stripped-down patch. I've cleaned
it up a bit, and added more sanity checks. Documentation is still
missing and I haven't test it much.
FWIW, I disagree with the stripping down and think
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
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
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
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, but
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
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
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
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
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
and
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
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
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
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.
Well, why is that a bug? If
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
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, no?
If
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
[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
the
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. Basically if a
[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
=?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?
Attached is
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
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
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
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.
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
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 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
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 however allow
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
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 think there was
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 (you
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 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
a
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
=?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.
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
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
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
-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.
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
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
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
-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
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.
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
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
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
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
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 rewriting
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
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 generate an
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
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
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 design,
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, 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 like a new OO
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
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
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
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 understand OO
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 that
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
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 guess
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 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
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 do it
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
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 about
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
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
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
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
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 than avg.
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
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
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
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 week.
The
79 matches
Mail list logo
