Re: Changeset Extraction v7.9

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Changeset Extraction v7.9
Дата
Msg-id CA+TgmoaEVKeudWKAK3ZjPY3JyXEt8_OVHO+c5JJnnn0ZHL+pVg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Changeset Extraction v7.9  (Andres Freund <andres@2ndquadrant.com>)
Ответы Re: Changeset Extraction v7.9  (Andres Freund <andres@2ndquadrant.com>)
Re: Changeset Extraction v7.9.1  (Andres Freund <andres@2ndquadrant.com>)
Список pgsql-hackers
On Mon, Mar 3, 2014 at 11:26 AM, Andres Freund <andres@2ndquadrant.com> wrote:
> On 2014-02-27 17:56:08 +0100, Andres Freund wrote:
>> * do we modify struct SnapshotData to be polymorphic based on some tag
>>   or move comments there?
>
> I tried that, and it got far to invasive. So I've updated the relevant
> comment in snapshot.h, inl
>
>> * How/whether to change the exclusive lock on the ProcArrayLock in
>>   CreateInitDecodingContext()
>
> I looked at this, and I believe the current code is the best
> solution. It's pretty far away from any hot codepath and it's a short
> operation. I liked the idea about using snapmgr.c for this in principle,
> but it doesn't have enough smarts by far...
>
> So, attached is the newest version:
> * Management of historic/timetravel snapshot is now done by snapmgr.c,
>   not tqual.c anymore. No ->satisfies pointers are redirected anymore
> * removal of the "suspend" logic for historic snapshot, instead the one
>   place that needed it, now explicitly uses a snapshot
> * removal of some pointless CREATE EXTENSIONs from the regression tests
> * splitoff of the slot tests that aren't committable into a separate
>   commit.
> * minor doc adjustments
>
> I am not aware of any further things that need to be fixed now (in
> contrast to features for later releases of which there are aplenty).

OK, I've committed the 0001 patch, which is the core of this feature,
with a bit of minor additional hacking.

I'm sure there are some problems here yet and some things that people
will want fixed, as is inevitable for any patch of this size.  But I
don't have any confidence that further postponing commit is going to
be the best way to find those issues, so in it goes.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Simon Riggs
Дата:
Сообщение: Re: ALTER TABLE lock strength reduction patch is unsafe
Следующее
От: Willy-Bas Loos
Дата:
Сообщение: building pgadmin4