Hi
On Sat, 13 Jul 2024 at 23:01, Thomas Munro wrote:
> On Fri, Jul 12, 2024 at 3:49 AM Dave Page wrote:
> > So I received an off-list tip to checkout [1], a discussion around
> GSSAPI causing test failures on windows that Alexander Lakhin was looking
> at. Thomas Munro's v2 patch to try to addr
On Sun, Jul 14, 2024 at 10:00 AM Thomas Munro wrote:
> On Fri, Jul 12, 2024 at 3:49 AM Dave Page wrote:
> > # doesn't match '(?^:pg_dump: error: connection to server .* failed:
> > FATAL: database "qqq" does not exist)'
>
> Does it help if you revert 29992a6?
FWIW I just happened to notice
On Fri, Jul 12, 2024 at 3:49 AM Dave Page wrote:
> So I received an off-list tip to checkout [1], a discussion around GSSAPI
> causing test failures on windows that Alexander Lakhin was looking at. Thomas
> Munro's v2 patch to try to address the issue brought me down to just a single
> test fai
On Wed, 10 Jul 2024 at 10:35, Dave Page wrote:
> > The other failures I see are the following, which I'm just starting to
>>> dig
>>> > into:
>>> >
>>> > 26/298 postgresql:recovery / recovery/019_replslot_limit
>>> > ERROR43.05s exit status 2
>>> > 44/298 postgresql:re
On 2024-07-11 Th 7:29 AM, Andrew Dunstan wrote:
On 2024-07-11 Th 4:59 AM, Nazir Bilal Yavuz wrote:
Hi,
On Wed, 10 Jul 2024 at 17:04, Andrew Dunstan
wrote:
On 2024-07-10 We 9:25 AM, Tom Lane wrote:
Dave Page writes:
On Wed, 10 Jul 2024 at 12:12, Andrew Dunstan
wrote:
As I was looking
On 2024-07-11 Th 4:59 AM, Nazir Bilal Yavuz wrote:
Hi,
On Wed, 10 Jul 2024 at 17:04, Andrew Dunstan wrote:
On 2024-07-10 We 9:25 AM, Tom Lane wrote:
Dave Page writes:
On Wed, 10 Jul 2024 at 12:12, Andrew Dunstan wrote:
As I was looking at this I wondered if there might be anywhere else
Hi,
On Wed, 10 Jul 2024 at 17:04, Andrew Dunstan wrote:
>
>
> On 2024-07-10 We 9:25 AM, Tom Lane wrote:
> > Dave Page writes:
> >> On Wed, 10 Jul 2024 at 12:12, Andrew Dunstan wrote:
> >>> As I was looking at this I wondered if there might be anywhere else that
> >>> needed adjustment. One thin
On 2024-07-10 We 9:25 AM, Tom Lane wrote:
Dave Page writes:
On Wed, 10 Jul 2024 at 12:12, Andrew Dunstan wrote:
As I was looking at this I wondered if there might be anywhere else that
needed adjustment. One thing that occurred to me was that that maybe we
should replace the use of "-w" in
Dave Page writes:
> On Wed, 10 Jul 2024 at 12:12, Andrew Dunstan wrote:
>> As I was looking at this I wondered if there might be anywhere else that
>> needed adjustment. One thing that occurred to me was that that maybe we
>> should replace the use of "-w" in pg_regress.c with this rather less
>>
On Wed, 10 Jul 2024 at 12:12, Andrew Dunstan wrote:
>
> On 2024-07-09 Tu 11:34 AM, Andrew Dunstan wrote:
>
>
> On 2024-07-09 Tu 9:52 AM, Dave Page wrote:
>
>
>
>> > What I suggest (see attached) is we run the diff command with
>> > --strip-trailing-cr on Windows. Then we just won't care if the ex
On 2024-07-09 Tu 11:34 AM, Andrew Dunstan wrote:
On 2024-07-09 Tu 9:52 AM, Dave Page wrote:
> What I suggest (see attached) is we run the diff command with
> --strip-trailing-cr on Windows. Then we just won't care if the
expected file
> and/or the output file has CRs.
I
Sorry - somehow managed to send whilst pasting in logs...
On Wed, 10 Jul 2024 at 10:30, Dave Page wrote:
>
>
> On Tue, 9 Jul 2024 at 17:32, Andres Freund wrote:
>
>> Hi,
>>
>> On 2024-07-09 14:52:39 +0100, Dave Page wrote:
>> > I have 4 different diff.exe's on my ~6 week old build VM (not count
On Tue, 9 Jul 2024 at 17:32, Andres Freund wrote:
> Hi,
>
> On 2024-07-09 14:52:39 +0100, Dave Page wrote:
> > I have 4 different diff.exe's on my ~6 week old build VM (not counting
> > shims), all of which seem to support --strip-trailing-cr. Those builds
> came
> > with:
> >
> > - git
> > - VC+
Hi,
On 2024-07-09 06:26:12 -0400, Andrew Dunstan wrote:
> On 2024-07-08 Mo 5:44 PM, Andres Freund wrote:
> > > What I suggest (see attached) is we run the diff command with
> > > --strip-trailing-cr on Windows. Then we just won't care if the expected
> > > file
> > > and/or the output file has CR
Hi,
On 2024-07-09 14:52:39 +0100, Dave Page wrote:
> I have 4 different diff.exe's on my ~6 week old build VM (not counting
> shims), all of which seem to support --strip-trailing-cr. Those builds came
> with:
>
> - git
> - VC++
> - diffutils (installed by chocolatey)
> - vcpkg
>
> I think it's re
On 2024-07-09 Tu 9:52 AM, Dave Page wrote:
> What I suggest (see attached) is we run the diff command with
> --strip-trailing-cr on Windows. Then we just won't care if the
expected file
> and/or the output file has CRs.
I was wondering about that too, but I wasn't sure we
Hi
On Mon, 8 Jul 2024 at 22:44, Andres Freund wrote:
> Hi,
>
> On 2024-07-08 16:56:10 -0400, Andrew Dunstan wrote:
> > On 2024-07-08 Mo 4:16 PM, Andres Freund wrote:
> > > I'm actually mildly surprised that the tests don't fail when *not*
> using
> > > autocrlf, because afaict test_json_parser_i
On 2024-07-08 Mo 5:44 PM, Andres Freund wrote:
What I suggest (see attached) is we run the diff command with
--strip-trailing-cr on Windows. Then we just won't care if the expected file
and/or the output file has CRs.
I was wondering about that too, but I wasn't sure we can rely on that flag
be
Hi,
On 2024-07-08 16:56:10 -0400, Andrew Dunstan wrote:
> On 2024-07-08 Mo 4:16 PM, Andres Freund wrote:
> > I'm actually mildly surprised that the tests don't fail when *not* using
> > autocrlf, because afaict test_json_parser_incremental.c doesn't set stdout
> > to
> > binary and thus we presum
On 2024-07-08 Mo 4:16 PM, Andres Freund wrote:
On 2024-07-07 06:30:57 -0400, Andrew Dunstan wrote:
On 2024-07-07 Su 1:26 AM, Tom Lane wrote:
Andres Freund writes:
Do we want to support checking out with core.autocrlf?
-1. It would be a constant source of breakage, and you could never
expec
Andres Freund writes:
> On 2024-07-07 06:30:57 -0400, Andrew Dunstan wrote:
>> ISTM the right fix is probably to use PG_BINARY_R mode instead of "r" when
>> opening the files, at least in the case if the test_json_parser tests.
> That approach does seem to mildly conflict with Tom and your prefer
On 2024-07-07 06:30:57 -0400, Andrew Dunstan wrote:
>
> On 2024-07-07 Su 1:26 AM, Tom Lane wrote:
> > Andres Freund writes:
> > > Do we want to support checking out with core.autocrlf?
> > -1. It would be a constant source of breakage, and you could never
> > expect that (for example) making a t
Hi
On Sun, 7 Jul 2024 at 07:07, Andres Freund wrote:
> Hi,
>
> On 2024-07-07 01:26:13 -0400, Tom Lane wrote:
> > Andres Freund writes:
> > > Do we want to support checking out with core.autocrlf?
> >
> > -1. It would be a constant source of breakage, and you could never
> > expect that (for ex
On 2024-07-07 Su 1:26 AM, Tom Lane wrote:
Andres Freund writes:
Do we want to support checking out with core.autocrlf?
-1. It would be a constant source of breakage, and you could never
expect that (for example) making a tarball from such a checkout
would match anyone else's results.
Yea
Hi,
On 2024-07-07 01:26:13 -0400, Tom Lane wrote:
> Andres Freund writes:
> > Do we want to support checking out with core.autocrlf?
>
> -1. It would be a constant source of breakage, and you could never
> expect that (for example) making a tarball from such a checkout
> would match anyone else'
Andres Freund writes:
> Do we want to support checking out with core.autocrlf?
-1. It would be a constant source of breakage, and you could never
expect that (for example) making a tarball from such a checkout
would match anyone else's results.
> If we do not want to support that, ISTM we ought
Hi,
Git on windows defaults to core.autocrlf being enabled. Which means
that a normal git clone will convert all lineendings in text files.
Unfortunately that causes a few tests to fail, at least:
test_json_parser/001_test_json_parser_incremental
test_json_parser/003_test_semantic
pg_bsd_in
27 matches
Mail list logo
