Re: tracking commit timestamps
От | Fujii Masao |
---|---|
Тема | Re: tracking commit timestamps |
Дата | |
Msg-id | CAHGQGwHte=AXNyQ0bGLuPvRjzAc=VN=v1S1smSAw4GtwYFHpAA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: tracking commit timestamps (Alvaro Herrera <alvherre@2ndquadrant.com>) |
Список | pgsql-hackers |
On Tue, Nov 25, 2014 at 11:19 PM, Alvaro Herrera <alvherre@2ndquadrant.com> wrote: > Fujii Masao wrote: >> On Tue, Nov 25, 2014 at 7:58 AM, Alvaro Herrera >> <alvherre@2ndquadrant.com> wrote: >> >> And here is v10 which fixes conflicts with Heikki's WAL API changes (no >> >> changes otherwise). >> > >> > After some slight additional changes, here's v11, which I intend to >> > commit early tomorrow. The main change is moving the test module from >> > contrib to src/test/modules. >> >> When I specify the XID of the aborted transaction in pg_xact_commit_timestamp(), >> it always returns 2000-01-01 09:00:00+09. Is this intentional? > > Well, when a transaction has not committed, nothing is written so on > reading we get all zeroes which corresponds to the timestamp you give. > So yeah, it is intentional. We could alternatively check pg_clog and > raise an error if the transaction is not marked either COMMITTED or > SUBCOMMITTED, but I'm not real sure there's much point. > > The other option is to record a "commit" time for aborted transactions > too, but that doesn't seem very good either: first, this doesn't do > anything for crashed or for in-progress transactions; and second, how > does it make sense to have a "commit" time for a transaction that > doesn't actually commit? What about the PREPARE and COMMIT PREPARED transactions? ISTM that this feature tracks neither of them. Regards, -- Fujii Masao
В списке pgsql-hackers по дате отправления: