Noah Misch writes:
> On Sat, Apr 16, 2011 at 11:17:53AM -0400, Tom Lane wrote:
>> [ squint... ] Won't that result in the rebuild failing outright? We
>> can't remove an index from the pending list till after it's rebuilt,
>> for obvious reasons.
> That would be a problem if an ambuild function w
On Sat, Apr 16, 2011 at 11:17:53AM -0400, Tom Lane wrote:
> Noah Misch writes:
> > On Fri, Apr 15, 2011 at 03:01:04PM -0400, Tom Lane wrote:
> >> What is happening is that the preceding "reindex table pg_index" set the
> >> indcheckxmin flag for pg_index's indexes. The new table built by vacuum
>
Noah Misch writes:
> On Fri, Apr 15, 2011 at 03:01:04PM -0400, Tom Lane wrote:
>> What is happening is that the preceding "reindex table pg_index" set the
>> indcheckxmin flag for pg_index's indexes. The new table built by vacuum
>> full contains no HOT chains at all, let alone broken ones, so at
On Fri, Apr 15, 2011 at 03:01:04PM -0400, Tom Lane wrote:
> What is happening is that the preceding "reindex table pg_index" set the
> indcheckxmin flag for pg_index's indexes. The new table built by vacuum
> full contains no HOT chains at all, let alone broken ones, so at the end
> of reindex_ind
Tom Lane wrote:
> "Kevin Grittner" writes:
>> can we enforce it through locks [?]
> Well, we already enforce it through the allow_system_table_mods
> mechanism:
Good enough for me.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subsc
"Kevin Grittner" writes:
> Tom Lane wrote:
>> This amounts to assuming that no new indexes get added to system
>> catalogs after initdb, or at least not during concurrent
>> operations wherein indcheckxmin would be important.
> Sounds reasonable, but can we enforce it through locks rather than
Tom Lane wrote:
> This amounts to assuming that no new indexes get added to system
> catalogs after initdb, or at least not during concurrent
> operations wherein indcheckxmin would be important.
Sounds reasonable, but can we enforce it through locks rather than
assuming, or isn't there a clea
I've been able to reproduce the syndrome reported here and here:
http://archives.postgresql.org/pgsql-performance/2011-02/msg00497.php
http://archives.postgresql.org/pgsql-general/2011-04/msg00487.php
It's a bit tricky to do it reliably, but once you get into the right
state it's reproducible. Yo
