On Thu, 9 Feb 2023 at 05:43, Aleksander Alekseev
wrote:
>
> >> I don't buy your argument about DO UPDATE needing to be brought into
> >> line with DO NOTHING. In any case I'm pretty sure that Tom's remarks
> >> in 2016 about a behavioral inconsistencies (which you cited) actually
> >> called for m
Hi,
> And yet my review did figure out that your patch would have visibility
> problems, which you did end up having, as you noticed yourself downthread :)
Yep, this particular implementation turned out to be buggy.
>> I don't buy your argument about DO UPDATE needing to be brought into
>> line
Hi,
On 2023-02-09 13:06:04 +0300, Aleksander Alekseev wrote:
> > Yes, and the fact is that cmin == cmax is something that we don't normally
> > produce
>
> Not sure if this is particularly relevant to this discussion but I
> can't resist noticing that the heap doesn't even store cmin and
> cmax..
Hi,
```
=# commit;
=# SELECT xmin, xmax, cmin, cmax, * FROM t;
xmin | xmax | cmin | cmax | a | b
--+--+--+--+---+---
731 |0 |0 |0 | 1 | 0
732 | 732 |1 |1 | 2 | 0
732 | 732 |1 |1 | 3 | 0
```
Oops, you got me :) This of course isn't right - the x
Hi,
> Yes, and the fact is that cmin == cmax is something that we don't normally
> produce
Not sure if this is particularly relevant to this discussion but I
can't resist noticing that the heap doesn't even store cmin and
cmax... There is only HeapTupleHeaderData.t_cid and flags. cmin/cmax
are me
On Wed, Feb 8, 2023 at 5:08 AM Aleksander Alekseev
wrote:
> > To me it's a pretty fundamental violation of how heap visibility works.
>
> I don't think this has much to do with heap visibility. It's true that
> generally a command doesn't see its own tuples. This is done in order
> to avoid the Ha
Hi,
On 2023-02-08 16:08:39 +0300, Aleksander Alekseev wrote:
> > To me it's a pretty fundamental violation of how heap visibility works.
>
> I don't think this has much to do with heap visibility. It's true that
> generally a command doesn't see its own tuples. This is done in order
> to avoid th
Hi,
> To me it's a pretty fundamental violation of how heap visibility works.
I don't think this has much to do with heap visibility. It's true that
generally a command doesn't see its own tuples. This is done in order
to avoid the Halloween problem which however can't happen in this
particular c
Hi,
On 2023-01-26 13:07:08 +0300, Aleksander Alekseev wrote:
> > It *certainly* can't be right to just continue with the update in
> > heap_update,
>
> I see no reason why. What makes this case so different from updating a
> tuple created by the previous command?
To me it's a pretty fundamental
Hi Andres,
> It *certainly* can't be right to just continue with the update in heap_update,
I see no reason why. What makes this case so different from updating a
tuple created by the previous command?
> as you've done. You'd have to skip the update, not execute it. What am I
> missing here?
Si
Hi,
On 2023-01-25 22:00:50 +0300, Aleksander Alekseev wrote:
> Perhaps that's not a bug especially considering the fact that the
> documentation describes this behavior, but in any case the fact that:
>
> ```
> INSERT INTO t VALUES (1,1) ON CONFLICT (a) DO UPDATE SET b = 0;
> INSERT INTO t VALUES
Hi Peter,
> It also makes DO UPDATE not work the same way as either UPDATE itself
> (which will silently skip a second or subsequent update of the same
> row by the same UPDATE statement in RC mode), or MERGE (which has
> similar cardinality violations).
That's true. On the flip side, UPDATE and
On Wed, Jan 25, 2023 at 11:01 AM Aleksander Alekseev
wrote:
> Just to make sure we are on the same page. The patch doesn't break the
> current DO NOTHING behavior but rather makes DO UPDATE work the same
> way DO NOTHING does.
It also makes DO UPDATE not work the same way as either UPDATE itself
Hi Andres,
> I don't think I agree with this being a bug.
Perhaps that's not a bug especially considering the fact that the
documentation describes this behavior, but in any case the fact that:
```
INSERT INTO t VALUES (1,1) ON CONFLICT (a) DO UPDATE SET b = 0;
INSERT INTO t VALUES (1,2) ON CONF
Hi,
On 2023-01-25 18:45:12 +0300, Aleksander Alekseev wrote:
> Currently we allow self-conflicting inserts for ON CONFLICT DO NOTHING:
>
> ```
> CREATE TABLE t (a INT UNIQUE, b INT);
> INSERT INTO t VALUES (1,1), (1,2) ON CONFLICT DO NOTHING;
> -- succeeds, inserting the first row and ignoring th
15 matches
Mail list logo
