Re: [ADMIN] 'SGT DETAIL: Could not open file "pg_clog/05DC": No such file or directory' - what to do now?
От | Tomasz Chmielewski |
---|---|
Тема | Re: [ADMIN] 'SGT DETAIL: Could not open file "pg_clog/05DC": No such file or directory' - what to do now? |
Дата | |
Msg-id | 4DE4A652.2040301@wpkg.org обсуждение исходный текст |
Ответ на | Re: [ADMIN] 'SGT DETAIL: Could not open file "pg_clog/05DC": No such file or directory' - what to do now? (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
pgpool versus sequences (was Re: [ADMIN] 'SGT DETAIL: Could not open file "pg_clog/05DC": No such file or directory' - what to do now?)
|
Список | pgsql-hackers |
On 31.05.2011 05:16, Tom Lane wrote: > Tomasz Chmielewski<mangoo@wpkg.org> writes: >> bookstor=# SELECT 1 FROM core_wot_seq FOR UPDATE; > > Um ... why are you doing that on a sequence? > >> ERROR: could not access status of transaction 1573786613 >> DETAIL: Could not open file "pg_clog/05DC": No such file or directory. > > This doesn't surprise me too much, because sequences are not expected > to contain any live XIDs, so the XID freezing mechanism ignores them. > So if you did that in the past, this would eventually happen. > > I think the most appropriate solution may be to disallow SELECT FOR > UPDATE/SHARE on sequences ... so if you have a good reason why we > shouldn't do so, please explain it. That's a good question. I grepped the sources of the application using postgres, and it certainly doesn't do it. We use pgpool though, and I see: pool_process_query.c: snprintf(qbuf, sizeof(qbuf), "SELECT 1 FROM %s FOR UPDATE", seq_rel_name); So it looks to be coming from pgpool 3.x (it didn't do it in 2.x version). This is a message explaining why it was introduced to pgpool: http://comments.gmane.org/gmane.comp.db.postgresql.pgpool.devel/348 This brings two questions: 1) whatever command I send to postgres, should I expect "Could not open file "pg_clog/05DC": No such file or directory"? If so, it should be documented, and a way to recover from such a situation should be explained. 2) is pgpool behaviour correct? -- Tomasz Chmielewski http://wpkg.org
В списке pgsql-hackers по дате отправления: