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 "pg_logical/snapshots/0-14F2060.s
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 used
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 ju
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 referrin
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 a
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 16d2
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: coul
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 lorike
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 wi
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 direc
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 probab
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 ?
One
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 star
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 i
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 Cygw
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 even
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() macro
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 yo
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 mo
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 pos
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 whic
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.*'
> >
> > Does
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, an
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 v3.3.4.202
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 subtle
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 o
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
> > upst
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 to
38 matches
Mail list logo
