On 30 September 2017 at 14:10, konstantin knizhnik <
k.knizh...@postgrespro.ru> wrote:
> So I do not see any troubles caused by adding this functions. And it can
> really be helpful for DBA in some cases.
>
If it's self-contained and exposes existing functionality, then I'm not
opposed, I just d
On 2 October 2017 at 08:09, Robert Haas wrote:
> On Sat, Sep 30, 2017 at 2:10 AM, konstantin knizhnik
> wrote:
> > txid_status() also not always be able to return status of transaction
> (if wraparound happen).
> > But it is still considered as one of the key features of 10 (transaction
> tracea
On Mon, Oct 2, 2017 at 9:09 AM, Robert Haas wrote:
> On Sat, Sep 30, 2017 at 2:10 AM, konstantin knizhnik
> wrote:
>> txid_status() also not always be able to return status of transaction (if
>> wraparound happen).
>> But it is still considered as one of the key features of 10 (transaction
>> t
On Sat, Sep 30, 2017 at 2:10 AM, konstantin knizhnik
wrote:
> txid_status() also not always be able to return status of transaction (if
> wraparound happen).
> But it is still considered as one of the key features of 10 (transaction
> traceability...).
Not by me. It's a feature, though, for su
On Sep 29, 2017, at 11:33 PM, Robert Haas wrote:
> On Fri, Sep 29, 2017 at 4:22 AM, Craig Ringer wrote:
>> This sounds kind-of like 1/4 of a distributed transaction resolver, without
>> a way to make it reliable enough to build the other 3/4.
>>
>> To make this practical I think you'd need a wa
On Fri, Sep 29, 2017 at 4:22 AM, Craig Ringer wrote:
> This sounds kind-of like 1/4 of a distributed transaction resolver, without
> a way to make it reliable enough to build the other 3/4.
>
> To make this practical I think you'd need a way to retain historic GIDs +
> their outcomes, and a way to
On 29.09.2017 11:27, Craig Ringer wrote:
On 29 September 2017 at 15:57, Konstantin Knizhnik
mailto:k.knizh...@postgrespro.ru>> wrote:
So you are saying that Postgresql 2PC mechanism is not complete
and user needs to maintain some extra information to make it work?
No, it provides wh
On 29 September 2017 at 15:57, Konstantin Knizhnik <
k.knizh...@postgrespro.ru> wrote:
> So you are saying that Postgresql 2PC mechanism is not complete and user
> needs to maintain some extra information to make it work?
>
No, it provides what's needed for an implementation of what in XA terms
On 29 September 2017 at 15:57, Konstantin Knizhnik <
k.knizh...@postgrespro.ru> wrote:
>
> The idea of pg_prepared_xact_status function is that it allows to get
> status of 2PC transaction without any additional requirements to GIDs and
> any other additional information about participants of 2PC
On 29.09.2017 06:02, Michael Paquier wrote:
On Fri, Sep 29, 2017 at 1:53 AM, Konstantin Knizhnik
wrote:
In Postgres 10 we have txid_status function which returns status of
transaction by XID.
I wonder if it will be also useful to have similar function for 2PC
transactions which can operate wi
On Fri, Sep 29, 2017 at 1:53 AM, Konstantin Knizhnik
wrote:
> In Postgres 10 we have txid_status function which returns status of
> transaction by XID.
> I wonder if it will be also useful to have similar function for 2PC
> transactions which can operate with GID?
> pg_prepared_xacts view allows t
11 matches
Mail list logo
