BUG #5798: Some weird error with pl/pgsql procedure
От | Maxim Boguk |
---|---|
Тема | BUG #5798: Some weird error with pl/pgsql procedure |
Дата | |
Msg-id | 201012210248.oBL2m9sp090535@wwwmaster.postgresql.org обсуждение исходный текст |
Ответы |
Re: BUG #5798: Some weird error with pl/pgsql procedure
|
Список | pgsql-bugs |
The following bug has been logged online: Bug reference: 5798 Logged by: Maxim Boguk Email address: Maxim.Boguk@gmail.com PostgreSQL version: 8.4.4 Operating system: FreeBSD 7.2 Description: Some weird error with pl/pgsql procedure Details: While I testing my table compactor utility (http://code.google.com/p/compacttable/), I sometime getting exeptionally weird errors from pl/pgsql procedure. 2010-12-21 05:17:19 MSK 17263 postgres@hh from 192.168.1.129 [vxid:22/1898656 txid:20671567] [SELECT] ERROR: cannot extract system attribute from virtual tuple 2010-12-21 05:17:19 MSK 17263 postgres@hh from 192.168.1.129 [vxid:22/1898656 txid:20671567] [SELECT] CONTEXT: PL/pgSQL function "__clear_table_tail" line 50 at FOR over EXECUTE statement 2010-12-21 05:17:19 MSK 17263 postgres@hh from 192.168.1.129 [vxid:22/1898656 txid:20671567] [SELECT] STATEMENT: SELECT * from __clear_table_tail('vacancy_view', 'public', 'count_', 25053, 25) Now 50th line of the procedure is: --trying update all tuples in current page range FOR _new_tid IN EXECUTE 'UPDATE ONLY ' || quote_ident(arg_relnamespace) || '.' || quote_ident(arg_relname) || ' SET ' || arg_field || ' = ' || arg_field || ' WHERE ctid=ANY($1) RETURNING ctid' USING _current_tid_list LOOP This error usually happen with another error from Slony side (this error easy to understand and not an problem at all): 2010-12-21 05:15:08 MSK 24679 slony@hh from [local] [vxid:37/4336609 txid:20671079] [UPDATE] ERROR: could not serialize access due to concurrent update 2010-12-21 05:15:08 MSK 24679 slony@hh from [local] [vxid:37/4336609 txid:20671079] [UPDATE] STATEMENT: update only "public"."vacancy_view" set "count_"='1428' where "vacancy_id"='3568635'; ... I think there some strange concurrency issues with pl/pgsql and slony, and I don't understand reason of that error. This error not easy to reproduce but happens for me 3 times during tests on 130GB slave database run with my utility. Anyone can enlighten me what happens here?
В списке pgsql-bugs по дате отправления: