On Wed, Feb 8, 2023 at 8:06 PM Thomas Munro wrote:
> On Fri, Jan 13, 2023 at 5:17 PM Justin Pryzby wrote:
> > My patch used fsync_fname_ext() which would cause an ERROR rather than a
> > PANIC when failing to fsync the logical decoding pathname.
>
> FTR While analysing a lot of CI logs trying to
On Fri, Jan 13, 2023 at 5:17 PM Justin Pryzby wrote:
> My patch used fsync_fname_ext() which would cause an ERROR rather than a
> PANIC when failing to fsync the logical decoding pathname.
FTR While analysing a lot of CI logs trying to debug something else I
came across a plain Windows/MSVC (not
Note that cirrus failed like this:
https://api.cirrus-ci.com/v1/artifact/task/4881596411543552/testrun/build/testrun/subscription/010_truncate/log/010_truncate_publisher.log
2023-01-25 23:17:10.417 GMT [29821][walsender] [sub1][3/0:0] ERROR: could not
open file
Hi,
On 2023-01-23 17:28:14 -0600, Justin Pryzby wrote:
> On Thu, Jan 12, 2023 at 10:17:55PM -0600, Justin Pryzby wrote:
> > On Thu, Jan 12, 2023 at 06:43:54PM -0800, Andres Freund wrote:
> > > > It looks like logical decoding may be the "most wrong" place that
> > > > wal_sync_method is being
On Thu, Jan 12, 2023 at 10:17:55PM -0600, Justin Pryzby wrote:
> On Thu, Jan 12, 2023 at 06:43:54PM -0800, Andres Freund wrote:
> > > It looks like logical decoding may be the "most wrong" place that
> > > wal_sync_method is being used, so maybe my change is reasonable to
> > > consider, and not
Hi,
On 2023-01-12 22:17:55 -0600, Justin Pryzby wrote:
> On Thu, Jan 12, 2023 at 06:43:54PM -0800, Andres Freund wrote:
> > Are you actually proposing that we don't PANIC after an fsync for the
> > category
> > of files that you list here, even with data_sync_retry set?
>
> Yes, but I'm
On Thu, Jan 12, 2023 at 06:43:54PM -0800, Andres Freund wrote:
> > It looks like logical decoding may be the "most wrong" place that
> > wal_sync_method is being used, so maybe my change is reasonable to
> > consider, and not just a workaround.
>
> I don't follow. What does using fsync_fname() vs
Hi,
On 2023-01-11 22:39:49 -0600, Justin Pryzby wrote:
> Thomas raised a good question, which was how the tests were passing when
> SnapBuildSerialize() was raising an error, which is what it would've
> been doing when I used data_sync_retry=no.
Presumably some test not checking for failures in
On Wed, Jan 11, 2023 at 10:39:49PM -0600, Justin Pryzby wrote:
> Here's my latest copy of the patch.
> + # due to resource constraints we don't run this task by default for now
> + trigger_type: manual
Now, with trigger_type commented, so Thomas doesn't have to click
"trigger" for me.
>From
On Sat, Jan 07, 2023 at 12:39:11AM +1300, Thomas Munro wrote:
> On Wed, Nov 9, 2022 at 2:04 PM Justin Pryzby wrote:
> > +data_sync_retry = on
>
> Sharing with the list some clues that Justin and I figured out about
> what that part is doing. Without it, you get failures like:
>
> PANIC:
On Sat, Jan 7, 2023 at 3:40 AM Andrew Dunstan wrote:
> OK, should I now try re-enabling TAP tests on lorikeet?
Not before https://commitfest.postgresql.org/41/4032/ is committed.
After that, it might be worth a try? I have no idea if the PANIC
problem I mentioned last night would apply to
On 2023-01-05 Th 16:39, Thomas Munro wrote:
> On Fri, Jan 6, 2023 at 1:22 AM Thomas Munro wrote:
>> https://cirrus-ci.com/task/5142810819559424 [still running at time of
>> writing]
>>
>> Gotta run, but I'll check again in the morning to see if that does better...
> Yes! Two successful runs
On Wed, Nov 9, 2022 at 2:04 PM Justin Pryzby wrote:
> +data_sync_retry = on
Sharing with the list some clues that Justin and I figured out about
what that part is doing. Without it, you get failures like:
PANIC: could not open file "pg_logical/snapshots/0-14FE6B0.snap":
No such file or
On Fri, Jan 6, 2023 at 1:22 AM Thomas Munro wrote:
> https://cirrus-ci.com/task/5142810819559424 [still running at time of writing]
>
> Gotta run, but I'll check again in the morning to see if that does better...
Yes! Two successful runs with all TAP tests so far. So it looks like
we can
On Wed, Jan 4, 2023 at 3:25 AM Justin Pryzby wrote:
> On Tue, Jan 03, 2023 at 05:54:56PM +0530, vignesh C wrote:
> > Is there still some work pending for this thread as Andres had
> > committed some part, if so, can you post an updated patch for the
> > same.
>
> Thomas, what's your opinion ?
On Tue, Jan 03, 2023 at 05:54:56PM +0530, vignesh C wrote:
> > On Thu, Oct 20, 2022 at 10:40:40PM -0500, Justin Pryzby wrote:
> > > On Thu, Aug 04, 2022 at 04:16:06PM +1200, Thomas Munro wrote:
> > > > On Thu, Aug 4, 2022 at 3:38 PM Justin Pryzby
> > > > wrote:
> > > > > [train wreck]
> > > >
>
On Wed, 9 Nov 2022 at 06:34, Justin Pryzby wrote:
>
> On Thu, Oct 20, 2022 at 10:40:40PM -0500, Justin Pryzby wrote:
> > On Thu, Aug 04, 2022 at 04:16:06PM +1200, Thomas Munro wrote:
> > > On Thu, Aug 4, 2022 at 3:38 PM Justin Pryzby wrote:
> > > > [train wreck]
> > >
> > > Oh my, so I'm getting
On Fri, Jul 29, 2022 at 10:57 AM Thomas Munro wrote:
> I wonder if these problems would go away as a nice incidental
> side-effect if we used latches for postmaster wakeups. I don't
> know... maybe, if the problem is just with the postmaster's pattern of
> blocking/unblocking? Maybe backend
Hi,
On 2022-11-08 19:04:37 -0600, Justin Pryzby wrote:
> From 2741472080eceac5cb6d002c39eaf319d7f72b50 Mon Sep 17 00:00:00 2001
> From: Justin Pryzby
> Date: Fri, 30 Sep 2022 13:39:43 -0500
> Subject: [PATCH 1/3] meson: other fixes for cygwin
>
> XXX: what about HAVE_BUGGY_STRTOF ?
What about
On Thu, Oct 20, 2022 at 10:40:40PM -0500, Justin Pryzby wrote:
> On Thu, Aug 04, 2022 at 04:16:06PM +1200, Thomas Munro wrote:
> > On Thu, Aug 4, 2022 at 3:38 PM Justin Pryzby wrote:
> > > [train wreck]
> >
> > Oh my, so I'm getting the impression we might actually be totally
> > unstable on
On Thu, Aug 04, 2022 at 04:16:06PM +1200, Thomas Munro wrote:
> On Thu, Aug 4, 2022 at 3:38 PM Justin Pryzby wrote:
> > [train wreck]
>
> Oh my, so I'm getting the impression we might actually be totally
> unstable on Cygwin. Which surprises me because ... wait a minute ...
> lorikeet isn't
On Thu, Aug 4, 2022 at 5:23 PM Tom Lane wrote:
> Thomas Munro writes:
> > It may be madness to try to work around this, but I wonder if we could
> > use a static local variable that we update with atomic compare
> > exhange, inside PG_SIGNAL_HANDLER_ENTRY(), and
> > PG_SIGNAL_HANDLER_EXIT()
Thomas Munro writes:
> It may be madness to try to work around this, but I wonder if we could
> use a static local variable that we update with atomic compare
> exhange, inside PG_SIGNAL_HANDLER_ENTRY(), and
> PG_SIGNAL_HANDLER_EXIT() macros that do nothing on every other system.
> On entry, if
On Thu, Aug 4, 2022 at 4:16 PM Thomas Munro wrote:
> On Thu, Aug 4, 2022 at 3:38 PM Justin Pryzby wrote:
> > [train wreck]
>
> Oh my, so I'm getting the impression we might actually be totally
> unstable on Cygwin. Which surprises me because ... wait a minute ...
> lorikeet isn't even running
Hi,
On 2022-08-04 16:16:06 +1200, Thomas Munro wrote:
> Ok, that's slightly reassuring, so maybe we *can* fix this, but I'm
> one step closer to what Tom said, re wasting developer time...
It might be worth checking whether the cygwin installer, which at some point
at least allowed installing
On Thu, Aug 4, 2022 at 3:38 PM Justin Pryzby wrote:
> [train wreck]
Oh my, so I'm getting the impression we might actually be totally
unstable on Cygwin. Which surprises me because ... wait a minute ...
lorikeet isn't even running most of the tests. So... we don't really
know the degree to
Hi,
On 2022-07-28 17:23:19 -0500, Justin Pryzby wrote:
> On Fri, Jul 29, 2022 at 10:04:04AM +1200, Thomas Munro wrote:
> > > > XXX This should use a canned Docker image with all the right packages
> > > > installed
> > >
> > > Has anyone tried using non-canned images ? It sounds like this could
On Fri, Jul 29, 2022 at 10:04:04AM +1200, Thomas Munro wrote:
> > > XXX We would never want this to run by default in CI, but it'd be nice
> > > to be able to ask for it with ci-os-only! (See commented out line)
> > > only_if: $CIRRUS_CHANGE_MESSAGE =~ '.*\nci-os-only:[^\n]*cygwin.*'
> >
> >
On Wed, Jul 27, 2022 at 5:09 AM Robert Haas wrote:
> On Tue, Jul 26, 2022 at 7:40 AM Tom Lane wrote:
> > I think maybe we should re-open the discussion. I've certainly
> > reached the stage of fed-up-ness. That platform seems seriously
> > broken, upstream is making no progress on fixing it,
On Fri, Jul 29, 2022 at 10:23 AM Justin Pryzby wrote:
> On Fri, Jul 29, 2022 at 10:04:04AM +1200, Thomas Munro wrote:
> > [04:33:55.234] Starting cygwin install, version 2.918
>
> Hm, I think that's the version of "cygwinsetup" but not cygwin..
> It also says this: [13:16:36.014] Cygwin
On Fri, Jul 29, 2022 at 10:04:04AM +1200, Thomas Munro wrote:
> Thanks for working on this!
>
> Huh, that Cygwin being shipped by Choco is quite old, older than
> lorikeet's, but not old enough to not have the bug:
>
> [04:33:55.234] Starting cygwin install, version 2.918
Hm, I think that's the
On Wed, Jul 27, 2022 at 6:44 PM Justin Pryzby wrote:
> On Tue, Jul 26, 2022 at 04:24:25PM +1200, Thomas Munro wrote:
> > 3. You can't really run PostgreSQL on Cygwin for real, because its
> > implementation of signals does not have reliable signal masking, so
> > unsubtle and probably also
On Tue, Jul 26, 2022 at 04:24:25PM +1200, Thomas Munro wrote:
> 3. You can't really run PostgreSQL on Cygwin for real, because its
> implementation of signals does not have reliable signal masking, so
> unsubtle and probably also subtle breakage occurs. That was reported
> upstream by Noah years
On Tue, Jul 26, 2022 at 7:40 AM Tom Lane wrote:
> I think maybe we should re-open the discussion. I've certainly
> reached the stage of fed-up-ness. That platform seems seriously
> broken, upstream is making no progress on fixing it, and there
> doesn't seem to be any real-world use-case. The
Thomas Munro writes:
> On Tue, Jul 26, 2022 at 4:34 PM Tom Lane wrote:
>> If that's an accurate statement, shouldn't we just drop Cygwin support?
> This thread rejected the idea last time around:
> https://www.postgresql.org/message-id/flat/136712b0-0619-5619-4634-0f0286acaef7%402ndQuadrant.com
On Tue, Jul 26, 2022 at 4:34 PM Tom Lane wrote:
> Thomas Munro writes:
> > 3. You can't really run PostgreSQL on Cygwin for real, because its
> > implementation of signals does not have reliable signal masking, so
> > unsubtle and probably also subtle breakage occurs. That was reported
> >
Thomas Munro writes:
> 3. You can't really run PostgreSQL on Cygwin for real, because its
> implementation of signals does not have reliable signal masking, so
> unsubtle and probably also subtle breakage occurs. That was reported
> upstream by Noah years ago, but they aren't working on a fix.
Hi,
Continuing a discussion started over at [1]. Moving this to a new
thread so that other thread can focus on Unix cleanup, and both
threads can get CI coverage...
1. In a few places, it is alleged that both __CYGWIN__ and WIN32
might be defined at the same time. Do you think we should try
38 matches
Mail list logo
