Noah Misch writes:
> On Sun, Jun 05, 2011 at 02:17:00PM -0400, Tom Lane wrote:
>> Attached are two versions of a patch to fix this. The second one
>> modifies the code that tracks what's "pending" as per the above thought.
>> I'm not entirely sure which one I like better ... any comments?
> +1 f
On Sun, 2011-06-05 at 15:09 -0400, Tom Lane wrote:
> so once we've set the index as the currentlyReindexedIndex, there's
> no need for it still to be in pendingReindexedIndexes.
OK. The second version of the patch looks good to me.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing
On Sun, Jun 05, 2011 at 02:17:00PM -0400, Tom Lane wrote:
> I wrote:
> > Noah Misch writes:
> >> Sounds reasonable. Need to remove the index from pendingReindexedIndexes,
> >> not
> >> just call ResetReindexProcessing().
>
> > [ looks again... ] Uh, right. I was thinking that the pending list
Jeff Davis writes:
> On Sun, 2011-06-05 at 14:17 -0400, Tom Lane wrote:
>> Attached are two versions of a patch to fix this. The second one
>> modifies the code that tracks what's "pending" as per the above thought.
>> I'm not entirely sure which one I like better ... any comments?
> I think I'm
On Sun, 2011-06-05 at 14:17 -0400, Tom Lane wrote:
> Attached are two versions of a patch to fix this. The second one
> modifies the code that tracks what's "pending" as per the above thought.
> I'm not entirely sure which one I like better ... any comments?
I think I'm missing something simple:
I wrote:
> Noah Misch writes:
>> Sounds reasonable. Need to remove the index from pendingReindexedIndexes,
>> not
>> just call ResetReindexProcessing().
> [ looks again... ] Uh, right. I was thinking that the pending list was
> just "pending" and not "in progress" indexes. I wonder if we sho
Noah Misch writes:
> On Sat, Jun 04, 2011 at 05:49:31PM -0400, Tom Lane wrote:
>> So in short, I'm thinking move lines 1760-1772 (in HEAD) of index.c to
>> the end of index_build(), then insert a ResetReindexProcessing() call in
>> front of them; or maybe only do ResetReindexProcessing there if we
On Sat, Jun 04, 2011 at 05:49:31PM -0400, Tom Lane wrote:
> Noah Misch writes:
> > I could not come up with an actual wrong behavior arising from this usage,
> > so
> > I'll tentatively call it a false positive. reindex_index() could instead
> > unconditionally clear indexInfo->ii_Exclusion* bef
Noah Misch writes:
> Commit d2f60a3ab055fb61c8e1056a7c5652f1dec85e00 added an assert to indexam.c's
> RELATION_CHECKS to block use of an index while it's being rebuilt. This
> assert trips while rechecking an exclusion constraint after an ALTER TABLE
> rebuild:
> CREATE TABLE t (
>
Commit d2f60a3ab055fb61c8e1056a7c5652f1dec85e00 added an assert to indexam.c's
RELATION_CHECKS to block use of an index while it's being rebuilt. This
assert trips while rechecking an exclusion constraint after an ALTER TABLE
rebuild:
CREATE TABLE t (
c int,
10 matches
Mail list logo