Re: logical decoding : exceeded maxAllocatedDescs for .spill files

From: Juan José Santamaría Flecha <juanjo(dot)santamaria(at)gmail(dot)com>
To: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
Cc: Amit Khandekar <amitdkhan(dot)pg(at)gmail(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Alvaro Herrera from 2ndQuadrant <alvherre(at)alvh(dot)no-ip(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: logical decoding : exceeded maxAllocatedDescs for .spill files
Date: 2019-11-19 12:14:22
Message-ID: CAC+AXB0_zNFUH1BrRGKUkFxvq3SxsojroJN70iTUA1gUNn_gag@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Nov 19, 2019 at 12:49 PM Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
wrote:

> On Wed, Nov 20, 2019 at 12:28 AM Amit Khandekar <amitdkhan(dot)pg(at)gmail(dot)com>
> wrote:
> > On Tue, 19 Nov 2019 at 14:07, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
> wrote:
> > > No, I got this before applying the patch. However, after applying the
> > > patch, I got below error in the same test:
> > >
> > > postgres=# SELECT 1 from
> > > pg_logical_slot_get_changes('regression_slot', NULL,NULL) LIMIT 1;
> > > ERROR: could not read from reorderbuffer spill file: Invalid argument
> > >
> > > It seems to me that FileRead API used in the patch can return value <
> > > 0 on EOF. See the API usage in BufFileLoadBuffer. I got this error
> > > on a windows machine and in the server log the message was "LOG:
> > > unrecognized win32 error code: 38" which indicates "Reached the end of
> > > the file."
> >
> > On Windows, it is documented that ReadFile() (which is called by
> > pg_pread) will return false on EOF but only when the file is open for
> > asynchronous reads/writes. But here we are just dealing with usual
> > synchronous reads. So pg_pread() code should indeed return 0 on EOF on
> > Windows. Not yet able to figure out how FileRead() managed to return
> > this error on Windows. But from your symptoms, it does look like
> > pg_pread()=>ReadFile() returned false (despite doing asynchronous
> > reads), and so _dosmaperr() gets called, and then it does not find the
> > eof error in doserrors[], so the "unrecognized win32 error code"
> > message is printed. May have to dig up more on this.
>
> Hmm. See also this report:
>
>
> https://www.postgresql.org/message-id/flat/CABuU89MfEvJE%3DWif%2BHk7SCqjSOF4rhgwJWW6aR3hjojpGqFbjQ%40mail.gmail.com
>
>
The files from pgwin32_open() are open for synchronous access, while
pg_pread() uses the asynchronous functionality to offset the read. Under
these circunstances, a read past EOF will return ERROR_HANDLE_EOF (38), as
explained in:

https://devblogs.microsoft.com/oldnewthing/20150121-00/?p=44863

Regards,

Juan José Santamaría Flecha

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2019-11-19 12:48:59 Re: Hypothetical indexes using BRIN broken since pg10
Previous Message Justin Pryzby 2019-11-19 11:57:59 checkpointer: PANIC: could not fsync file: No such file or directory