On Tue, Aug 09, 2022 at 11:48:23AM +0200, Álvaro Herrera wrote:
> On 2022-Aug-01, Álvaro Herrera wrote:
>
> > > > If MERGE attempts an INSERT
> > > > and a unique index is present and a duplicate row is concurrently
> > > > +inserted, then a uniqueness violation error is raised;
> >
On 2022-Aug-01, Álvaro Herrera wrote:
> > > If MERGE attempts an INSERT
> > > and a unique index is present and a duplicate row is concurrently
> > > +inserted, then a uniqueness violation error is raised;
> > > +MERGE does not attempt to avoid such
> > > +errors by evaluatin
On 2022-Aug-01, Justin Pryzby wrote:
> On Tue, Jun 14, 2022 at 11:27:06AM +0200, Álvaro Herrera wrote:
> > @@ -448,9 +448,9 @@ COMMIT;
> > and execute the first one that succeeds.
> > If MERGE attempts an INSERT
> > and a unique index is present and a duplicate row is concurrently
>
On Tue, Jun 14, 2022 at 11:27:06AM +0200, Álvaro Herrera wrote:
> @@ -448,9 +448,9 @@ COMMIT;
> and execute the first one that succeeds.
> If MERGE attempts an INSERT
> and a unique index is present and a duplicate row is concurrently
> -inserted, then a uniqueness violation is r
Pushed this. I noticed that the paragraph that described MERGE in the
read-committed subsection had been put in the middle of some other paras
that describe interactions with other transactions, so I moved it up so
that it appears together with all the other paras that describe the
behavior of spe
On Wed, Jun 1, 2022, at 5:28 PM, Alvaro Herrera wrote:
> Re-reading the modified paragraph, I propose "see X for a thorough
> explanation on the behavior of MERGE under concurrency". However, in
> the proposed patch the link goes to Chapter 13 "Concurrency Control",
> and the explanation that we i
On 2022-Jun-01, Justin Pryzby wrote:
> I prefer that way, with "See also" after the text that requires more
> information. But the most important thing is to include the link at all.
But it's not a "see also". It's a link to the primary source of
concurrency information for MERGE. The text tha
On Wed, Jun 01, 2022 at 12:56:55PM +0200, Peter Eisentraut wrote:
> On 31.05.22 22:06, Justin Pryzby wrote:
> > On Wed, May 18, 2022 at 11:57:15AM -0500, Justin Pryzby wrote:
> > > I prefer my original, but the most important thing is to include the link
> > > at
> > > *somewhere*.
> >
> > Any ot
On 31.05.22 22:06, Justin Pryzby wrote:
On Wed, May 18, 2022 at 11:57:15AM -0500, Justin Pryzby wrote:
I prefer my original, but the most important thing is to include the link at
*somewhere*.
Any other opinions ?
Álvaro's patch seems ok to me. What are you concerned about? Do you
have an
On Wed, May 18, 2022 at 11:57:15AM -0500, Justin Pryzby wrote:
> I prefer my original, but the most important thing is to include the link at
> *somewhere*.
Any other opinions ?
On 2022-May-18, Tom Lane wrote:
> I don't think the committed patch will behave nicely in edge cases:
[...]
> If it's text format and total is 0, I'd wish it to print nothing,
> not to revert to the verbose format.
Oops, true. Fixed.
--
Álvaro Herrera 48°01'N 7°57'E — https://w
Alvaro Herrera writes:
> I chose the other way :-)
I don't think the committed patch will behave nicely in edge cases:
+ if (es->format == EXPLAIN_FORMAT_TEXT && total > 0)
+ {
+ ExplainIndentText(es);
+ appendStringInfoString(es->str, "Tuples:");
On Wed, May 18, 2022 at 06:42:38PM +0200, Alvaro Herrera wrote:
> On 2022-May-11, Justin Pryzby wrote:
>
> > I suggest to reference the mvcc docs from the merge docs, or to make the
> > merge
> > docs themselves include the referenced information.
> >
> > diff --git a/doc/src/sgml/ref/merge.sgml
On 2022-May-11, Justin Pryzby wrote:
> I suggest to reference the mvcc docs from the merge docs, or to make the merge
> docs themselves include the referenced information.
>
> diff --git a/doc/src/sgml/ref/merge.sgml b/doc/src/sgml/ref/merge.sgml
> index f68aa09736c..99dd5814f36 100644
> --- a/do
On 2022-May-18, Justin Pryzby wrote:
> On Wed, May 11, 2022 at 11:33:50AM -0500, Justin Pryzby wrote:
>
> > That's separate from the question about eliding zeros.
>
> Actually, the existing uses suggest that these *aren't* separate.
>
> The cases where 0 output is elided (like Heap Blocks and B
On Wed, May 11, 2022 at 11:33:50AM -0500, Justin Pryzby wrote:
> I suggest to reference the mvcc docs from the merge docs, or to make the merge
> docs themselves include the referenced information.
No comments here ?
> Also, EXPLAIN output currently looks like this:
>
> | Merge on ex_mtarget t (
On Wed, 2022-05-11 at 11:33 -0500, Justin Pryzby wrote:
> Also, EXPLAIN output currently looks like this:
>
> > Merge on ex_mtarget t (actual rows=0 loops=1)
> > Tuples Inserted: 0
> > Tuples Updated: 50
> > Tuples Deleted: 0
> > Tuples Skipped: 0
>
> Should the "zero" rows be elided from
I suggest to reference the mvcc docs from the merge docs, or to make the merge
docs themselves include the referenced information.
diff --git a/doc/src/sgml/mvcc.sgml b/doc/src/sgml/mvcc.sgml
index 341fea524a1..4446e1c484e 100644
--- a/doc/src/sgml/mvcc.sgml
+++ b/doc/src/sgml/mvcc.sgml
@@ -425,7
Em ter., 12 de abr. de 2022 às 10:47, Alvaro Herrera <
alvhe...@alvh.no-ip.org> escreveu:
> On 2022-Apr-02, Ranier Vilela wrote:
>
> > Em sáb., 2 de abr. de 2022 às 12:01, Alvaro Herrera <
> alvhe...@alvh.no-ip.org>
> > escreveu:
>
> > IMHO, actually there are bug here.
> > ExecGetChildToRootMap i
On 2022-Apr-02, Ranier Vilela wrote:
> Em sáb., 2 de abr. de 2022 às 12:01, Alvaro Herrera
> escreveu:
> IMHO, actually there are bug here.
> ExecGetChildToRootMap is clear, is possible returning NULL.
> To discover if the map is NULL, ExecGetChildToRootMap needs to process
> "ResultRelInfo *lea
Em sáb., 2 de abr. de 2022 às 12:01, Alvaro Herrera
escreveu:
> On 2022-Mar-31, Daniel Gustafsson wrote:
>
> > > On 31 Mar 2022, at 19:38, Ranier Vilela wrote:
> >
> > > I think that there is an oversight at 7103ebb
> > > There is no chance of Assert preventing this bug.
> >
> > This seems reaso
Hi,
On 2022-04-02 17:02:01 +0200, Alvaro Herrera wrote:
> There's no bug here and this is actually intentional: if the map is
> NULL, this function should not be called.
This made me, again, wonder if we should add a pg_nonnull attibute to c.h. The
compiler can probably figure it out in this case
On 2022-Mar-31, Daniel Gustafsson wrote:
> > On 31 Mar 2022, at 19:38, Ranier Vilela wrote:
>
> > I think that there is an oversight at 7103ebb
> > There is no chance of Assert preventing this bug.
>
> This seems reasonable from brief reading of the code, NULL is a legitimate
> value for the ma
> On 31 Mar 2022, at 19:38, Ranier Vilela wrote:
> I think that there is an oversight at 7103ebb
> There is no chance of Assert preventing this bug.
This seems reasonable from brief reading of the code, NULL is a legitimate
value for the map and that should yield an empty list AFAICT.
--
Daniel
On 2022-Mar-28, Alvaro Herrera wrote:
> I intend to get this pushed after lunch.
Pushed, with one more change: fetching the tuple ID junk attribute in
ExecMerge was not necessary, since we already had done that in
ExecModifyTable. We just needed to pass that down to ExecMerge, and
make sure to h
On 2022-Mar-10, Simon Riggs wrote:
> Duplicate rows should produce a uniqueness violation error in one of
> the transactions, assuming there is a constraint to define the
> conflict. Without such a constraint there is no conflict.
>
> Concurrent inserts are checked by merge-insert-update.spec, wh
On 17.03.22 12:31, Alvaro Herrera wrote:
0001 pushed. Here's 0002 again for cfbot, with no changes other than
pgindent cleanup.
I did a cursory read through and want to offer some trivial amendments
in the attached patches. The 0001 adds back various serial commas, the
0002 is assorted othe
On 2022-Mar-17, Alvaro Herrera wrote:
> I'll see what to do about Instrumentation->nfiltered{1,2,3} that was
> complained about by Andres upthread. Maybe some additional macros will
> help.
This turns out not to be as simple as I expected, mostly because we want
to keep Instrumentation as a node
On Thu, 17 Mar 2022 at 03:18, Alvaro Herrera wrote:
> v16.
> On 2022-Mar-14, Japin Li wrote:
>
>> + ar_delete_trig_tcs = mtstate->mt_transition_capture;
>> + if (mtstate->operation == CMD_UPDATE &&
>> mtstate->mt_transition_capture &&
>> + mtstate->mt_transition_captur
On Mon, Mar 14, 2022 at 11:36 PM Amit Langote wrote:
> On Sun, Mar 13, 2022 at 12:36 AM Alvaro Herrera
> wrote:
> > FYI I intend to get the ModifyTable split patch (0001+0003) pushed
> > hopefully on Tuesday or Wednesday next week, unless something really
> > ugly is found on it.
>
> I looked at
On Sat, 12 Mar 2022 at 11:53, Alvaro Herrera wrote:
> On 2022-Mar-09, Zhihong Yu wrote:
>
>> Hi,
>> For v14-0002-Split-ExecUpdate-and-ExecDelete-in-reusable-piec.patch :
>>
>> + TupleTableSlot *insertProjectedTuple;
>>
>> With `insert` at the beginning of the variable name, someone may think i
On Sun, Mar 13, 2022 at 12:36 AM Alvaro Herrera wrote:
> FYI I intend to get the ModifyTable split patch (0001+0003) pushed
> hopefully on Tuesday or Wednesday next week, unless something really
> ugly is found on it.
I looked at 0001 and found a few things that could perhaps be improved.
+ /*
On Sat, Jan 29, 2022 at 12:03:35AM -0600, Justin Pryzby wrote:
> Note that MergeWhenClause and MergeAction have the node definition in a
> different order than the header, which is a bit confusing.
The .h files still order these fields differently than the other .h files, and
then the node funcs (
FYI I intend to get the ModifyTable split patch (0001+0003) pushed
hopefully on Tuesday or Wednesday next week, unless something really
ugly is found on it.
As for MERGE proper, I'm aiming at getting that one pushed on the week
starting March 21st, though of course I'll spend some more time on it
On Sun, 27 Feb 2022 at 17:35, Alvaro Herrera wrote:
> > > + /*
> > > +* Project the tuple. In case of a
> > > partitioned table, the
> > > +* projection was already built to use the
> > > root's descriptor,
> > >
On Wed, Mar 9, 2022 at 9:38 AM Alvaro Herrera
wrote:
> I attach MERGE v14. This includes a fix from Amit Langote for the
> problem I described previously, with EvalPlanQual not working correctly.
> (I had failed to short-circuit the cross-partition update correctly.)
> Now the test case is enabl
On 2022-Mar-07, Zhihong Yu wrote:
> For v13-0003-MERGE-SQL-Command-following-SQL-2016.patch :
>
> +* Reset per-tuple memory context to free any expression evaluation
> +* storage allocated in the previous cycle.
> +*/
> + ResetExprContext(econtext);
>
> Why is the memory cleanup do
On Mon, Mar 7, 2022 at 12:04 PM Álvaro Herrera
wrote:
> On Mon, Mar 7, 2022, at 4:59 PM, Álvaro Herrera wrote:
>
> I attach v13 here. This version includes a 0002 that's does the split of
> nodeModifyTable.c routines, then 0003 implements MERGE on top of that.
> 0001 is as before.
>
>
> In 0002,
On Mon, Mar 7, 2022, at 4:59 PM, Álvaro Herrera wrote:
> I attach v13 here. This version includes a 0002 that's does the split of
> nodeModifyTable.c routines, then 0003 implements MERGE on top of that. 0001
> is as before.
In 0002, I've opted to have two separate structs. One is the
ModifyT
On Sun, Feb 27, 2022 at 09:17:13PM +0100, Daniel Gustafsson wrote:
> > On 27 Feb 2022, at 18:42, Tom Lane wrote:
>
> > I'd rather keep all the ModifyTable code in one .c file, even if that one is
> > bigger than our usual practice.
>
> Agreed, I also prefer a (too) large file over a set of .c #i
> On 27 Feb 2022, at 18:42, Tom Lane wrote:
> I'd rather keep all the ModifyTable code in one .c file, even if that one is
> bigger than our usual practice.
Agreed, I also prefer a (too) large file over a set of .c #include's.
--
Daniel Gustafsson https://vmware.com/
On Sun, Feb 27, 2022 at 9:25 AM Alvaro Herrera
wrote:
> I attach v12 of MERGE. Significant effort went into splitting
> ExecUpdate and ExecDelete into parts that can be reused from the MERGE
> routines in a way that doesn't involve jumping out in the middle of
> TM_Result processing to merge-spe
Alvaro Herrera writes:
> I think we should make a decision on code arrangement here. From my
> perspective, MERGE isn't its own executor node; rather it's just another
> "method" in ModifyTable. Which makes sense, given that all it does is
> call parts of INSERT, UPDATE, DELETE which are the oth
On 2022-Jan-28, Andres Freund wrote:
> Any chance you could split this into something more reviewable? The overall
> diff stats are: 102 files changed, 8589 insertions(+), 234 deletions(-) thats
> pretty hard to really review. Incremental commits don't realy help with that.
I'll work on splitting
On Fri, Feb 11, 2022 at 05:25:49PM -0300, Alvaro Herrera wrote:
> > I'm not sure git diff --cherry-pick is widely known/used, but I think
> > using that relative to master may be good enough.
>
> I had never heard of git diff --cherry-pick, and the manpages I found
> don't document it, so frankl
On 2022-Feb-11, Justin Pryzby wrote:
> Because I put your patch on top of some other branch with the CI coverage (and
> other stuff).
Ah, that makes sense.
> But it has to figure out where the branch "starts". Which I did by looking at
> "git diff --cherry-pick origin..."
>
> I'm not sure git d
On Fri, Feb 11, 2022 at 03:21:43PM -0300, Alvaro Herrera wrote:
> On 2022-Jan-28, Justin Pryzby wrote:
> > Have you looked at code coverage ? I have an experimental patch to add
> > that to
> > cirrus, and ran it with this patch; visible here:
> > https://cirrus-ci.com/task/6362512059793408
>
>
On 2022-Jan-28, Justin Pryzby wrote:
> Have you looked at code coverage ? I have an experimental patch to add that
> to
> cirrus, and ran it with this patch; visible here:
> https://cirrus-ci.com/task/6362512059793408
Ah, thanks, this is useful. I think it is showing that the new code is
gener
Op 28-01-2022 om 21:27 schreef Alvaro Herrera:
MERGE, v10. I am much more comfortable with this version; I have
removed a bunch of temporary hacks and cleaned up the interactions with
table AM and executor, which is something that had been bothering me for
a while. The complete set of changes c
On Fri, Jan 28, 2022 at 05:27:37PM -0300, Alvaro Herrera wrote:
> The one thing I'm a bit bothered about is the fact
> that we expose a lot of executor functions previously static. I am now
> wondering if it would be better to move the MERGE executor support
> functions into nodeModifyTable.c, whi
On Fri, Jan 28, 2022 at 2:19 PM Andres Freund wrote:
> Hi,
>
> On 2022-01-28 17:27:37 -0300, Alvaro Herrera wrote:
> > MERGE, v10. I am much more comfortable with this version; I have
> > removed a bunch of temporary hacks and cleaned up the interactions with
> > table AM and executor, which is
Hi,
On 2022-01-28 17:27:37 -0300, Alvaro Herrera wrote:
> MERGE, v10. I am much more comfortable with this version; I have
> removed a bunch of temporary hacks and cleaned up the interactions with
> table AM and executor, which is something that had been bothering me for
> a while. The complete
On 2022-Jan-21, Japin Li wrote:
> + /*
> +* NOT MATCHED actions can't see target relation, but they
> can see
> +* source relation.
> +*/
> + Assert(mergeWhenClause->commandType == CMD_INSERT ||
> +
On Fri, 21 Jan 2022 at 05:06, Alvaro Herrera wrote:
> Here's v8 of this patch. I have fixed the problems pointed out by Jaime
> and Erik, as well as incorporated Zhihong, Erik and Justin's
> documentation fixes (typos and otherwise).
>
> Not yet included: a fix for Peter's suggestion to raise a
On 2022-Jan-12, Jaime Casanova wrote:
> I found two crashes, actually I found them on the original patch Álvaro
> sent on november but just checked that those already exists.
>
> I configured with:
>
> CFLAGS="-ggdb -Og -g3 -fno-omit-frame-pointer" ./configure
> --prefix=/opt/var/pgdg/15/merge
On 2022-Jan-17, Japin Li wrote:
> So for NOT MATCHED, we are expected not use the target table columns.
>
> The code comes from execMerge.c says:
>
> /*
> * Make source tuple available to ExecQual and ExecProject. We don't need
> * the target tuple, since the WHEN quals and the tar
On 13.01.22 13:43, Alvaro Herrera wrote:
Apologies, there was a merge failure and I failed to notice. Here's the
correct patch.
I looked through this a bit. I wonder why there is a check for
"unreachable WHEN clause". I don't see this in the SQL standard.
On the other hand, there is a req
Resending some language fixes to the public documentation.
>From 28b8532976ddb3e8b617ca007fae6b4822b36527 Mon Sep 17 00:00:00 2001
From: Justin Pryzby
Date: Sat, 13 Nov 2021 12:11:46 -0600
Subject: [PATCH] f!typos
---
doc/src/sgml/mvcc.sgml | 8 ++---
doc/src/sgml/ref/create_policy
Op 13-01-2022 om 13:43 schreef Alvaro Herrera:
Apologies, there was a merge failure and I failed to notice. Here's the
correct patch.
(This is also in github.com/alvherre/postgres/tree/merge-15)
[v6-0001-MERGE-SQL-Command-following-SQL-2016]
I read though the MERGE-docs; some typos:
'F
Op 13-01-2022 om 13:43 schreef Alvaro Herrera:
Apologies, there was a merge failure and I failed to notice. Here's the
correct patch.
(This is also in github.com/alvherre/postgres/tree/merge-15)
[20220113/v6-0001-MERGE-SQL-Command-following-SQL-2016.patch]
Good morning,
I got into this c
On Thu, Jan 13, 2022 at 4:43 AM Alvaro Herrera
wrote:
> Apologies, there was a merge failure and I failed to notice. Here's the
> correct patch.
>
> (This is also in github.com/alvherre/postgres/tree/merge-15)
>
> Hi,
For v6-0001-MERGE-SQL-Command-following-SQL-2016.patch :
+* Either we wer
On 1/5/22 02:53, Simon Riggs wrote:
> On Wed, 22 Dec 2021 at 11:35, Simon Riggs
> wrote:
>> On Mon, 15 Nov 2021 at 22:45, Alvaro Herrera wrote:
>>> On 2021-Nov-15, Alvaro Herrera wrote:
>>>
Thanks everyone for the feedback. I attach a version with the fixes
that were submitted, as w
On Wed, Dec 22, 2021 at 11:35:56AM +, Simon Riggs wrote:
> On Mon, 15 Nov 2021 at 22:45, Alvaro Herrera wrote:
> >
> > On 2021-Nov-15, Alvaro Herrera wrote:
> >
> > > Thanks everyone for the feedback. I attach a version with the fixes
> > > that were submitted, as well as some additional chan
On Wed, 22 Dec 2021 at 11:35, Simon Riggs wrote:
>
> On Mon, 15 Nov 2021 at 22:45, Alvaro Herrera wrote:
> >
> > On 2021-Nov-15, Alvaro Herrera wrote:
> >
> > > Thanks everyone for the feedback. I attach a version with the fixes
> > > that were submitted, as well as some additional changes:
> >
Hi Amit
On 2021-Nov-16, Amit Langote wrote:
> AFAICS, MERGE operating on an inheritance parent that is not
> partitioned should work mostly the same as the case where it is
> partitioned (good thing that it works at all without needing any
> special code!), though only the INSERT actions would ha
Hi Álvaro,
On Tue, Nov 16, 2021 at 6:01 AM Álvaro Herrera wrote:
> On 2021-Nov-14, Amit Langote wrote:
> > The only problem caused by the code block that follows the buggy if
> > statement unconditionally executing is wasted cycles. Fortunately,
> > there's no correctness issue, because rootRelI
Thanks everyone for the feedback. I attach a version with the fixes
that were submitted, as well as some additional changes:
- I removed the restriction for tables inheritance and added the sample
I showed to regression.
- I added DO NOTHING support to the WHERE MATCHED case; it previously
o
On 2021-Nov-14, Amit Langote wrote:
> The only problem caused by the code block that follows the buggy if
> statement unconditionally executing is wasted cycles. Fortunately,
> there's no correctness issue, because rootRelInfo is the same as the
> input result relation in the cases where the latt
On Sun, Nov 14, 2021 at 12:23 AM Álvaro Herrera wrote:
> On 2021-Nov-13, Daniel Westermann wrote:
> > /usr/bin/clang -Wno-ignored-attributes -fno-strict-aliasing -fwrapv -O2
> > -I../../../src/include -D_GNU_SOURCE -I/usr/include/libxml2 -flto=thin
> > -emit-llvm -c -o execMerge.bc execMerge.
On Fri, Nov 12, 2021 at 02:57:57PM -0300, Alvaro Herrera wrote:
> Here's a new version. Many of the old complaints have been fixed;
I should've replied to this newer message.
I also read through the code a bit and have some more language fixes, mostly.
I ran sqlsmith for a few hours with no app
On Thu, Dec 31, 2020 at 10:47:36AM -0300, Alvaro Herrera wrote:
> Here's a rebase of Simon/Pavan's MERGE patch to current sources. I
> cleaned up some minor things in it, but aside from rebasing, it's pretty
> much their work (even the commit message is Simon's).
>
> Adding to commitfest.
I revi
On Sat, Nov 13, 2021 at 7:41 AM Alvaro Herrera
wrote:
> On 2021-Nov-12, Zhihong Yu wrote:
>
> > +lmerge_matched:
> > ...
> > + foreach(l, resultRelInfo->ri_matchedMergeAction)
> >
> > I suggest expanding the foreach macro into the form of for loop where the
> > loop condition has extra boolean
On 2021-Nov-12, Zhihong Yu wrote:
> +lmerge_matched:
> ...
> + foreach(l, resultRelInfo->ri_matchedMergeAction)
>
> I suggest expanding the foreach macro into the form of for loop where the
> loop condition has extra boolean variable merge_matched.
> Initial value for merge_matched can be true.
On 2021-Nov-12, Zhihong Yu wrote:
> This is continuation of review.
>
> + elog(WARNING, "hoping nothing needed here");
>
> the above warning can be dropped.
Hmm, yeah, the fact that this doesn't show up in the logs anywhere
suggests that there is a gap in testing.
--
Álvaro
On 2021-Nov-13, Daniel Westermann wrote:
> /usr/bin/clang -Wno-ignored-attributes -fno-strict-aliasing -fwrapv -O2
> -I../../../src/include -D_GNU_SOURCE -I/usr/include/libxml2 -flto=thin
> -emit-llvm -c -o execMerge.bc execMerge.c
> execMerge.c:552:32: warning: if statement has empty body [-
On Fri, Nov 12, 2021 at 9:58 AM Alvaro Herrera
wrote:
> Here's a new version. Many of the old complaints have been fixed;
> particularly, the handling of partitioned tables is now much cleaner and
> straightforward. Amit Langote helped considerably in getting this part
> to shape -- thanks for
On Fri, Nov 12, 2021 at 3:13 PM Alvaro Herrera
wrote:
> On 2021-Nov-12, Zhihong Yu wrote:
>
> > Hi,
> >
> > + skipped_path = total - insert_path - update_path -
> delete_path;
> >
> > Should there be an assertion that skipped_path is not negative ?
>
> Hm, yeah, added.
>
> > +* We m
On 2021-Nov-12, Zhihong Yu wrote:
> Hi,
>
> + skipped_path = total - insert_path - update_path - delete_path;
>
> Should there be an assertion that skipped_path is not negative ?
Hm, yeah, added.
> +* We maintain separate transaction tables for UPDATE/INSERT/DELETE since
> +*
On Fri, Nov 12, 2021 at 9:58 AM Alvaro Herrera
wrote:
> Here's a new version. Many of the old complaints have been fixed;
> particularly, the handling of partitioned tables is now much cleaner and
> straightforward. Amit Langote helped considerably in getting this part
> to shape -- thanks for
On 2021-Nov-12, Tomas Vondra wrote:
> On 11/12/21 18:57, Alvaro Herrera wrote:
> > Secondarily, and I'm now not sure that I really want to do it, is change
> > the representation for executor: instead of creating a fake join between
> > target and source, perhaps we should have just source, and g
On 11/12/21 18:57, Alvaro Herrera wrote:
Here's a new version. Many of the old complaints have been fixed;
particularly, the handling of partitioned tables is now much cleaner and
straightforward. Amit Langote helped considerably in getting this part
to shape -- thanks for that. Amit also help
> On 1 Sep 2021, at 14:25, Alvaro Herrera wrote:
>
> On 2021-Sep-01, Daniel Gustafsson wrote:
>
>>> On 21 Mar 2021, at 14:57, Alvaro Herrera wrote:
>>> On 2021-Mar-21, Magnus Hagander wrote:
>>
But what is it we *want* it to do? That is, what should be the target?
Is it 2021-07 with
On 2021-Sep-01, Daniel Gustafsson wrote:
> > On 21 Mar 2021, at 14:57, Alvaro Herrera wrote:
> > On 2021-Mar-21, Magnus Hagander wrote:
>
> >> But what is it we *want* it to do? That is, what should be the target?
> >> Is it 2021-07 with status WoA?
> >
> > Yeah, that sounds like it, thanks.
>
> On 21 Mar 2021, at 14:57, Alvaro Herrera wrote:
> On 2021-Mar-21, Magnus Hagander wrote:
>> But what is it we *want* it to do? That is, what should be the target?
>> Is it 2021-07 with status WoA?
>
> Yeah, that sounds like it, thanks.
This patch fails to apply, will there be a new version fo
On Sun, Mar 21, 2021 at 2:57 PM Alvaro Herrera wrote:
>
> On 2021-Mar-21, Magnus Hagander wrote:
>
> > On Fri, Mar 19, 2021 at 6:03 PM Bruce Momjian wrote:
> > >
> > > Let's get someone to go into the "database" and adjust it. ;-)
> >
> > Yeah, we probably can clean that up on the database side
On 2021-Mar-21, Magnus Hagander wrote:
> On Fri, Mar 19, 2021 at 6:03 PM Bruce Momjian wrote:
> >
> > Let's get someone to go into the "database" and adjust it. ;-)
>
> Yeah, we probably can clean that up on the database side :)
Thank you!
> But what is it we *want* it to do? That is, what sh
On Fri, Mar 19, 2021 at 6:03 PM Bruce Momjian wrote:
>
> On Fri, Mar 19, 2021 at 10:53:53AM -0400, David Steele wrote:
> > On 3/19/21 10:44 AM, Alvaro Herrera wrote:
> > > On 2021-Mar-19, David Steele wrote:
> > >
> > > > Since it does not appear this is being worked on for PG14 perhaps we
> > >
On Fri, Mar 19, 2021 at 10:53:53AM -0400, David Steele wrote:
> On 3/19/21 10:44 AM, Alvaro Herrera wrote:
> > On 2021-Mar-19, David Steele wrote:
> >
> > > Since it does not appear this is being worked on for PG14 perhaps we
> > > should
> > > close it in this CF and then reopen it when a patch
On 3/19/21 10:44 AM, Alvaro Herrera wrote:
On 2021-Mar-19, David Steele wrote:
Since it does not appear this is being worked on for PG14 perhaps we should
close it in this CF and then reopen it when a patch is available?
No, please move it to the next CF. Thanks
Ugh. I clicked wrong and mo
On 2021-Mar-19, David Steele wrote:
> Since it does not appear this is being worked on for PG14 perhaps we should
> close it in this CF and then reopen it when a patch is available?
No, please move it to the next CF. Thanks
--
Álvaro Herrera Valdivia, Chile
On 1/18/21 11:48 AM, Alvaro Herrera wrote:
On 2021-Jan-18, Robert Haas wrote:
On Thu, Dec 31, 2020 at 8:48 AM Alvaro Herrera wrote:
Here's a rebase of Simon/Pavan's MERGE patch to current sources. I
cleaned up some minor things in it, but aside from rebasing, it's pretty
much their work (eve
On 2021-Jan-18, Robert Haas wrote:
> On Thu, Dec 31, 2020 at 8:48 AM Alvaro Herrera
> wrote:
> > Here's a rebase of Simon/Pavan's MERGE patch to current sources. I
> > cleaned up some minor things in it, but aside from rebasing, it's pretty
> > much their work (even the commit message is Simon'
On Thu, Dec 31, 2020 at 8:48 AM Alvaro Herrera wrote:
> Here's a rebase of Simon/Pavan's MERGE patch to current sources. I
> cleaned up some minor things in it, but aside from rebasing, it's pretty
> much their work (even the commit message is Simon's).
It's my impression that the previous discu
Jaime Casanova just reported that this patch causes a crash on the
regression database with this query:
MERGE INTO public.pagg_tab_ml_p3 as target_0
USING public.prt2_l_p3_p2 as ref_0 ON target_0.a = ref_0.a
WHEN MATCHED AND cast(null as tid) <= cast(null as tid)THEN DELETE;
The reason
On 2021-Jan-13, Simon Riggs wrote:
> On Sun, Jan 10, 2021 at 1:44 AM Tomas Vondra
> wrote:
> > 8) varlena.c
> >
> > Again, why are these changes to length checks in a MERGE patch?
>
> Nothing I added, IIRC, nor am I aware of why that would exist.
Sorry, this was a borked merge.
--
Álvaro Her
On 1/13/21 11:20 AM, Simon Riggs wrote:
On Sun, Jan 10, 2021 at 1:44 AM Tomas Vondra
wrote:
5) WHEN AND
I admit the "WHEN AND" conditions sounds a bit cryptic - it took me a
while to realize what this refers to. Is that a term established by SQL
Standard, or something we invented?
As Vik
On Sun, Jan 10, 2021 at 1:44 AM Tomas Vondra
wrote:
> 5) WHEN AND
>
> I admit the "WHEN AND" conditions sounds a bit cryptic - it took me a
> while to realize what this refers to. Is that a term established by SQL
> Standard, or something we invented?
As Vik notes, this refers to the WHEN [NOT]
On 1/10/21 2:44 AM, Tomas Vondra wrote:
> 5) WHEN AND
>
> I admit the "WHEN AND" conditions sounds a bit cryptic - it took me a
> while to realize what this refers to. Is that a term established by SQL
> Standard, or something we invented?
The grammar gets it right but the error messages are nons
On 1/8/21 8:22 PM, Alvaro Herrera wrote:
> On 2020-Dec-31, Alvaro Herrera wrote:
>
>> Here's a rebase of Simon/Pavan's MERGE patch to current sources. I
>> cleaned up some minor things in it, but aside from rebasing, it's pretty
>> much their work (even the commit message is Simon's).
>
> Rebase
99 matches
Mail list logo
