Re: BUG #18047: ODBC to PG long transaction causes PANIC

Поиск
Список
Период
Сортировка
От Julien Rouhaud
Тема Re: BUG #18047: ODBC to PG long transaction causes PANIC
Дата
Msg-id 20230803051448.cy2ylwpjcqkgcxsb@jrouhaud
обсуждение исходный текст
Ответ на BUG #18047: ODBC to PG long transaction causes PANIC  (PG Bug reporting form <noreply@postgresql.org>)
Ответы Re: BUG #18047: ODBC to PG long transaction causes PANIC  (Justin Tocci <justin@wfprod.com>)
Список pgsql-bugs
Hi,
On Thu, Aug 03, 2023 at 12:08:08AM -0500, justin tocci wrote:

> found it! had to set security.bsd.hardlink_check_gid=0 to give postgres the
> ability to create hard links.  please disregard.

Note sure how it was related, especially to the missing WAL part.  In any case
the full postgres log on the server side should give you an explanation.

> quickest way to recover is to su - postgres:
> pg_resetwal -f /opt/env.d/5434/data
> exit
> service postgresql restart 5434
>
> and we are back in business.

Just to be clear, this is *NOT* a way to recover, this is a way to irremediably
corrupt your data.

If you care about your data you should do a fresh initdb and recover from your
latest backup, or if you have no backup try to extract the data from what's
left on your current instance, with the fact that you can't assume that any
visible row is supposed to be visible and that expected rows are not there
anymore.



В списке pgsql-bugs по дате отправления:

Предыдущее
От: PG Bug reporting form
Дата:
Сообщение: BUG #18047: ODBC to PG long transaction causes PANIC
Следующее
От: PG Bug reporting form
Дата:
Сообщение: BUG #18048: Database process terminated automatically