| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Andres Freund <andres(at)2ndquadrant(dot)com> |
| Cc: | Simon Riggs <simon(at)2ndquadrant(dot)com>, Peter Geoghegan <peter(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: logical decoding - GetOldestXmin |
| Date: | 2012-12-14 19:01:30 |
| Message-ID: | CA+TgmoZRcm_mpxzup_+Ka-UmdXqjVvhpk+UmvOqe8-Bf8XOSWQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, Dec 14, 2012 at 6:46 AM, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
> Just moving that tidbit inside the lock seems to be the pragmatic
> choice. GetOldestXmin is called
>
> * once per checkpoint
> * one per index build
> * once in analyze
> * twice per vacuum
> * once for HS feedback messages
>
> Nothing of that occurs frequently enough that 5 instructions will make a
> difference. I would be happy to go an alternative path, but right now I
> don't see any nice one. A "already_locked" parameter to GetOldestXmin
> seems to be a cure worse than the disease.
I'm not sure that would be so bad, but I guess I question the need to
do it this way at all. Most of the time, if you need to advertise
your global xmin, you use GetSnapshotData(), not GetOldestXmin(), and
I guess I'm not seeing why that wouldn't also work here. Am I dumb?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2012-12-14 19:02:47 | Re: Use of systable_beginscan_ordered in event trigger patch |
| Previous Message | Tom Lane | 2012-12-14 19:00:06 | Re: Use of systable_beginscan_ordered in event trigger patch |