Heikki Linnakangas writes:
> On 16.12.2010 16:50, Alvaro Herrera wrote:
>> All tuples need to have index pointers, even the dead ones.
> To be precise, tuples that are truly dead, ie. not visible to anyone
> anymore, don't need index pointers. They usually have index pointers
> anyway, because
On 16.12.2010 16:50, Alvaro Herrera wrote:
Excerpts from Ng, Stan's message of mié dic 15 21:07:57 -0300 2010:
Now I just need to get my head wrapped around the corner cases of MVCC
+ indexes. From a layman's perspective, it seems the index should only
operate on the latest version. Perhaps the
Excerpts from Ng, Stan's message of mié dic 15 21:07:57 -0300 2010:
> Now I just need to get my head wrapped around the corner cases of MVCC
> + indexes. From a layman's perspective, it seems the index should only
> operate on the latest version. Perhaps there's a pgsql configuration
> option or h
From: Mikael Krantz [mailto:m...@zigamorph.se]
Sent: Tuesday, December 14, 2010 4:36 PM
To: Ng, Stan
Cc: Craig Ringer; pgsql-bugs@postgresql.org
Subject: Re: [BUGS] index corruption on composite primary key indexes
I'm afraid that I'm a bit out of my depth when it comes to index corruption.
I
VehicleUsedICCGRadiusCache.DatasetId=t1.DatasetId and
> VehicleUsedICCGRadiusCache.PostalCode=t1.PostalCode and
> VehicleUsedICCGRadiusCache.VehicleClassGroupIdIC=t1.VehicleClassGroupIdI
> C
> where VehicleUsedICCGRadiusCache.VehicleUsedSearchRadius is null
>
>
>
> -Original Message
inger'
Cc: pgsql-bugs@postgresql.org
Subject: RE: [BUGS] index corruption on composite primary key indexes
Ah, I forgot to mention why I suspected corruption. The delta
application is a single threaded, sequential process. Each delta is done
within a single transaction. If it fails, there is r
icleClassGroupIdIC=t1.VehicleClassGroupIdI
C
where VehicleUsedICCGRadiusCache.VehicleUsedSearchRadius is null
-Original Message-
From: Craig Ringer [mailto:cr...@postnewspapers.com.au]
Sent: Tuesday, December 14, 2010 4:47 AM
To: Ng, Stan
Cc: pgsql-bugs@postgresql.org
Subject: Re: [BUGS] index cor
On 12/14/2010 10:18 AM, Ng, Stan wrote:
Some info on the platform I’m using:
Please also show your schema and query / queries. If you think it's
corruption, provide your postgresql logs too, including any mention of
the names of the suspect indexes.
Personally I agree with Mikael Krantz; y
This could quite possibly be a correct behaviour. "duplicate key value
violates unique constraint" usually happens when you try to insert a
row to a table already containing a row with the same value(s) for the
key column(s). If you have two connections both trying to insert a new
record with the s
I've noticed what appears to be index corruption on composite primary
key indexes during my testing. Data deletes, updates, and inserts are
applied from delta data that is loaded into temporary tables. The
duplicate key error occurs at different points in time and isn't
isolated to any single table
10 matches
Mail list logo
