Hello Daniel and Michael,
02.12.2021 08:03, Michael Paquier wrote:
> On Wed, Dec 01, 2021 at 11:51:58AM +0100, Daniel Gustafsson wrote:
>> Michael, have you had a chance to look at the updated patch here? I'm moving
>> this patch entry from Waiting on Author to Needs Review.
> No, I haven't.
On Wed, Dec 01, 2021 at 11:51:58AM +0100, Daniel Gustafsson wrote:
> Michael, have you had a chance to look at the updated patch here? I'm moving
> this patch entry from Waiting on Author to Needs Review.
No, I haven't. Before being touched more, this requires first a bit
more of testing
> On 13 Jul 2021, at 20:00, Alexander Lakhin wrote:
>
> Hello Michael,
> 12.07.2021 08:52, Michael Paquier wrote:
>> On Mon, Jul 12, 2021 at 02:09:41PM +0900, Michael Paquier wrote:
>>
>>> And fairywren, that uses MinGW, is unhappy:
>>>
>>>
Hello Michael,
12.07.2021 08:52, Michael Paquier wrote:
> On Mon, Jul 12, 2021 at 02:09:41PM +0900, Michael Paquier wrote:
>> And fairywren, that uses MinGW, is unhappy:
>> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=fairywren=2021-07-12%2004%3A47%3A13
>> Looking at it now.
> I am not
12.07.2021 09:23, Michael Paquier wrote:
> On Mon, Jul 12, 2021 at 09:06:01AM +0300, Alexander Lakhin wrote:
>> I'll take care of it and will prepare mingw-compatible patch tomorrow.
> Thanks. Do you have an environment with 32b or 64b MinGW?
Yes, I have VMs with 32- and 64-bit mingw
On Mon, Jul 12, 2021 at 09:06:01AM +0300, Alexander Lakhin wrote:
> I'll take care of it and will prepare mingw-compatible patch tomorrow.
Thanks. Do you have an environment with 32b or 64b MinGW?
--
Michael
signature.asc
Description: PGP signature
Hello Michael,
12.07.2021 08:52, Michael Paquier wrote:
> On Mon, Jul 12, 2021 at 02:09:41PM +0900, Michael Paquier wrote:
>> And fairywren, that uses MinGW, is unhappy:
>> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=fairywren=2021-07-12%2004%3A47%3A13
>> Looking at it now.
> I am not
On Mon, Jul 12, 2021 at 02:09:41PM +0900, Michael Paquier wrote:
> And fairywren, that uses MinGW, is unhappy:
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=fairywren=2021-07-12%2004%3A47%3A13
> Looking at it now.
I am not sure what to do here to cool down MinGW, so the patch has
been
On Mon, Jul 12, 2021 at 01:07:17PM +0900, Michael Paquier wrote:
> Thanks, that matches my impression. There was one comment at the top
> of _pgstat64() that was still incorrect. I have spent more time
> checking and tested this stuff today, and that looks fine. One
> question pending is if we
On Fri, Jul 09, 2021 at 09:00:00PM +0300, Alexander Lakhin wrote:
> Thank you! I agree with your improvement. I can't remember why did I
> inject 'include "port.h"' in genfile.c.
> Today I've rechecked all the chain of includes and I see that stat() is
> redefined as _pgstat64() in win32_port.h,
Hello Michael,
09.07.2021 08:52, Michael Paquier wrote:
> On Thu, Jul 08, 2021 at 11:00:00PM +0300, Alexander Lakhin wrote:
>> Beside the aforementioned test I can only propose the extended patch,
>> that incorporates the undo of the changes brought by bed90759f.
>> With this patch that test is
On Thu, Jul 08, 2021 at 11:00:00PM +0300, Alexander Lakhin wrote:
> Beside the aforementioned test I can only propose the extended patch,
> that incorporates the undo of the changes brought by bed90759f.
> With this patch that test is passed.
Checked and confirmed. It is a nice test with
08.07.2021 10:47, Michael Paquier wrote:
> On Thu, Jul 08, 2021 at 07:00:01AM +0300, Alexander Lakhin wrote:
>> As Tom Lane noted above, the code added with bed90759f is dubious
>> (_NtQueryInformationFile() can not be used to handle the "delete
>> pending" state as CreateFile() returns
On Thu, Jul 08, 2021 at 07:00:01AM +0300, Alexander Lakhin wrote:
> As Tom Lane noted above, the code added with bed90759f is dubious
> (_NtQueryInformationFile() can not be used to handle the "delete
> pending" state as CreateFile() returns INVALID_HANDLE_VALUE in this case.)
> Probably that
Hello Michael,
06.07.2021 11:33, Michael Paquier wrote:
> On Sun, Mar 14, 2021 at 06:00:00PM +0300, Alexander Lakhin wrote:
>> I believe that the patch attached to [1] should fix this issue. The
>> patch still applies to master and makes the demotest (attached to [2])
>> pass. Also I've prepared
On Sun, Mar 14, 2021 at 06:00:00PM +0300, Alexander Lakhin wrote:
> I believe that the patch attached to [1] should fix this issue. The
> patch still applies to master and makes the demotest (attached to [2])
> pass. Also I've prepared a trivial patch that makes pgwin32_open() use
> the original
Hello hackers,
22.11.2020 18:59, Alexander Lakhin wrote:
> 19.11.2020 01:28, Tom Lane wrote:
>
>> Hmm, that is an interesting question isn't it. Here's a search going
>> back a full year. There are a few in v12 --- interestingly, all on
>> the statistics file, none from pg_ctl --- and none in
19.11.2020 01:28, Tom Lane wrote:
> Alexander Lakhin writes:
>> 18.11.2020 23:39, Tom Lane wrote:
>>> Now, the ones on the 10 and 11 branches are all from pg_ctl, which
>>> does not use pgwin32_open() in those branches, only native open().
>>> So those aren't fair to count against it. But we
Alexander Lakhin writes:
> 18.11.2020 23:39, Tom Lane wrote:
>> Now, the ones on the 10 and 11 branches are all from pg_ctl, which
>> does not use pgwin32_open() in those branches, only native open().
>> So those aren't fair to count against it. But we have nearly as
>> many similar failures in
Hello Tom,
18.11.2020 23:39, Tom Lane wrote:
> BTW ... scraping the buildfarm logs for "could not open ... Permission
> denied" failures suggests that pgwin32_open() isn't the pinnacle of
> perfection either. In the last three months I found these instances:
>
> dory | REL_11_STABLE |
BTW ... scraping the buildfarm logs for "could not open ... Permission
denied" failures suggests that pgwin32_open() isn't the pinnacle of
perfection either. In the last three months I found these instances:
dory | REL_11_STABLE | 2020-08-21 22:15:14 | Check | pg_ctl:
could
Alexander Lakhin writes:
> 15.11.2020 04:11, Justin Pryzby wrote:
>> Your patch introduces a "loops", but doesn't use it to escape the loop.
> Indeed, this is my mistake. Please look at the corrected patch (now that
> code corresponds to the pgwin32_open() as intended).
So what you're saying
On Sun, Nov 15, 2020 at 4:00 PM Alexander Lakhin
wrote:
> As I've found out, readdir() replacement for Windows in fact gets all
> the needed information (correct file size, attributes...) in
> WIN32_FIND_DATA, but it just leaves it inside and returns only fields of
> the dirent structure. So
15.11.2020 08:00, Alexander Lakhin wrote:
> And it rises another question, what if pg_ls_dir_files() is called for a
> directory where hundreds or thousands of files are really inaccessible
> due to restrictions?
> I mean that using CreateFile() in the modified stat() implementation can
> be
15.11.2020 04:11, Justin Pryzby wrote:
> On Sat, Nov 14, 2020 at 01:00:00PM +0300, Alexander Lakhin wrote:
>> As noted in [1], a sensible solution would be putting the same "retry on
>> ERROR_ACCESS_DENIED" action in a wrapper for stat().
>> And bed90759f brought in master the _pgstat64()
On Sat, Nov 14, 2020 at 01:00:00PM +0300, Alexander Lakhin wrote:
> As noted in [1], a sensible solution would be putting the same "retry on
> ERROR_ACCESS_DENIED" action in a wrapper for stat().
> And bed90759f brought in master the _pgstat64() function, where such
> error handling should be
Hello hackers,
After fixing bug #16161 (pg_ctl inability to open just deleted
postmaster.pid) there are still some errors related to the same
Windows-only issue.
Namely, pg_upgradeCheck failures seen on
https://buildfarm.postgresql.org/cgi-bin/show_history.pl?nm=fairywren=REL_13_STABLE
Here
27 matches
Mail list logo
