Prev: Streaming replication and unfit messages
Next: [HACKERS] SR: "pseudo replication database of the primary" ...
From: Magnus Hagander on 18 Feb 2010 04:43
2010/2/18 Tom Lane <tgl(a)sss.pgh.pa.us>:
> In connection with the recent discussion of changing SearchSysCache call
> format, Robert espoused the view that right now is the time when there
> are a minimal number of outstanding patches that would suffer merge
> problems from an invasive change.  That seems correct to me --- although
> ideally everyone should be thinking "beta test" for the next few months,
> we all know there will be some development going on in people's private
> trees.
>
> Which leads me to the thought that rather than postponing running
> pgindent until late beta, maybe we should run it *now*, and get the
> bulk of its work done for the new code in 9.0.  Then people would have
> a solid base to patch against, rather than having to expect a major
> merge hassle at the end of beta.
>
> We'd probably still want to run pgindent again at the traditional
> point in the cycle, but if we did one now then the final run would
> only be fixing sloppiness in beta-period fixes, and it should make
> relatively few changes.
>
> I have a personal interest in this because I'm hoping to spend time
> over the next few weeks reading all of the HS/SR code in detail, and
> it will be nicer to look at if it's formatted to project standards;
> which quite a lot of it is not at the moment.
>
> Comments?

I think it's a good idea in general. There are of course people out
there with patches *already* that will have problems with this, but
they'll have the problem eventually anyway. The only real stopper
there is if someone (Simon would be the most likelyi I guess?) has a
big fixup change queued up or so - but if someone does, we can just
postpone until right after that one...

The followup question is of course, what do we do with fixup patches
that land *after* this? Do we run pgindent once more later in the
cycle? That should be a fairly small run in that case, so it might be
worth doing it that way?

--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/

--
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: Heikki Linnakangas on 18 Feb 2010 05:02
Magnus Hagander wrote:
> 2010/2/18 Tom Lane <tgl(a)sss.pgh.pa.us>:
>> Which leads me to the thought that rather than postponing running
>> pgindent until late beta, maybe we should run it *now*, and get the
>> bulk of its work done for the new code in 9.0. Then people would have
>> a solid base to patch against, rather than having to expect a major
>> merge hassle at the end of beta.
> ...
> I think it's a good idea in general.

Yep, +1 for running pgindent now.

> There are of course people out
> there with patches *already* that will have problems with this, but
> they'll have the problem eventually anyway. The only real stopper
> there is if someone (Simon would be the most likelyi I guess?) has a
> big fixup change queued up or so - but if someone does, we can just
> postpone until right after that one...

It's worth noting that any patches that bit-rot because of pgindent run
can be fixed with the following procedure:

1. check out the source tree just before pgindent.
2. Apply patch
3. Run pgindent
4. Diff against source tree just after pgindent.

> The followup question is of course, what do we do with fixup patches
> that land *after* this? Do we run pgindent once more later in the
> cycle? That should be a fairly small run in that case, so it might be
> worth doing it that way?

Yeah, that was Tom's plan.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

--
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: Magnus Hagander on 18 Feb 2010 05:14
2010/2/18 Heikki Linnakangas <heikki.linnakangas(a)enterprisedb.com>:
> Magnus Hagander wrote:
>> There are of course people out
>> there with patches *already* that will have problems with this, but
>> they'll have the problem eventually anyway. The only real stopper
>> there is if someone (Simon would be the most likelyi I guess?) has a
>> big fixup change queued up or so - but if someone does, we can just
>> postpone until right after that one...
>
> It's worth noting that any patches that bit-rot because of pgindent run
>  can be fixed with the following procedure:
>
> 1. check out the source tree just before pgindent.
> 2. Apply patch
> 3. Run pgindent
> 4. Diff against source tree just after pgindent.

Doesn't that require that all pgindent runs produce the same output?
Which they generally don't due to different sets of typedefs and
stuff? It's a solvable problem of course, but not quite as simple as
you make it sound :-)


--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/

--
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: Heikki Linnakangas on 18 Feb 2010 05:21
Magnus Hagander wrote:
> 2010/2/18 Heikki Linnakangas <heikki.linnakangas(a)enterprisedb.com>:
>> It's worth noting that any patches that bit-rot because of pgindent run
>> can be fixed with the following procedure:
>>
>> 1. check out the source tree just before pgindent.
>> 2. Apply patch
>> 3. Run pgindent
>> 4. Diff against source tree just after pgindent.
>
> Doesn't that require that all pgindent runs produce the same output?
> Which they generally don't due to different sets of typedefs and
> stuff? It's a solvable problem of course, but not quite as simple as
> you make it sound :-)

True. So everyone will have to send their patches to Bruce for bit-rot
fixing ;-)

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

--
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 18 Feb 2010 09:12
Magnus Hagander wrote:

> Doesn't that require that all pgindent runs produce the same output?
> Which they generally don't due to different sets of typedefs and
> stuff? It's a solvable problem of course, but not quite as simple as
> you make it sound :-)

The typedef file emitted by the buildfarm is supposed to be rather
static, no?

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

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

 |  Next  |  Last
Pages: 1 2 3 4 5
Prev: Streaming replication and unfit messages
Next: [HACKERS] SR: "pseudo replication database of the primary" ...