Re: BUG #17705: Segmentation fault in BufFileLoadBuffer

From: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
To: Vahur Sinijärv <vahursi(at)icloud(dot)com>
Cc: pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #17705: Segmentation fault in BufFileLoadBuffer
Date: 2022-12-05 10:09:00
Message-ID: CA+hUKG+SpbDwW3HisWaRWPw9pT8Ci9-o4QPvd++LAD1_mWH+=A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Mon, Dec 5, 2022 at 7:24 PM Vahur Sinijärv <vahursi(at)icloud(dot)com> wrote:
> Where are these files normally created and what names do they have? We may still have them since last crash.

Something like base/pgsql_tmp/pgsql_tmp21949.19 where 21949 is a pid
(print MyProcPid in your core), and 19 is a number that keeps going
up. It may be hard to figure out which one it is though because there
should be some power of 2 number of logical spill files for a single
hash join, and then if any file exceeded 1GB it would spill into
another file (for historical reasons, 90s computers couldn't all do
large files) with hard to predict suffix, and it'd be hard to see
which ones go together. Hopefully your files didn't exceed 1GB so
hopefully you'll see a set of files all < 1GB created around the same
time, so none of them are 'continuations' that are hard to stitch
together. Then you could start from the beginning of each file and
walk tuple by tuple to see if you find the {0,0} header.

Those files get cleaned up when you restart, though.

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Nunya Business 2022-12-05 19:49:40 PG 14.5 -- Impossible to restore dump due to interaction/order of views, functions, and generated columns
Previous Message Vahur Sinijärv 2022-12-05 06:24:20 Re: BUG #17705: Segmentation fault in BufFileLoadBuffer