On Thu, Jul 28, 2022 at 12:41 PM Thomas Munro wrote:
> I thought about putting it at the top, but don't we really only need
> to make an extra system call if MinGW's stat() told us it saw a
> directory? And what if you asked to look through symlinks? I thought
> about putting it near the S_ISLNK
On Thu, Jul 28, 2022 at 3:21 AM Andrew Dunstan wrote:
> On 2022-07-27 We 10:58, Tom Lane wrote:
> > Andrew Dunstan writes:
> >> The alternative I thought of would be to switch msys to using our
> >> dirent.c. Probably not too hard, but certainly more work than reverting.
Thanks for figuring this
On 2022-07-27 We 10:58, Tom Lane wrote:
> Andrew Dunstan writes:
>> The alternative I thought of would be to switch msys to using our
>> dirent.c. Probably not too hard, but certainly more work than reverting.
> If you ask me, the shortest-path general-purpose fix is to insert
>
> #if MSYS
>
Andrew Dunstan writes:
> The alternative I thought of would be to switch msys to using our
> dirent.c. Probably not too hard, but certainly more work than reverting.
If you ask me, the shortest-path general-purpose fix is to insert
#if MSYS
if (pgwin32_is_junction(path))
retu
On 2022-07-27 We 10:24, Alvaro Herrera wrote:
> On 2022-Jul-27, Andrew Dunstan wrote:
>
>> The msys dirent.h doesn't have a d_type field at all in a struct dirent.
>> I can see a number of ways of dealing with this, but the simplest seems
>> to be just to revert 5344723755, at least for msys, alo
On 2022-Jul-27, Andrew Dunstan wrote:
> The msys dirent.h doesn't have a d_type field at all in a struct dirent.
> I can see a number of ways of dealing with this, but the simplest seems
> to be just to revert 5344723755, at least for msys, along with a comment
> about why it's necessary.
Hmm, wh
On 2022-07-27 We 09:47, Andrew Dunstan wrote:
> On 2022-07-26 Tu 18:31, Thomas Munro wrote:
>> On Tue, Jul 26, 2022 at 4:03 AM Andrew Dunstan wrote:
>>> On 2022-07-25 Mo 11:24, Thomas Munro wrote:
On Tue, Jul 26, 2022 at 3:08 AM Tom Lane wrote:
> Hmm ... an alternative theory is that t
On 2022-07-26 Tu 18:31, Thomas Munro wrote:
> On Tue, Jul 26, 2022 at 4:03 AM Andrew Dunstan wrote:
>> On 2022-07-25 Mo 11:24, Thomas Munro wrote:
>>> On Tue, Jul 26, 2022 at 3:08 AM Tom Lane wrote:
Hmm ... an alternative theory is that the test is fine, and what
it's telling us is th
On Tue, Jul 26, 2022 at 4:03 AM Andrew Dunstan wrote:
> On 2022-07-25 Mo 11:24, Thomas Munro wrote:
> > On Tue, Jul 26, 2022 at 3:08 AM Tom Lane wrote:
> >> Hmm ... an alternative theory is that the test is fine, and what
> >> it's telling us is that get_dirent_type() is still wrong on msys.
> >>
On Mon, Jul 25, 2022 at 11:35:12AM -0400, Tom Lane wrote:
> Noah Misch writes:
> > On Mon, Jul 25, 2022 at 09:44:21AM -0400, Andrew Dunstan wrote:
> >> Perhaps we should have a guard in system_or_bail() and/or system_log()
> >> which bails if some element of @_ is undefined.
>
> +1, seeing how ha
On 2022-07-25 Mo 11:24, Thomas Munro wrote:
> On Tue, Jul 26, 2022 at 3:08 AM Tom Lane wrote:
>> I wrote:
>>> Right, so the "glob" failed to find anything. Seeing that this test
>>> is new as of 534472375, which postdates fairywren's last successful
>>> run, I'd guess that the "glob" needs adju
Noah Misch writes:
> On Mon, Jul 25, 2022 at 09:44:21AM -0400, Andrew Dunstan wrote:
>> Perhaps we should have a guard in system_or_bail() and/or system_log()
>> which bails if some element of @_ is undefined.
+1, seeing how hard this is to diagnose.
> That would be reasonable. Also reasonable
On Tue, Jul 26, 2022 at 3:08 AM Tom Lane wrote:
> I wrote:
> > Right, so the "glob" failed to find anything. Seeing that this test
> > is new as of 534472375, which postdates fairywren's last successful
> > run, I'd guess that the "glob" needs adjustment for msys path names.
The test added by 53
On Mon, Jul 25, 2022 at 09:44:21AM -0400, Andrew Dunstan wrote:
> On 2022-07-24 Su 15:10, Noah Misch wrote:
> > On Sun, Jul 24, 2022 at 12:55:56PM -0400, Tom Lane wrote:
> >> Andrew Dunstan writes:
> >>> fairywren (msys2 animal) is currently hung in the pg_basebackup tests.
> >>> Here's the bottom
I wrote:
> Right, so the "glob" failed to find anything. Seeing that this test
> is new as of 534472375, which postdates fairywren's last successful
> run, I'd guess that the "glob" needs adjustment for msys path names.
Hmm ... an alternative theory is that the test is fine, and what
it's telling
Andrew Dunstan writes:
> On 2022-07-24 Su 15:10, Noah Misch wrote:
>> On Sun, Jul 24, 2022 at 12:55:56PM -0400, Tom Lane wrote:
>>> Andrew Dunstan writes:
fairywren (msys2 animal) is currently hung in the pg_basebackup tests.
Here's the bottom of the regress log. I don't have further in
On 2022-07-24 Su 15:10, Noah Misch wrote:
> On Sun, Jul 24, 2022 at 12:55:56PM -0400, Tom Lane wrote:
>> Andrew Dunstan writes:
>>> fairywren (msys2 animal) is currently hung in the pg_basebackup tests.
>>> Here's the bottom of the regress log. I don't have further info as yet,
>>> but can dig i
On Sun, Jul 24, 2022 at 12:55:56PM -0400, Tom Lane wrote:
> Andrew Dunstan writes:
> > fairywren (msys2 animal) is currently hung in the pg_basebackup tests.
> > Here's the bottom of the regress log. I don't have further info as yet,
> > but can dig is someone has a suggestion.
>
> Hm, what's wit
Andrew Dunstan writes:
> fairywren (msys2 animal) is currently hung in the pg_basebackup tests.
> Here's the bottom of the regress log. I don't have further info as yet,
> but can dig is someone has a suggestion.
Hm, what's with the "Use of uninitialized value" warnings?
fairywren (msys2 animal) is currently hung in the pg_basebackup tests.
Here's the bottom of the regress log. I don't have further info as yet,
but can dig is someone has a suggestion.
### Starting node "main"
# Running: pg_ctl -w -D
C:/tools/nmsys64/home/pgrunner/bf/root/REL_15_STABLE/pgsql.build
20 matches
Mail list logo
