Andres Freund writes:
> I agree that it ought to be more efficent - but also about as equally
> safe? I.e. if the previous code wasn't safe, the new code wouldn't be
> safe either? As in, we're "just" avoiding the assert, but not increasing
> safety?
Well, the point is that the old code risks per
Hi,
On 2019-09-01 16:50:00 -0400, Tom Lane wrote:
> As far as 4) goes, I think the code in ExtractReplicaIdentity is pretty
> duff anyway, because it doesn't bother to check for the defined failure
> return for RelationIdGetRelation. But if we're concerned about the
> cost of recalculating this s
Amit Langote writes:
> On Mon, Sep 2, 2019 at 6:31 AM Tom Lane wrote:
>> Here's a proposed patch along those lines. It fixes Hadi's original
>> crash case and passes check-world.
> Agree that this patch would be a better solution for Hadi's report,
> although I also agree that the situation wit
On Mon, Sep 2, 2019 at 6:31 AM Tom Lane wrote:
> I wrote:
> > As far as 4) goes, I think the code in ExtractReplicaIdentity is pretty
> > duff anyway, because it doesn't bother to check for the defined failure
> > return for RelationIdGetRelation. But if we're concerned about the
> > cost of reca
I wrote:
> As far as 4) goes, I think the code in ExtractReplicaIdentity is pretty
> duff anyway, because it doesn't bother to check for the defined failure
> return for RelationIdGetRelation. But if we're concerned about the
> cost of recalculating this stuff per-row, couldn't we cache it a littl
Andres Freund writes:
> On 2019-08-17 01:43:45 -0400, Tom Lane wrote:
>> Yeah ... see the discussion leading up to 9c703c169,
>> https://www.postgresql.org/message-id/flat/19465.1541636036%40sss.pgh.pa.us
>> We didn't pull the trigger on removing the CMD_DELETE exception here,
>> but I think the h
Hi,
On 2019-08-17 01:43:45 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2019-08-16 09:44:15 -0700, Hadi Moshayedi wrote:
> >> It seems that sometimes when DELETE cascades to referencing tables we fail
> >> to acquire locks on replica identity index.
>
> > I suspect this "always" has been
Andres Freund writes:
> On 2019-08-16 09:44:15 -0700, Hadi Moshayedi wrote:
>> It seems that sometimes when DELETE cascades to referencing tables we fail
>> to acquire locks on replica identity index.
> I suspect this "always" has been broken, it's just that we previously
> didn't have checks in
Hi,
On 2019-08-16 09:44:15 -0700, Hadi Moshayedi wrote:
> It seems that sometimes when DELETE cascades to referencing tables we fail
> to acquire locks on replica identity index.
>
> To reproduce, set wal_level to logical, and run 1.sql.
>
> I can look into this, but I thought first I should sen
It seems that sometimes when DELETE cascades to referencing tables we fail
to acquire locks on replica identity index.
To reproduce, set wal_level to logical, and run 1.sql.
I can look into this, but I thought first I should send it here in case
someone who is more familiar with these related fun
10 matches
Mail list logo
