On 21 December 2016 at 14:06, Jim Nasby wrote:
> On 12/20/16 10:20 PM, Craig Ringer wrote:
>>
>> Tools look at pg_class.relfrozenxid and pg_databse.datfrozenxid more
>> than probably anything else, so making changes that ignores them is
>> pretty pointless.
>
>
> Except the only useful way I know
On 12/20/16 10:20 PM, Craig Ringer wrote:
Tools look at pg_class.relfrozenxid and pg_databse.datfrozenxid more
than probably anything else, so making changes that ignores them is
pretty pointless.
Except the only useful way I know of to access *frozenxid is using
age(), and even that is a roya
On 17 December 2016 at 00:13, Robert Haas wrote:
> On Thu, Dec 15, 2016 at 3:02 AM, Craig Ringer wrote:
>> I really wish we could just change the pg_stat_activity and
>> pg_stat_replication xid fields to be epoch qualified in a 64-bit wide
>> 'fullxid' type, or similar.
>
> I think that approach
On Thu, Dec 15, 2016 at 3:02 AM, Craig Ringer wrote:
> I really wish we could just change the pg_stat_activity and
> pg_stat_replication xid fields to be epoch qualified in a 64-bit wide
> 'fullxid' type, or similar.
I think that approach is worth considering.
--
Robert Haas
EnterpriseDB: http:
Hi all
I recently had a real world case of a user confused by the
(non)relationship between txid_current()'s output and that of the xid
type, specifically pg_stat_replication.backend_xmin .
I quote:
"
> What should we look for to determine normal? I thought maybe it would
> compare to txid_curre
