Re: BUG #14150: Attempted to delete invisible tuple

From: Peter Tripp <peter(at)chartio(dot)com>
To: pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #14150: Attempted to delete invisible tuple
Date: 2016-06-08 01:33:34
Message-ID: CACOLnRXL-EZ2wwdxq3=mrTL5BL21wLu5Z_KUHuMJCcVU1kPf5A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

I have also experienced this bug while using upserts. I've been able to
reproduce it with a significantly simpler table/upsert than virenda's
example.

````
CREATE TABLE IF NOT EXISTS cache (
id SERIAL,
key TEXT PRIMARY KEY NOT NULL CHECK (octet_length(key) < 256),
value JSON CHECK (octet_length(value::text) < 10 * 1024 * 1024),
expires_at TIMESTAMP NOT NULL
);
CREATE INDEX cache_expires_at_idx ON cache USING btree (expires_at);
````

From my logs:
````
2016-06-08 00:54:18 UTC:10.10.4.142(59691):user(at)dbname:[13169]:ERROR:
attempted to delete invisible tuple
2016-06-08 00:54:18 UTC:10.10.4.142(59691):user(at)dbname:[13169]:STATEMENT:
INSERT INTO cache (key, value, expires_at) VALUES ($1, $2, $3) ON CONFLICT
(key) DO UPDATE SET value=EXCLUDED.value, expires_at=EXCLUDED.expires_at
````

This was a freshly provisioned postgreSQL 9.5.2 on RDS with no imported
data. The issue appeared less than a minute after stress testing it with
insert/updates. I don't yet have a working test case, but I've only seen
it when there's quite a bit of concurrency.

-Peter

------------------------

> From: virendra(at)idyllic-software(dot)com
> To: pgsql-bugs(at)postgresql(dot)org
> Subject: BUG #14150: Attempted to delete invisible tuple
> Date: 2016-05-19 12:33:38
> Message-ID: 20160519123338(dot)12513(dot)20271(at)wrigleys(dot)postgresql(dot)org
> Thread: 2016-05-19 12:33:38 from virendra(at)idyllic-software(dot)com
>
> The following bug has been logged on the website:
>
> Bug reference: 14150
> Logged by: Viren Negi
> Email address: virendra(at)idyllic-software(dot)com
> PostgreSQL version: 9.5.2
> Operating system: Mac OS
> Description:
>
> ## We have system where we perform lot of insert and update (no delete)
and
> some time upsert query.
>
> ## Error the ruby pg library report
> PG::ObjectNotInPrerequisiteState: ERROR: attempted to delete invisible
> tuple
>
> ## Schema for call_records
> psql
> database=# \d call_records;
> Table "public.call_records"
> Column | Type |

> Modifiers
>
---------------------+-----------------------------+-----------------------------------------------------------
> id | integer | not null default
> nextval('call_records_id_seq'::regclass)
> sequence_number | character varying |
> more_data | character varying |
> acd | character varying |
> crn | character varying |
> efd | integer | default 0
> ror | character varying |
> slr | integer |
> slt | integer |
> raw_data | bytea |
> created_at | timestamp without time zone | not null
> updated_at | timestamp without time zone | not null
> crn_data | character varying |
> file_detail_id | integer |
> problems | hstore | not null default
> ''::hstore
> plain_crn | bigint |
> parsed_json | json |
> raw_processing_data | bytea |
> timestamp | bigint | default 0
> active | boolean | default true
> Indexes:
> "call_records_pkey" PRIMARY KEY, btree (id)
> "index_call_records_on_crn" UNIQUE, btree (crn)
> "index_call_records_on_plain_crn" UNIQUE, btree (plain_crn)
> "index_call_records_on_file_detail_id" btree (file_detail_id)
> Foreign-key constraints:
> "fk_rails_f25dc6ba1c" FOREIGN KEY (file_detail_id) REFERENCES
> file_details(id) ON DELETE CASCADE
> Referenced by:
> TABLE "call_processing_records" CONSTRAINT "fk_rails_2d36d7abd8"
FOREIGN
> KEY (call_record_id) REFERENCES call_records(id) ON DELETE CASCADE
>
> ## For the following insert(upsert) query
>
>
> INSERT INTO
>
call_records(plain_crn,efd,acd,slt,slr,ror,raw_processing_data,parsed_json,timestamp,active,created_at,updated_at)
> VALUES>

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Peter Geoghegan 2016-06-08 01:41:41 Re: BUG #14150: Attempted to delete invisible tuple
Previous Message Jim Nasby 2016-06-08 00:25:13 Re: [BUGS] Routine analyze of single column prevents standard autoanalyze from running at all