| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | stark <stark(at)enterprisedb(dot)com> |
| Cc: | Greg Stark <gsstark(at)mit(dot)edu>, Hannu Krosing <hannu(at)skype(dot)net>, "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Tricky bugs in concurrent index build |
| Date: | 2006-08-23 14:09:37 |
| Message-ID: | 18833.1156342177@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
stark <stark(at)enterprisedb(dot)com> writes:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
>> [ thinks for a bit... ] At least, it seems hopeless if we use
>> SnapshotNow. Does it help if we use a real snapshot? I'm thinking
>> pass 1 inserts exactly those tuples that are good according to a
>> snap taken at its beginning, and then pass 2 considers only tuples
>> that are good according to a snap taken at *its* beginning. But
>> having consumed no caffeine yet this morning, I'm not sure I can
>> spot any flaws that might exist in this idea.
> What about tuples that are inserted and committed in the window between the
> two phases. Ie, they're RECENTLY_DEAD but not in phase2's snapshot.
We'd put them in the index but skip uniqueness check.
> Or do you mean we use SatisfiesVacuum to determine what to insert but
> SatisfiesSnapshot to determine whether to check uniqueness?
Right. The problems seem to all stem from the risk of trying to
unique-check more than one version of a tuple, and using a snap would
stop that. We need to think through all the cases though and be sure
they all work.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2006-08-23 14:12:25 | Re: Some minor changes to pgbench |
| Previous Message | Joshua D. Drake | 2006-08-23 14:09:05 | Re: Some minor changes to pgbench |