Re: cheaper snapshots redux

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: cheaper snapshots redux
Дата
Msg-id CA+TgmoZsy5+4=Y2Dt1hWnpazNGQsXQAc71J=aqkmEOwTpjLeBg@mail.gmail.com
обсуждение исходный текст
Ответ на cheaper snapshots redux  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On Tue, Sep 13, 2011 at 7:49 AM, Amit Kapila <amit.kapila@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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Florian Pflug
Дата:
Сообщение: Re: Patch to improve reliability of postgresql on linux nfs
Следующее
От: "ktm@rice.edu"
Дата:
Сообщение: Re: Patch to improve reliability of postgresql on linux nfs