Skip site navigation (1) Skip section navigation (2)

Re: Dealing with CLUSTER failures

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>,PostgreSQL-patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: Dealing with CLUSTER failures
Date: 2005-05-10 00:36:28
Message-ID: 200505100036.j4A0aSB19281@candle.pha.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > I looked over this item, originally posted as:
> > 	http://archives.postgresql.org/pgsql-hackers/2005-03/msg01055.php
> 
> I still think this is substantial complication (more than likely
> introducing some bugs) to deal with a non problem.
> 
> http://archives.postgresql.org/pgsql-hackers/2005-03/msg01058.php

Well, it is a demonstrated problem, and we currently don't even report
the index name that caused the cluster to fail.

Here is a new patch that continues to throw an error for a failed
database-wide cluster (no warning) if a single table fails.  It does
print the index name and it prints a hint that the user can use ALTER
TABLE ... SET WITHOUT CLUSTER to avoid the failure:

	test=> CLUSTER  test_gist_idx ON  test;
	ERROR:  cannot cluster on index "test_gist_idx" because access method
	does not handle null values
	HINT:  You may be able to work around this by marking column "a" NOT
	NULL.
	
	test=> CLUSTER;
	ERROR:  cannot cluster on index "test_gist_idx" because access method
	does not handle null values
	HINT:  You may be able to work around this by marking column "a" NOT
	NULL, or use ALTER TABLE ... SET WITHOUT CLUSTER to remove the cluster
	specification from the table.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman(at)candle(dot)pha(dot)pa(dot)us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

In response to

pgsql-hackers by date

Next:From: Neil ConwayDate: 2005-05-10 00:37:04
Subject: Re: Inline PL/pgSQL
Previous:From: David FetterDate: 2005-05-10 00:26:35
Subject: Re: Inline PL/pgSQL

pgsql-patches by date

Next:From: Bruce MomjianDate: 2005-05-10 00:42:42
Subject: Re: Dealing with CLUSTER failures
Previous:From: Neil ConwayDate: 2005-05-10 00:16:26
Subject: Re: csv header feature regression test

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group