Prev: ERROR: argument to pg_get_expr() must come from system catalogs
Next: [HACKERS] testing plpython3u on 9.0beta3
From: Markus Wanner on 15 Jul 2010 16:00
Hi,

On 07/15/2010 09:51 PM, Jaime Casanova wrote:
> so, merging this with the autovacuum will drop our hopes of having a
> time based autovacuum? not that i'm working on that nor i was thinking
> on working on that... just asking to know what the implications are,
> and what the future improves could be if we go this route

Not at all. Autovacuum should work exactly as before (seen from the
outside, the implementation is a bit different). The coordinator is an
async event processor. Events may origin from sockets, or may be driven
by time, as is the case for autovacuum (up to something like a 1 second
precision or something, I don't remember exactly).

(There's nothing that needs to be merged with autovacuum. It already is
merged, if you want).

Regards

Markus Wanner

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Alvaro Herrera on 15 Jul 2010 16:37
Excerpts from Jaime Casanova's message of jue jul 15 15:51:10 -0400 2010:
> On Thu, Jul 15, 2010 at 1:28 PM, Markus Wanner <markus(a)bluegap.ch> wrote:
> >
> > However, note that the coordinator is designed to be just a message
> > passing or routing process, which should not do any kind of time
> > consuming processing. It must *coordinate* things (well, jobs) and react
> > promptly. Nothing else.
>
> so, merging this with the autovacuum will drop our hopes of having a
> time based autovacuum?

I don't think so, but I didn't know we had hopes for time-based
autovacuum. What exactly do you mean?

Initially there were some thoughts on schedule-based autovacuum
parameters, but it seems that interest has dropped for that feature, so
I haven't pushed much for that. However, I don't think that this patch
series affects that in any way.

BTW I think this patch series makes sense, though I haven't looked at it
in detail. I guess it means I'll have to have a look at the IMessages
stuff as well.

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Simon Riggs on 17 Jul 2010 06:30
On Tue, 2010-07-13 at 16:30 +0200, Markus Wanner wrote:

> I've combined these two components into a single, general purpose
> background worker infrastructure component

I think many people want such a feature, so the requirement is good.

The code itself merely reflects your design, so what I would really like
to see is a full explanation of this. If the generalisation is to be
accepted we need a very clear explanation of how it works and details of
the API since that is what's needed to allow other people besides
yourself to begin using it for patches in 9.1.

If we can see the docs on that SGML/README form then we'll be able to
more quickly agree how to proceed. After that, reviewing your patch
against that design will be easy/ier.

Let's go for this in stages. If we can get something basic and useful
for lots of people in this commitfest, we can layer on the other stuff
later.

--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Training and Services


--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Markus Wanner on 17 Jul 2010 07:47
Hello Simon,

On 07/17/2010 12:30 PM, Simon Riggs wrote:
> The code itself merely reflects your design, so what I would really like
> to see is a full explanation of this.

Are the descriptive mails I sent for each patch going into the right
direction and just need to be extended, in your opinion? Or are you
really missing something in there?

It's easier to answer more specific questions.

> If the generalisation is to be
> accepted we need a very clear explanation of how it works and details of
> the API since that is what's needed to allow other people besides
> yourself to begin using it for patches in 9.1.

Understood.

> If we can see the docs on that SGML/README form then we'll be able to
> more quickly agree how to proceed. After that, reviewing your patch
> against that design will be easy/ier.

I don't think SGML makes much sense, as there are not many user visible
changes that need to go into the manual (except for the GUCs, those
certainly require to be mentioned in the manual).

If you agree, I'd add the currently sent descriptions to README files in
the source.

I think that I commented the source code pretty extensively, however,
that's a subjective feeling.

I'm under the impression, that I commented the source code pretty well.

> Let's go for this in stages. If we can get something basic and useful
> for lots of people in this commitfest, we can layer on the other stuff
> later.
>


--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Markus Wanner on 17 Jul 2010 07:53
Sorry, hit send too early.

On 07/17/2010 01:47 PM, Markus Wanner wrote:
> I think that I commented the source code pretty extensively, however,
> that's a subjective feeling.

Take this phrase.

> I'm under the impression, that I commented the source code pretty well.

Scratch that, please.

:-)


You wrote:
>> Let's go for this in stages. If we can get something basic and useful
>> for lots of people in this commitfest, we can layer on the other stuff
>> later.

Hm.. agreed. That's why I split into dynshmem, imessages and steps 1 - 6
of bgworker.

I'm expecting controversy and discussion about dynshmem, which is a
dependency of all of my other patches. So, maybe we should start there?

Or what kind of staging did you have in mind?

Regards

Markus

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: ERROR: argument to pg_get_expr() must come from system catalogs
Next: [HACKERS] testing plpython3u on 9.0beta3