On Tue, 4 Jan 2022 at 16:15, Tom Lane wrote:
>
> Alvaro Herrera writes:
> > Pushed, thanks Simon for reporting this problem.
And causing another; my bad, apologies.
> Umm ...
>
>Assert(TM_WouldBlock || !(tuple->t_data->t_infomask &
> HEAP_XMAX_INVALID));
>
> AFAICS, this assertion cond
On Tue, Jan 04, 2022 at 11:15:30AM -0500, Tom Lane wrote:
> Alvaro Herrera writes:
> > Pushed, thanks Simon for reporting this problem.
>
> Umm ...
>
>Assert(TM_WouldBlock || !(tuple->t_data->t_infomask &
> HEAP_XMAX_INVALID));
>
> AFAICS, this assertion condition is constant-true,
Th
Alvaro Herrera writes:
> Pushed, thanks Simon for reporting this problem.
Umm ...
Assert(TM_WouldBlock || !(tuple->t_data->t_infomask &
HEAP_XMAX_INVALID));
AFAICS, this assertion condition is constant-true,
because TM_WouldBlock is a nonzero constant. Perhaps you meant
Assert(
On 2022-Jan-04, Alvaro Herrera wrote:
> On 2022-Jan-03, Alvaro Herrera wrote:
>
> > What I don't understand is why hasn't this been reported already: this
> > bug is pretty old. My only explanation is that nobody runs sufficiently-
> > concurrent load with SKIP LOCKED in assert-enabled builds.
>
On 2022-Jan-03, Alvaro Herrera wrote:
> What I don't understand is why hasn't this been reported already: this
> bug is pretty old. My only explanation is that nobody runs sufficiently-
> concurrent load with SKIP LOCKED in assert-enabled builds.
Pushed, thanks Simon for reporting this problem.
On 2021-Dec-01, Simon Riggs wrote:
> On Wed, 1 Dec 2021 at 14:33, Bossart, Nathan wrote:
> >
> > On 11/12/21, 8:56 AM, "Simon Riggs" wrote:
> > > The combination of these two statements in a transaction hits an
> > > Assert in heapam.c at line 4770 on REL_14_STABLE
> >
> > I've been unable to re
On Wed, 1 Dec 2021 at 14:33, Bossart, Nathan wrote:
>
> On 11/12/21, 8:56 AM, "Simon Riggs" wrote:
> > The combination of these two statements in a transaction hits an
> > Assert in heapam.c at line 4770 on REL_14_STABLE
>
> I've been unable to reproduce this. Do you have any tips for how to
> d
On 11/12/21, 8:56 AM, "Simon Riggs" wrote:
> The combination of these two statements in a transaction hits an
> Assert in heapam.c at line 4770 on REL_14_STABLE
I've been unable to reproduce this. Do you have any tips for how to
do so? Does there need to be some sort of concurrent workload?
Na
The combination of these two statements in a transaction hits an
Assert in heapam.c at line 4770 on REL_14_STABLE
BEGIN;
SELECT * FROM queue LIMIT 1 FOR UPDATE SKIP LOCKED;
...
UPDATE queue SET status = 'UPDATED' WHERE id = :id;
COMMIT;
pgbench reliably finds this, running from inside a PL/pgSQL
