Yes, it seems we will have to do something for 8.3. I assume the method
below would reduce frequent updates of the stats_command_string too.
---
Tom Lane wrote:
Arjen van der Meijden told me that according to the
Bruce Momjian [EMAIL PROTECTED] writes:
Yes, it seems we will have to do something for 8.3.
Yeah, we've kind of ignored any possible overhead of the stats mechanism
for awhile, but I think we've got to face up to this if we're gonna have
it on by default.
I assume the method
below would
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Yes, it seems we will have to do something for 8.3.
Yeah, we've kind of ignored any possible overhead of the stats mechanism
for awhile, but I think we've got to face up to this if we're gonna have
it on by default.
I assume the
On Sat, Apr 28, 2007 at 01:34:15PM -0300, Guido Barosio wrote:
My point was to step on the asumption that the implicit serial
call for a type represents the fact that the sequence will start
allways in the same place, unless inmediatelly after your create
table you plan to modify that, which
On Thu, 2007-04-26 at 23:13 -0400, Bruce Momjian wrote:
Our community could probably handle a few of these complex patches, but
the volume for this release is significantly higher than previous
releases. The community is doing a good job of giving patch writers
feedback and new patch
On Sun, 2007-04-29 at 00:44 -0400, Tom Lane wrote:
The first design that comes to mind is that at transaction end
(pgstat_report_tabstat() time) we send a stats message only if at least
X milliseconds have elapsed since we last sent one, where X is
PGSTAT_STAT_INTERVAL or closely related to
Simon Riggs wrote:
On Thu, 2007-04-26 at 23:13 -0400, Bruce Momjian wrote:
Our community could probably handle a few of these complex patches, but
the volume for this release is significantly higher than previous
releases. The community is doing a good job of giving patch writers
feedback
Tom Lane [EMAIL PROTECTED] writes:
So I think that complicating the design with, say, a timeout counter to
force out the stats after a sleep interval is not necessary. Doing so would
add a couple of kernel calls to every client interaction so I'd really
rather avoid that.
Any thoughts,
On 4/28/07, Simon Riggs [EMAIL PROTECTED] wrote:
I think the community has to come up with ideas on how to accomplish this.
My thinking is to move to a two stage release process: Do one
production release annually, and one dev release at the 6 month
mid-point. That way each new release contains
Simon Riggs wrote:
My thinking is to move to a two stage release process: Do one
production release annually, and one dev release at the 6 month
mid-point. That way each new release contains a manageable number of new
features and we have a realistic chance of integrating them
successfully.
Tom Lane wrote:
The first design that comes to mind is that at transaction end
(pgstat_report_tabstat() time) we send a stats message only if at least
X milliseconds have elapsed since we last sent one, where X is
PGSTAT_STAT_INTERVAL or closely related to it. We also make sure to
flush stats
Stefan Kaltenbrunner wrote:
Simon Riggs wrote:
I would also suggest that 8.3 be labelled a dev release. We have a
reasonable number of fairly invasive patches, so we need a mechanism to
integrate them with reduced risk.
I would rather like to see patches we don't are confident enough in
Heikki Linnakangas [EMAIL PROTECTED] writes:
I like the idea of draining the patch queue mid-way through the release cycle.
That'll hopefully encourage people to submit patches earlier in the release
cycle, knowing they will be reviewed. It'll also give people working on
external projects,
Alvaro Herrera [EMAIL PROTECTED] writes:
The postponed patches can be reviewed and committed early in 8.4, instead of
at the last minute in 8.3.
Given that some of those patches have been in the queue since last September
is there any reason to think they'll get reviewed early in this cycle
Tom Lane wrote:
The first design that comes to mind is that at transaction end
(pgstat_report_tabstat() time) we send a stats message only if at least
X milliseconds have elapsed since we last sent one, where X is
PGSTAT_STAT_INTERVAL or closely related to it. We also make sure to
flush
Alvaro Herrera [EMAIL PROTECTED] writes:
Tom Lane wrote:
The first design that comes to mind is that at transaction end
(pgstat_report_tabstat() time) we send a stats message only if at least
X milliseconds have elapsed since we last sent one, where X is
PGSTAT_STAT_INTERVAL or closely
Stefan Kaltenbrunner wrote:
well - i now have a core file but it does not seem to be much worth
except to prove that autovacuum seems to be the culprit:
Core was generated by `postgres: autovacuum worker process
'.
Program terminated with signal 6, Aborted.
Alvaro Herrera wrote:
Stefan Kaltenbrunner wrote:
well - i now have a core file but it does not seem to be much worth
except to prove that autovacuum seems to be the culprit:
Core was generated by `postgres: autovacuum worker process
'.
Program
Alvaro Herrera wrote:
Yeah; the agreement we had was that 8.3 would be a short release. So if
we're going to take too long to review and apply the outstanding patches
we have, we should rather push them to 8.4, get 8.3 released quickly and
then go on with the regular annual release. The
Gregory Stark [EMAIL PROTECTED] writes:
If we want to have an idle_in_statement_timeout then we'll need to introduce a
select loop instead of just directly blocking on recv anyways. Does that mean
we may as well bite the bullet now?
If we wanted such a timeout (which I personally don't) we
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
Simon Riggs wrote:
My thinking is to move to a two stage release process: Do one
production release annually, and one dev release at the 6 month
mid-point.
I'm not really convinced that this is good idea at all - it would lead
to further
Alvaro Herrera [EMAIL PROTECTED] writes:
Oh, another thing that I think may be happening is that the stack is
restored in longjmp, so it is trying to report an error elsewhere but
it crashes because something got overwritten or something; i.e. a
bug in the error recovery code.
Hm, something
Lukas Kahwe Smith [EMAIL PROTECTED] writes:
Hmm, I do not have an overview on this, but like Alvaro mentions, the
shorter release cycles for 8.3 was done because we felt that a number of
patches that were originally slated for 8.2 were almost but not quite
ready for 8.2. So are all of those
Heikki Linnakangas wrote:
I like the idea of draining the patch queue mid-way through the release
cycle. That'll hopefully encourage people to submit patches earlier in
the release cycle, knowing they will be reviewed. It'll also give people
working on external projects, drivers and tools, a
my postgresql source code is at c:/mingw/postgresql and instal to
C:/msys/1.0/local/pgsql/
I add a function to src\backend\utils\adt\geo_ops.c as the following:
*Datum
box_add2(PG_FUNCTION_ARGS)
{
BOX *box = PG_GETARG_BOX_P(0);
Point*p = PG_GETARG_POINT_P(1);*
*
Dave Page wrote:
Heikki Linnakangas wrote:
I like the idea of draining the patch queue mid-way through the
release cycle. That'll hopefully encourage people to submit patches
earlier in the release cycle, knowing they will be reviewed. It'll
also give people working on external projects,
Need help. I want to create new system catalog and extend existing commands
- CREATE ROLE and another commands connected with roles. I can't find how to
add new features into parser. Can you help me?
Thanks.
Akmal.
On Mon, Apr 30, 2007 at 01:36:36AM +0800, shieldy wrote:
my postgresql source code is at c:/mingw/postgresql and instal to
C:/msys/1.0/local/pgsql/
I add a function to src\backend\utils\adt\geo_ops.c as the following:
A few things:
- You never did a CREATE FUNCTION so ofcourse the DB doesn't
On Sun, Apr 29, 2007 at 07:37:09PM +, Akmal Akmalhojaev wrote:
Need help. I want to create new system catalog and extend existing commands
- CREATE ROLE and another commands connected with roles. I can't find how to
add new features into parser. Can you help me?
Check out gram.y in the
Stefan Kaltenbrunner wrote:
This means that there is a huge rush of new code in pgAdmin's
development cycle, right at the time when we should be testing - making
the release process more and more rushed as each release of PostgreSQL
gets more efficient and adds more and more new features.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
- --On Sunday, April 29, 2007 21:30:36 +0200 Stefan Kaltenbrunner
[EMAIL PROTECTED] wrote:
not sure I fully agree here - I think we could do a bit better on the
bug tracking front but it is a bit unclear if we cn honestly sy that
the current
Stefan Kaltenbrunner wrote:
2) Introduce a new patch management system. I suggest a web interface
through which patches be submitted. This would assign them an ID number,
and forward them to the patches list. The system would track any
responses to the initial email, logging the thread
Dave Page wrote:
But I don't like the idea of making a release out of it. Who would
use such a release? No one in production. Making a release comes with
a cost, even if it's just a dev release.
Agreed. That would have the opposite effect of what should happen.
I like the idea of having
On Fri, 27 Apr 2007, Jim Nasby wrote:
Yes, but how many data drives would you need to have to bottleneck on WAL?
Even if the entire database is memory resident you'd still have to write all
the pages out at some point, and it seems to me that you'd need a fair amount
of disk capacity the data
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
- --On Sunday, April 29, 2007 19:38:21 -0400 Andrew Dunstan
[EMAIL PROTECTED]
wrote:
patches held over from feature freeze from the previous
release will be reviewed within two months of the tree re-opening
a. why 2 months? shouldn't they be
Dave Page [EMAIL PROTECTED] writes:
I like the idea of having a sync point mid cycle, however, what I'd like
to see even more is an improved system in which we put less pressure on
the few committers we have, and give them more freedom to commit patches
they may not understand fully
I assume you are trying to create a built-in function, right?
If thats the case you may want to create an entry in pg_proc (That seems
to be missing). Search for box_add in the source code and you will get
an idea what code needs to be added where.
Rgds,
Arul Shaji
shieldy wrote:
my
37 matches
Mail list logo
