pg.ddx.io  pgsql-bugs@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Justin Tocci <justin@wfprod.com>
To: pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #18047: ODBC to PG long transaction causes PANIC
Date: Thu, 3 Aug 2023 09:48:03 -0500
Message-ID: <9f648db7-904d-a205-3957-e1e569dc23cd@wfprod.com> (raw)
In-Reply-To: <20230803051448.cy2ylwpjcqkgcxsb@jrouhaud>
References: <18047-02a64967c9174466@postgresql.org>
	<18047-02a64967c9174466@postgresql.org>
	<eacbf457-35b4-4bbe-5aec-423dfbc9c139@tocci.org>
	<eacbf457-35b4-4bbe-5aec-423dfbc9c139@tocci.org>
	<20230803051448.cy2ylwpjcqkgcxsb@jrouhaud>

Hi Julien!

I eventually gave up and went back to pg14. same problem, (big clue) but 
this time initdb gave me an error "could not link" and "operation not 
permitted" just before the unhelpful wal error.

I had posted the logs from the postgres server. Do you mean something 
other by 'full postgres log'? Very interested to know if I missed something.

You are correct, 'quickest way' was for a test server that was not 
stable already. Not something you would want to do in production. Thank 
you for pointing that out. I'd hate to have someone reset their wal from 
my recommendation.

Best Regards,

Justin Tocci
817-503-9545

On 8/3/2023 12:14 AM, Julien Rouhaud wrote:
> 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.





view thread (5+ messages)  latest in thread

Message-ID: <9f648db7-904d-a205-3957-e1e569dc23cd@wfprod.com>
Permalink:  ../9f648db7-904d-a205-3957-e1e569dc23cd@wfprod.com/
Also on:    postgresql.org/message-id/9f648db7-904d-a205-3957-e1e569dc23cd@wfprod.com

 · 

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-bugs@postgresql.org
  Cc: justin@wfprod.com, pgsql-bugs@lists.postgresql.org
  Subject: Re: BUG #18047: ODBC to PG long transaction causes PANIC
  In-Reply-To: <9f648db7-904d-a205-3957-e1e569dc23cd@wfprod.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox