Re: [COMMITTERS] pgsql: Keep track of transaction commit timestamps
От | Andres Freund |
---|---|
Тема | Re: [COMMITTERS] pgsql: Keep track of transaction commit timestamps |
Дата | |
Msg-id | 20141229121410.GC16114@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: [COMMITTERS] pgsql: Keep track of transaction commit timestamps (Heikki Linnakangas <hlinnakangas@vmware.com>) |
Список | pgsql-hackers |
On 2014-12-29 12:50:23 +0200, Heikki Linnakangas wrote: > On 12/29/2014 12:39 PM, Petr Jelinek wrote: > >On 29/12/14 11:16, Andres Freund wrote: > >>On 2014-12-29 12:06:07 +0200, Heikki Linnakangas wrote: > >>>To be honest, I think this patch should be reverted. Instead, we should > >>>design a system where extensions can define their own SLRUs to store > >>>additional per-transaction information. That way, each extension can have as > >>>much space per transaction as needed, and support functions that make most > >>>sense with the information. Commit timestamp tracking would be one such > >>>extension, and for this node ID stuff, you could have another one (or > >>>include it in the replication extension). > >> > >>If somebody wants that they should develop it. But given that we, based > >>on previous discussions, don't want to run user defined code in the > >>relevant phase during transaction commit *and* replay I don't think it'd > >>be all that easy to do it fast and flexible. > > > >Right, I would love to have custom SLRUs but I don't see it happening > >given those two restrictions, otherwise I would write the CommitTs patch > >that way in the first place... > > Transaction commit and replay can treat the per-transaction information as > an opaque blob. It just needs to be included in the commit record, and > replay needs to write it to the SLRU. That way you don't need to run any > user-defined code in those phases. Meh. Only if you want to duplicate the timestamps from the commits. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: