Re: now() vs transaction_timestamp()

Поиск
Список
Период
Сортировка
От Amit Kapila
Тема Re: now() vs transaction_timestamp()
Дата
Msg-id CAA4eK1LPVNjf-uU9=qM06ExZW-N2eO6h14ARs8rU6ShTOSRGFw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: now() vs transaction_timestamp()  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: now() vs transaction_timestamp()
Список pgsql-hackers
On Sat, Oct 6, 2018 at 2:55 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> My initial thought was that we should just re-mark transaction_timestamp()
> as parallel-restricted and call it a day, but we'd then have to do the
> same for SQLValueFunction, which is not much fun because it does have
> variants that are parallel safe (and teaching max_parallel_hazard_walker
> which is which seems like a recipe for bugs).
>
> Also, while it might not be quite too late to force a catversion bump
> in v11, this is demonstrably also broken in v10, and we can't do that
> there.
>
> So maybe the right answer is to change the parallel mode infrastructure
> so it transmits xactStartTimestamp, making transaction_timestamp()
> retroactively safe, and then in HEAD only we could re-mark now() as
> safe.  We might as well do the same for statement_timestamp as well.
>

+1.  Sounds like a reasonable way to fix the problem.  I can take care
of it (though not immediately) if you want.

-- 
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com


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

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: TAP tests for pg_verify_checksums
Следующее
От: Pavel Stehule
Дата:
Сообщение: Re: now() vs transaction_timestamp()