On Tue, Sep 13, 2011 at 7:49 AM, Amit Kapila <amit.kap...@huawei.com> wrote: >>Yep, that's pretty much what it does, although xmax is actually >>defined as the XID *following* the last one that ended, and I think >>xmin needs to also be in xip, so in this case you'd actually end up >>with xmin = 15, xmax = 22, xip = { 15, 16, 17, 19 }. But you've got >>the basic idea of it. > > Shouldn't Xmax be 21 okay as current check in TupleVisibility indicate if > XID is greater than equal to Xmax then it returns tuple is not visible.
No, that's not OK. You stipulated 21 as committed, so it had better be visible. >>In particular, if someone with proc->xmin = InvalidTransactionId is >>taking a snapshot while you're computing RecentGlobalXmin, and then >>stores a proc->xmin less than your newly-computed RecentGlobalXmin, >>you've got a problem. > > I am assuming here you are reffering to take a snapshot means it has to be > updated in shared memory because otherwise no need to refer proc with your > new design. > > Session-1 > Updating RecentGlobalXmin during GetSnapshotData() using shared memory copy > of snapshot and completed transactions as RecentGlobalXmin can be updated if > we get xmin. > > Session-2 > Getting Snapshot to update in shared memory, here it needs to go through > procarray. > Now when it is going through procarray using proclock it can be case that > proc of Session-1 has InvalidTransId, so we will ignore it and go through > remaining session procs. > Now normally Session-1 proc should not get lesser xmin as compare to other > session procs but incase it has got his copy from shared memory ring buffer > before other session procs then it can be lower and which can cause a > problem. > >>> It's not one extra read - you'd have to look at every PGPROC. > > If the above explanation is right then is this the reason that to update > RecentGlobalXmin, it has to go through every PGPROC. Your explanation isn't very clear to me. But I will post the patch once I have some of these details sorted out. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers