| Lists: | pgsql-hackers |
|---|
| From: | Heikki Linnakangas <heikki(at)enterprisedb(dot)com> |
|---|---|
| To: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Phantom command ids again |
| Date: | 2007-01-29 13:30:02 |
| Message-ID: | 45BDF6DA.1000302@enterprisedb.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Lists: | pgsql-hackers |
Hi,
I was about to resubmit the phantom command ids patch for review, as I
noticed a little problem.
In fmgr.c in record_C_func, we cache the xmin and cmin, and later in
lookup_C_func we check that they match to determine if the cached
information is still valid. With phantom command ids, the cmin is not
valid outside the inserting transaction, which makes it unusable for
that purpose.
Similar caching code is used for other PL languages as well.
The best solution I've come up with this far is to use the stored
commandid, even if it's a phantom one, and a flag indicating if it's
phantom or not. Any suggestions?
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Heikki Linnakangas <heikki(at)enterprisedb(dot)com> |
| Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Phantom command ids again |
| Date: | 2007-01-29 15:42:59 |
| Message-ID: | 10721.1170085379@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Lists: | pgsql-hackers |
Heikki Linnakangas <heikki(at)enterprisedb(dot)com> writes:
> I was about to resubmit the phantom command ids patch for review, as I
> noticed a little problem.
> In fmgr.c in record_C_func, we cache the xmin and cmin, and later in
> lookup_C_func we check that they match to determine if the cached
> information is still valid. With phantom command ids, the cmin is not
> valid outside the inserting transaction, which makes it unusable for
> that purpose.
I think that actually that's just belt-and-suspenders programming;
it should be sufficient to compare tuple TID and xmin. AFAICS a single
transaction cannot fill the same TID twice, since VACUUM would never
dare remove a tuple entered by a still-in-progress transaction. So the
cmin check doesn't seem necessary.
regards, tom lane
| From: | Heikki Linnakangas <heikki(at)enterprisedb(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Phantom command ids again |
| Date: | 2007-01-29 15:53:42 |
| Message-ID: | 45BE1886.9090103@enterprisedb.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Lists: | pgsql-hackers |
Tom Lane wrote:
> Heikki Linnakangas <heikki(at)enterprisedb(dot)com> writes:
>> I was about to resubmit the phantom command ids patch for review, as I
>> noticed a little problem.
>
>> In fmgr.c in record_C_func, we cache the xmin and cmin, and later in
>> lookup_C_func we check that they match to determine if the cached
>> information is still valid. With phantom command ids, the cmin is not
>> valid outside the inserting transaction, which makes it unusable for
>> that purpose.
>
> I think that actually that's just belt-and-suspenders programming;
> it should be sufficient to compare tuple TID and xmin. AFAICS a single
> transaction cannot fill the same TID twice, since VACUUM would never
> dare remove a tuple entered by a still-in-progress transaction. So the
> cmin check doesn't seem necessary.
We don't currently use tid in the up-to-dateness check. Just Oid, xmin
and cmin. Good point, tid would work. I'll change it do that in the patch.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com