| From: | "Zeugswetter Andreas DCP SD" <ZeugswetterA(at)spardat(dot)at> |
|---|---|
| To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Greg Stark" <gsstark(at)mit(dot)edu> |
| Cc: | <pgsql-hackers(at)postgreSQL(dot)org> |
| Subject: | Re: Tricky bugs in concurrent index build |
| Date: | 2006-08-23 08:46:37 |
| Message-ID: | E1539E0ED7043848906A8FF995BDA57901410127@m0143.s-mxs.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> > Is it not possible to brute force this adding an AM method to insert
> > without the uniqueness check?
>
> Hm. Actually there already is a feature of aminsert to allow
> suppressing the unique check, but I'm not sure whether using
> it for RECENTLY_DEAD tuples helps. Seems like we have to
> wait to see whether DELETE_IN_PROGRESS deleters commit in any case.
Um, but if we wait for the DELETE_IN_PROGRESS tuple, after the wait we
can
add it eighter with or without the unique check (depending on
commit/abort).
Then at least we don't need to wait in a 3rd pass for readers ?
Andreas
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Martijn van Oosterhout | 2006-08-23 08:49:05 | Re: pg_upgrade: What is changed? |
| Previous Message | Karel Zak | 2006-08-23 08:35:09 | Re: [HACKERS] COPY view |