Hi,
On 2022-08-03 16:33:46 -0400, Robert Haas wrote:
> On Wed, Aug 3, 2022 at 1:57 PM Andres Freund wrote:
> > The reason nothing might get logged in some cases is that
> > e.g. ResolveRecoveryConflictWithLock() tells
> > ResolveRecoveryConflictWithVirtualXIDs() to *not* report the waiting:
> >
On Wed, Aug 3, 2022 at 1:57 PM Andres Freund wrote:
> The reason nothing might get logged in some cases is that
> e.g. ResolveRecoveryConflictWithLock() tells
> ResolveRecoveryConflictWithVirtualXIDs() to *not* report the waiting:
> /*
> * Prevent ResolveRecoveryCo
Hi,
On 2022-07-26 13:03:54 -0700, Andres Freund wrote:
> On 2022-07-26 14:30:30 -0400, Tom Lane wrote:
> > Andres Freund writes:
> > > On 2022-07-26 13:57:53 -0400, Tom Lane wrote:
> > >> So this is not a case of RecoveryConflictInterrupt doing the wrong thing:
> > >> the startup process hasn't d
Hi,
On 2022-07-26 14:30:30 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2022-07-26 13:57:53 -0400, Tom Lane wrote:
> >> So this is not a case of RecoveryConflictInterrupt doing the wrong thing:
> >> the startup process hasn't detected the buffer conflict in the first
> >> place.
>
> > I
Andres Freund writes:
> On 2022-07-26 13:57:53 -0400, Tom Lane wrote:
>> So this is not a case of RecoveryConflictInterrupt doing the wrong thing:
>> the startup process hasn't detected the buffer conflict in the first
>> place.
> I wonder if this, at least partially, could be be due to the elog
Hi,
On 2022-07-26 13:57:53 -0400, Tom Lane wrote:
> I happened to notice that while skink continues to fail off-and-on
> in 031_recovery_conflict.pl, the symptoms have changed! What
> we're getting now typically looks like [1]:
>
> [10:45:11.475](0.023s) ok 14 - startup deadlock: lock acquisitio
I wrote:
>> It's been kind of hidden by other buildfarm noise, but
>> 031_recovery_conflict.pl is not as stable as it should be [1][2][3][4].
> After digging around in the code, I think this is almost certainly
> some manifestation of the previously-complained-of problem [1] that
> RecoveryConflic
On Thu, Apr 28, 2022 at 5:50 AM Mark Dilger
wrote:
> psql::1: ERROR: prepared transaction with identifier "xact_012_1"
> does not exist
> [10:26:16.314](1.215s) not ok 11 - Rollback of PGPROC_MAX_CACHED_SUBXIDS+
> prepared transaction on promoted standby
> [10:26:16.314](0.000s)
> [10:26:16.314
> On Apr 27, 2022, at 6:26 PM, Andres Freund wrote:
>
> I'm a bit confused - what's the relation of that failure to this thread / the
> tests / this commit?
None, upon further reflection. It turned out to be unrelated. Sorry for the
noise.
—
Mark Dilger
EnterpriseDB: http://www.enterprise
Hi,
On 2022-04-27 14:08:45 -0400, Tom Lane wrote:
> I wrote:
> > It's been kind of hidden by other buildfarm noise, but
> > 031_recovery_conflict.pl is not as stable as it should be [1][2][3][4].
> > ...
> > I think this is showing us a real bug, ie we sometimes fail to cancel
> > the conflicting
Hi,
On 2022-04-27 10:11:53 -0700, Mark Dilger wrote:
>
>
> > On Apr 27, 2022, at 9:45 AM, Tom Lane wrote:
> >
> > [ starting a new thread cuz the shared-stats one is way too long ]
> >
> > Andres Freund writes:
> >> Add minimal tests for recovery conflict handling.
> >
> > It's been kind of
I wrote:
> It's been kind of hidden by other buildfarm noise, but
> 031_recovery_conflict.pl is not as stable as it should be [1][2][3][4].
> ...
> I think this is showing us a real bug, ie we sometimes fail to cancel
> the conflicting query.
After digging around in the code, I think this is almos
> On Apr 27, 2022, at 10:11 AM, Mark Dilger
> wrote:
>
> I'll try again on master
Still with coverage and dtrace enabled, I get the same thing, except that
master formats the logs a bit differently:
# Postmaster PID for node "primary" is 19797
psql::1: ERROR: prepared transaction with
> On Apr 27, 2022, at 9:45 AM, Tom Lane wrote:
>
> [ starting a new thread cuz the shared-stats one is way too long ]
>
> Andres Freund writes:
>> Add minimal tests for recovery conflict handling.
>
> It's been kind of hidden by other buildfarm noise, but
> 031_recovery_conflict.pl is not a
[ starting a new thread cuz the shared-stats one is way too long ]
Andres Freund writes:
> Add minimal tests for recovery conflict handling.
It's been kind of hidden by other buildfarm noise, but
031_recovery_conflict.pl is not as stable as it should be [1][2][3][4].
Three of those failures loo
15 matches
Mail list logo
