Обсуждение: Re: SV: Log files polluted with permission denied error messages after every 10 seconds

Поиск
Список
Период
Сортировка

Re: SV: Log files polluted with permission denied error messages after every 10 seconds

От
Guy Burgess
Дата:
FWIW, this looks the same issue I am getting (reported last month: 
https://www.postgresql.org/message-id/f444a84e-2d29-55f9-51a6-a5dcea3bc253%40burgess.co.nz)

I get the same Process Monitor output, including BUFFER OVERFLOW 
entries.  No sign of any process other than postgres.exe touching the 
WAL files.

Regards,

Guy


On 18/03/2021 2:26 am, Andrus wrote:
>
> Hi!
>
>
>> I think what it would be most helpful to run "process monitor", so that you get
>> a log of the system calls and errors; perhaps that shows some details that
>> we cannot get from the error message.
>>
> Process monitor shows huge number of DELETE PENDING results from 
> CreateFile operation:
>
> 15:22:35,1708187    postgres.exe    11800    CreateFile C:\Program 
> Files\PostgreSQL\13\data\pg_wal\00000001000000110000003B    DELETE 
> PENDING    Desired Access: Read Attributes, Delete, Synchronize, 
> Disposition: Open, Options: Synchronous IO Non-Alert, Open Reparse 
> Point, Attributes: n/a, ShareMode: Read, Write, Delete, 
> AllocationSize: n/a
>
> 15:22:35,2713856    postgres.exe    11800    CreateFile C:\Program 
> Files\PostgreSQL\13\data\pg_wal\00000001000000110000003B DELETE 
> PENDING    Desired Access: Read Attributes, Delete, Synchronize, 
> Disposition: Open, Options: Synchronous IO Non-Alert, Open Reparse 
> Point, Attributes: n/a, ShareMode: Read, Write, Delete, 
> AllocationSize: n/a
>
> 15:22:35,3719483    postgres.exe    11800    CreateFile C:\Program 
> Files\PostgreSQL\13\data\pg_wal\00000001000000110000003B DELETE 
> PENDING    Desired Access: Read Attributes, Delete, Synchronize, 
> Disposition: Open, Options: Synchronous IO Non-Alert, Open Reparse 
> Point, Attributes: n/a, ShareMode: Read, Write, Delete, 
> AllocationSize: n/a
>
> 15:22:35,4723624    postgres.exe    11800    CreateFile C:\Program 
> Files\PostgreSQL\13\data\pg_wal\00000001000000110000003B DELETE 
> PENDING    Desired Access: Read Attributes, Delete, Synchronize, 
> Disposition: Open, Options: Synchronous IO Non-Alert, Open Reparse 
> Point, Attributes: n/a, ShareMode: Read, Write, Delete, 
> AllocationSize: n/a
>
> Andrus.
>
>



Re: SV: Log files polluted with permission denied error messages after every 10 seconds

От
Michael Paquier
Дата:
On Thu, Mar 18, 2021 at 12:25:45PM +1300, Guy Burgess wrote:
> FWIW, this looks the same issue I am getting (reported last month:
> https://www.postgresql.org/message-id/f444a84e-2d29-55f9-51a6-a5dcea3bc253%40burgess.co.nz)

Yep.

> I get the same Process Monitor output, including BUFFER OVERFLOW entries.
> No sign of any process other than postgres.exe touching the WAL files.

Guy, do you have an environment where this is still happening and
where you could test a potential fix?  We are not sure yet what's
causing that, but one code path has changed in this area, involving
CreateHardLinkA()+_unlink() instead of a single rename when attempting
to recycle a segment.  And I am just in a mood to build things by
myself and send some links to people to be able to download and test
that, so one more is fine..
--
Michael

Вложения

Re: SV: Log files polluted with permission denied error messages after every 10 seconds

От
Guy Burgess
Дата:
Thanks - yes pleas send me a private link and I will try to reproduce it 
in a test environment and then test the patch.

Regards,

Guy


On 18/03/2021 1:08 pm, Michael Paquier wrote:
> On Thu, Mar 18, 2021 at 12:25:45PM +1300, Guy Burgess wrote:
>> FWIW, this looks the same issue I am getting (reported last month:
>> https://www.postgresql.org/message-id/f444a84e-2d29-55f9-51a6-a5dcea3bc253%40burgess.co.nz)
> Yep.
>
>> I get the same Process Monitor output, including BUFFER OVERFLOW entries.
>> No sign of any process other than postgres.exe touching the WAL files.
> Guy, do you have an environment where this is still happening and
> where you could test a potential fix?  We are not sure yet what's
> causing that, but one code path has changed in this area, involving
> CreateHardLinkA()+_unlink() instead of a single rename when attempting
> to recycle a segment.  And I am just in a mood to build things by
> myself and send some links to people to be able to download and test
> that, so one more is fine..
> --
> Michael