On Sun, Oct 7, 2018 at 11:12 AM Konstantin Knizhnik
wrote:
>
> On 07.10.2018 07:58, Amit Kapila wrote:
> > On Sat, Oct 6, 2018 at 9:40 PM Tom Lane wrote:
> >> Konstantin Knizhnik writes:
> >>> On 06.10.2018 00:25, Tom Lane wrote:
> So maybe the right answer is to change the parallel mode in
Amit Kapila writes:
> On Sun, Oct 7, 2018 at 10:36 AM Tom Lane wrote:
>> That state is restored at least two transactions too late.
> That is right, but I think we can perform shm_toc_lookup for
> PARALLEL_KEY_TRANSACTION_STATE at some earlier point and then use the
> variables from it to restor
On 07.10.2018 07:58, Amit Kapila wrote:
On Sat, Oct 6, 2018 at 9:40 PM Tom Lane wrote:
Konstantin Knizhnik writes:
On 06.10.2018 00:25, Tom Lane wrote:
So maybe the right answer is to change the parallel mode infrastructure
so it transmits xactStartTimestamp, making transaction_timestamp(
On Sun, Oct 7, 2018 at 10:36 AM Tom Lane wrote:
>
> Amit Kapila writes:
> > On Sat, Oct 6, 2018 at 9:40 PM Tom Lane wrote:
> >> That's a bit too small ;-) ... one demonstrable problem with it is
> >> that the parallel worker will report the wrong xactStartTimestamp
> >> to pgstat_report_xact_tim
Amit Kapila writes:
> On Sat, Oct 6, 2018 at 9:40 PM Tom Lane wrote:
>> That's a bit too small ;-) ... one demonstrable problem with it is
>> that the parallel worker will report the wrong xactStartTimestamp
>> to pgstat_report_xact_timestamp(), since you aren't jamming the
>> transmitted value i
On Sat, Oct 6, 2018 at 9:40 PM Tom Lane wrote:
>
> Konstantin Knizhnik writes:
> > On 06.10.2018 00:25, Tom Lane wrote:
> >> So maybe the right answer is to change the parallel mode infrastructure
> >> so it transmits xactStartTimestamp, making transaction_timestamp()
> >> retroactively safe, and
Konstantin Knizhnik writes:
> On 06.10.2018 00:25, Tom Lane wrote:
>> 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 mi
On 06.10.2018 00:25, Tom Lane wrote:
I wrote:
Konstantin Knizhnik writes:
Postgres documentation says that |"now()| is a traditional PostgreSQL
equivalent to |transaction_timestamp()|".
Also both use the same implementation.
Right.
But them have different parallel safety property:
That se
so 6. 10. 2018 v 13:47 odesÃlatel Amit Kapila
napsal:
> On Sat, Oct 6, 2018 at 2:55 AM Tom Lane 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, wh
On Sat, Oct 6, 2018 at 2:55 AM Tom Lane 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 paralle
I wrote:
> So transaction_timestamp() is definitely buggy, but we're not out of the
> woods yet: SQLValueFunction is treated as parallel-safe, but it also has
> some instances that are equivalent to transaction_timestamp and so do not
> work correctly.
Oh, and I notice that timestamp_in and relate
I wrote:
> Konstantin Knizhnik writes:
>> Postgres documentation says that |"now()| is a traditional PostgreSQL
>> equivalent to |transaction_timestamp()|".
>> Also both use the same implementation.
> Right.
>> But them have different parallel safety property:
> That seems like a bug/thinko.
Konstantin Knizhnik writes:
> Postgres documentation says that |"now()| is a traditional PostgreSQL
> equivalent to |transaction_timestamp()|".
> Also both use the same implementation.
Right.
> But them have different parallel safety property:
That seems like a bug/thinko. I am not sure which
13 matches
Mail list logo
