Julien Rouhaud writes:
> On 23/10/2015 14:59, Michael Paquier wrote:
>>> Andres Freund wrote:
FWIW, adding an <> operator for xid seems like a perfectly good
idea.
>> See for example the attached
> I just reviewed the patch, tests passed and feature works as intended.
> I change the st
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello,
On 23/10/2015 14:59, Michael Paquier wrote:
> On Fri, Oct 23, 2015 at 7:20 AM, Alvaro Herrera
> wrote:
>> Andres Freund wrote:
>>
>>> FWIW, adding an <> operator for xid seems like a perfectly good
>>> idea.
>
> +1. I have wanted that more
On Fri, Oct 23, 2015 at 7:20 AM, Alvaro Herrera
wrote:
> Andres Freund wrote:
>
>> FWIW, adding an <> operator for xid seems like a perfectly good idea.
+1. I have wanted that more than once, but avoided it all the time
with some casts.
> +1 (two of them actually --
See for example the attached
On Thu, Oct 22, 2015 at 6:57 PM, Jim Nasby wrote:
> Is there no case where it can be a permanent XID for a table or toast table?
I don't think so.
> The other issue is relminmxid, which if you're looking at relfrozenxid you'd
> want to look at as well. So you can't do a simple WHERE here.
I don
On 10/22/15 5:07 PM, Robert Haas wrote:
On Thu, Oct 22, 2015 at 5:51 PM, Jim Nasby wrote:
>It's also a permanent ID when the relation is first created.
No it isn't.
Is there no case where it can be a permanent XID for a table or toast table?
The other issue is relminmxid, which if you're lo
Andres Freund wrote:
> FWIW, adding an <> operator for xid seems like a perfectly good idea.
+1 (two of them actually -- another one for <>(xid,int) which mirrors
the =(xid,int) we already have).
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support,
On 2015-10-22 18:07:06 -0400, Robert Haas wrote:
> > BTW, ignoring relfrozenxid = 0 also isn't as easy as you'd think:
> >
> > select count(*) from pg_class where relfrozenxid <> 0;
> > ERROR: operator does not exist: xid <> integer at character 50
>
> It takes a few more characters than that, bu
On Thu, Oct 22, 2015 at 5:51 PM, Jim Nasby wrote:
> It's also a permanent ID when the relation is first created.
No it isn't. If it were, the first insert into the table would have
to update the pg_class tuple, which it certainly doesn't. Before we
had MVCC catalog scans, that wouldn't have bee
On 10/22/15 4:18 PM, Robert Haas wrote:
On Wed, Oct 21, 2015 at 1:33 PM, Jim Nasby wrote:
Currently, xid_age() returns INT_MAX for a permanent xid. The comment in the
function that 'Permanent XIDs are always infinitely old' may be technically
correct, but returning INT_MAX is a useless behavior
On Wed, Oct 21, 2015 at 1:33 PM, Jim Nasby wrote:
> Currently, xid_age() returns INT_MAX for a permanent xid. The comment in the
> function that 'Permanent XIDs are always infinitely old' may be technically
> correct, but returning INT_MAX is a useless behavior because it actually
> makes it look
Currently, xid_age() returns INT_MAX for a permanent xid. The comment in
the function that 'Permanent XIDs are always infinitely old' may be
technically correct, but returning INT_MAX is a useless behavior because
it actually makes it look like that XID is in immediate wraparound
danger. I thin
11 matches
Mail list logo
