On Thu, Nov 21, 2019 at 3:35 PM Andrew Dunstan <
andrew.duns...@2ndquadrant.com> wrote:

>
> On 11/20/19 3:40 PM, Thomas Munro wrote:
> > On Fri, Nov 8, 2019 at 3:41 AM Andrew Dunstan
> > <andrew.duns...@2ndquadrant.com> wrote:
> >> On 11/7/19 9:12 AM, Alvaro Herrera wrote:
> >>>> The patch says:
> >>>>
> >>>> +        require Win32::API;
> >>>> +        Win32::API->import;
> >>> Oh, you're right, it does.  I wonder why, though:
> >>>
> >> On further inspection I think those lines are unnecessary. The remainder
> >> of the patch doesn't use this at all, AFAICT.
> > So does that mean we're back on, we can use a patch like Juan Jose's?
> > I'd love to get rid of these intermittent buildfarm failures, like
> > this one just now:
> >
> >
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=drongo&dt=2019-11-20%2010%3A00%3A10
> >
> > Here you can see:
> >
> > could not read
> "C:/prog/bf/root/HEAD/pgsql.build/src/bin/pg_ctl/tmp_check/t_004_logrotate_primary_data/pgdata/current_logfiles":
> > Permission denied at
> > C:/prog/bf/root/HEAD/pgsql.build/src/test/perl/TestLib.pm line 397.
> >
> > That line is in the subroutine slurp_file, and says open(my $in, '<',
> > $filename).  Using various clues from this thread, it seems like we
> > could, on Windows only, add code to TestLib.pm's INIT to rebind
> > *CORE::GLOBAL::open to a wrapper function that would just do
> > CreateFile(..., PLEASE_BE_MORE_LIKE_UNIX, ...).
>
>
> Possibly. I will do some testing on drongo in the next week or so.
>
>
I think Perl's open() is a bad candidate for an overload, so I will update
the previous patch that only touches slurp_file().

This version address the issues with the required libraries and uses
functions that expose less of the Windows API.

Regards,

Juan José Santamaría Flecha

Attachment: 0001-tap-file_share-windows-file-access-v2.patch
Description: Binary data

Reply via email to