Re: [HACKERS] pg_prepared_xact_status

2017-10-01 Thread Craig Ringer
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

Re: [HACKERS] pg_prepared_xact_status

2017-10-01 Thread Craig Ringer
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

Re: [HACKERS] pg_prepared_xact_status

2017-10-01 Thread Michael Paquier
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

Re: [HACKERS] pg_prepared_xact_status

2017-10-01 Thread Robert Haas
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.

Re: [HACKERS] pg_prepared_xact_status

2017-09-30 Thread konstantin knizhnik
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

Re: [HACKERS] pg_prepared_xact_status

2017-09-29 Thread Robert Haas
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 + >

Re: [HACKERS] pg_prepared_xact_status

2017-09-29 Thread Konstantin Knizhnik
On 29.09.2017 11:27, Craig Ringer wrote: On 29 September 2017 at 15:57, Konstantin Knizhnik > wrote: So you are saying that Postgresql 2PC mechanism is not complete and user needs to maintain some extra information to make

Re: [HACKERS] pg_prepared_xact_status

2017-09-29 Thread Craig Ringer
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

Re: [HACKERS] pg_prepared_xact_status

2017-09-29 Thread Craig Ringer
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

Re: [HACKERS] pg_prepared_xact_status

2017-09-29 Thread Konstantin Knizhnik
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

Re: [HACKERS] pg_prepared_xact_status

2017-09-28 Thread Michael Paquier
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? >

[HACKERS] pg_prepared_xact_status

2017-09-28 Thread Konstantin Knizhnik
Hi, 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 to get information about prepared transaction which are not