Daniel Gustafsson 于2025年4月16日周三 22:20写道：
> > On 14 Apr 2025, at 15:34, Tender Wang wrote:
> >
> > Hi,
> >
> > While reading the estimate_multivariate_ndistinct(),
> > I think "If a match it found, *varinfos is
> > * updated to remove the list of
Tender Wang 于2025年4月14日周一 14:17写道：
> Hi,
>
> While I debug hashjoin codes, in estimate_multivariate_bucketsize(), I
> find that
> the list_copy(hashclauses) below is unnecessary if we have a single join
> clause.
>
> List *clauses = list_copy(hashclauses);
> ..
's not, we should fix it.
BTW, the document doesn't state the order in which the commands are
executed when users specify more than one manipulation in a single ALTER
TABLE command.
--
Thanks,
Tender Wang
Tender Wang 于2025年4月14日周一 21:34写道：
> Hi,
>
> While reading the estimate_multivariate_ndistinct(),
> I think "If a match it found, *varinfos is
> * updated to remove the list of matched varinfos"
> should be "If a match is found, *varinfos is
> * updated to
t;
if (conForm->contype != CONSTRAINT_NOTNULL)
elog(ERROR, "constraint %u is not a not-null constraint", conForm->oid);
I feel that using conForm->conname is more friendly than oid for users.
Others look good for me.
--
Thanks,
Tender Wang
Alvaro Herrera 于2025年4月16日周三 03:12写道：
> On 2025-Apr-15, Tender Wang wrote:
>
> > I thought further about the lockmode calling find_inheritance_children
> > in ATPrepAddPrimaryKey.
> > What we do here? We first get oids of children, then check the if the
> > column o
Tender Wang 于2025年4月15日周二 11:20写道：
>
>
> Tom Lane 于2025年4月15日周二 05:39写道：
>
>> Alvaro Herrera writes:
>> > On 2025-Apr-14, Tom Lane wrote:
>> >> I would not have expected that adding pg_constraint rows implies
>> >> stronger locks than what
x7ffc0e561eb0) at
postmaster.c:3580
#24 0x561cd92afeb1 in ServerLoop () at postmaster.c:1702
#25 0x561cd92af7a2 in PostmasterMain (argc=3, argv=0x561cf1cffb00) at
postmaster.c:1400
#26 0x561cd914cf06 in main (argc=3, argv=0x561cf1cffb00) at main.c:227
The alter table session do check its children not-null constraint using
lockmod=8, and the copy session do get partition_qual to lock parent using
lockmode =1.
I wonder if we have to use the same lockmode for checking children's
not-null constraint.
--
Thanks,
Tender Wang
tch for that.
--
Thanks,
Tender Wang
From 55ac0d72303b7ea431d58cbbc242dc5215e13102 Mon Sep 17 00:00:00 2001
From: Tender Wang
Date: Mon, 14 Apr 2025 21:28:53 +0800
Subject: [PATCH] Fix a typo
---
src/backend/utils/adt/selfuncs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --gi
some overhead of function calls and memory copies.
Any thoughts?
--
Thanks, Tender Wang
From d4a29af25ef276a145b46ecc16d631909fb1891a Mon Sep 17 00:00:00 2001
From: Tender Wang
Date: Mon, 14 Apr 2025 13:53:15 +0800
Subject: [PATCH] Adjust the place of list_copy() in
patterns mean the same thing.
>
OK, makes sense.
--
Thanks, Tender Wang
the second formats to the third one, e.g., using
HeapTupleIsValid.
BTW, I searched the other files, some files also have different ways to
check the validity of tuples.
But the attached patch only focuses on tablecmds.c
Any thoughts?
--
Thanks, Tender Wang
From
Alexander Korotkov 于2025年4月6日周日 19:50写道：
> On Sun, Apr 6, 2025 at 2:42 PM Tender Wang wrote:
> > Daniel Gustafsson 于2025年4月6日周日 19:23写道：
> >>
> >> > On 6 Apr 2025, at 06:02, Tender Wang wrote:
> >>
> >> > I find t
Daniel Gustafsson 于2025年4月6日周日 19:23写道：
> > On 6 Apr 2025, at 06:02, Tender Wang wrote:
>
> > I find that the postgresql.conf.sample file doesn't contain
> enable_self_join_elimination guc.
> > If this is necessary, please see the attached patch.
>
> The GUC
Hi,
I find that the postgresql.conf.sample file doesn't contain
enable_self_join_elimination guc.
If this is necessary, please see the attached patch.
--
Thanks, Tender Wang
From f27c99aebbd07d4008173492c7913749b149b540 Mon Sep 17 00:00:00 2001
From: Tender Wang
Date: Sun, 6 Apr 2025 11:
Alexander Korotkov 于2025年3月25日周二 18:57写道：
> On Fri, Nov 29, 2024 at 3:39 AM Tender Wang wrote:
> > Alexander Pyhalov 于2024年11月29日周五 00:02写道：
> >>
> >> Tender Wang писал(а) 2024-10-09 10:26:
> >> > Hi,
> >> >When I de
Tom Lane 于2025年4月2日周三 23:15写道：
> Tender Wang writes:
> > So let's add CommandCounterIncrement() after calling
> StoreAttrMissingVal().
>
> Pushed with minor editorialization. I thought for a bit about whether
> the CCI call should be inside StoreAttrMissingVal; b
CommandCounterIncrement().
So let's add CommandCounterIncrement() after calling StoreAttrMissingVal().
--
Thanks, Tender Wang
From ee2bc290cab83daf0ebecf9f29cc23539ba19741 Mon Sep 17 00:00:00 2001
From: Tender Wang
Date: Wed, 2 Apr 2025 09:52:22 +0800
Subject: [PATCH] Fix &quo
flow, we should use the alternative calculation method:
>
> uint16 mid = min + (max - min) / 2;
>
> This approach ensures that (max - min) does not exceed 65535, preventing
> the addition from overflowing while still correctly computing the middle
> index.
> Patch
>
> A patch implementing this fix is attached.
>
--
Thanks, Tender Wang
Etsuro Fujita 于2025年3月30日周日 18:28写道：
> Another thing I noticed is $SUBJECT: I think “if lock could not
> immediately acquired” should be “if lock could not be immediately
> acquired”. Attached is a patch for that.
>
Agree.
The patch looks good to me.
--
Thanks,
Tender Wang
ms is zero-based set containing attnums of NOT NULL
* columns.
But in get_relation_notnullatts():
rte->notnullattnums = bms_add_member(rte->notnullattnums,
i + 1);
The notnullattnums seem to be 1-based.
--
Thanks,
Tender Wang
https://www.postgresql.org/message-id/flat/CAHewXN=8aW4hd_W71F7Ua4+_w0=bppuvvtebfbf6g0nusxl...@mail.gmail.com
--
Thanks,
Tender Wang
David Rowley 于2025年3月24日周一 16:50写道：
> On Mon, 24 Mar 2025 at 19:50, Tender Wang wrote:
> >
> > David Rowley 于2025年3月24日周一 05:28写道：
> >> This is no longer true in master, so if we do something here it's only
> >> v17 and earlier.
> >
> > In
something here it's only
> v17 and earlier.
>
In the case of [1], we still have AccessShareLock on entity_2, even though
it is pruned during initial partition pruning.
This seems to contradict what you said. "This is no longer true in master"
.
[1]
https://postgr.es/m/01020195b987abd3-a008b77d-8c63-4931-80a4-be36a351c8b2-000...@eu-west-1.amazonses.com
--
Thanks,
Tender Wang
sponding value in the
> new enum) instead?
>
The below else branch has code if (tcategory == JSONTYPE_CAST). I guess
here the
second JSONTYPE_JSON may just be removed.
@Amit Langote please check out this.
--
Thanks,
Tender Wang
Richard Guo 于2025年3月3日周一 15:34写道：
> On Wed, Feb 26, 2025 at 7:09 PM Tender Wang wrote:
> > Recently, I found Greenplum implement pull-up NOT IN subquery. They have
> the below comments in their codes:
> >
> > We normalize NOT subqueries using the following axioms:
>
nt, or if
> there are other options to consider.
>
>
Recently, I found Greenplum implement pull-up NOT IN subquery. They have
the below comments in their codes:
We normalize NOT subqueries using the following axioms:
*
* val NOT IN (subq) => val <> ALL (subq)
Richard, do you have an impression about this?
--
Thanks,
Tender Wang
join2 t2 where T2.ID = 1000);
> QUERY PLAN
>
>
> Seq Scan on join1 t1 (cost=4.45..38673.19 rows=630150 width=8)
>Filter: (NOT (ANY (id = (hashed SubPlan 1).col1)))
>SubPlan 1
> -> Index Only Scan using idx_j2 on join2 t2 (cost=0.42..4.44 rows=1
> width=4)
>Index Cond: (id = 1000)
> (5 rows)
>
>
Planner now doesn't support pulling up the "NOT IN" sublink. The "NOT IN"
sublink will be transformed into SubPlan.
--
Thanks,
Tender Wang
Amit Langote 于2025年2月23日周日 16:36写道：
> On Sun, Feb 23, 2025 at 2:03 AM Tender Wang wrote:
> > Alexander Lakhin 于2025年2月22日周六 23:00写道：
> >> 21.02.2025 05:40, Amit Langote wrote:
> >>
> >> I pushed the final piece yesterday.
> >>
> >>
&g
uneinfo created by
create_append_plan() is put into the head of global list.
So we first process it in ExecDoInitialPruning(). Then error reports
because we only contain 1 in estate->es_unpruned_relids.
--
Thanks,
Tender Wang
he code consistent
> > > across branches, and this avoids incorrect access patterns when
> > > copy-pasting this code.
> >
> > Hmm, fair point. I will backpatch-through 13.
>
> Done.
>
Thanks for pushing.
--
Thanks,
Tender Wang
andled.
>
Thanks for reviewing.
The BufferGetLSNAtomic() with this patch looks not complex. I think no
need more explanation here.
> Best regards,
> [Xuneng]
>
> The new status of this patch is: Waiting on Author
>
I change the status to Ready for commiter
--
Thanks,
Tender Wang
ded
> * because some places assume rel->tuples is valid for any baserel.
> */
>
> I wonder if this assumption still holds today. If we create an empty
> table, analyze it, and then use it in a query, the table will have
> rel->tuples set to zero and rel->rows set to one, which doesn't cause
> any issues today.
>
> [1]
> https://postgr.es/m/cambws4-ocromekmtvdh3rbmuajqaqdk0qi4k6zouvponmwz...@mail.gmail.com
>
> Thanks
> Richard
>
--
Thanks,
Tender Wang
Alexander Pyhalov 于2024年11月29日周五 00:02写道：
> Tender Wang писал(а) 2024-10-09 10:26:
> > Hi,
> >When I debug FDW join pushdown codes, I found below codes in
> > semijoin_target_ok():
> > if (bms_is_member(var->varno, innerrel->relids) &&
> >
t; There is one more in trgm.h, though it's OK as-is, as well.
> --
> Michael
>
Thanks for pushing.
--
Thanks,
Tender Wang
Andrey M. Borodin 于2024年11月15日周五 17:57写道：
>
>
> > On 15 Nov 2024, at 14:48, Tender Wang wrote:
> >
> > Hi,
> >
> > I found some inconsistent code format in gist.c.
> > See the attached.
>
> I’d suggest to combine such changes with some real co
Hi,
I found some inconsistent code format in gist.c.
See the attached.
--
Thanks,
Tender Wang
0001-Fix-some-codes-format-in-gist.c.patch
Description: Binary data
this is not in a macro.
> I've attached a patch.
>
Yeah, agree. The patch LGTM.
--
Thanks,
Tender Wang
local or shared
buffer.
If the buffer is local, then buffer < 0; it will be cast to uint32 when
passed to GetBufferDescriptor().
This may be unsafe, although no someone reports the problem.
I tweak a few codes; see the attached patch.
Any thoughts?
--
Thanks,
Tender Wang
0001-Fix-unsaf
Michael Paquier 于2024年11月7日周四 14:11写道：
> On Thu, Nov 07, 2024 at 10:57:08AM +0800, Tender Wang wrote:
> > Thanks for reviewing this. I have added it to the 2015-01 commitfest.
>
> Right. I don't quite see why this comment would apply anymore, and
> the commit you are
NULL /* size is currently bogus */, isnull);
> + values, isnull, true /* size is currently bogus */);
> ```
>
> I checked the rest of gistFormTuple() calls and also looked for other
> comments like this. There seems to be only one call like this to fix.
>
Thanks for reviewing this. I have added it to the 2015-01 commitfest.
--
Thanks,
Tender Wang
emoved together.
By the way, after commit 5edb24a, the comments in gistbuildCallback() was
removed.
So I think we can now remove the obsolete comment from gistinsert().
--
Thanks,
Tender Wang
0001-Remove-an-obsolete-comment-in-gistinsert.patch
Description: Binary data
Hi,
I found a typo in the comment of gistdoinsert() when I read the codes.
See the attached patch.
--
Thanks,
Tender Wang
From 9c614b424418d451fb375294733b0cdc3740a1b7 Mon Sep 17 00:00:00 2001
From: Tender Wang
Date: Mon, 4 Nov 2024 22:28:24 +0800
Subject: [PATCH] Fix a typo in the comment of
Amit Langote 于2024年11月1日周五 15:27写道：
> Hi,
>
> On Wed, Oct 23, 2024 at 10:48 PM Tender Wang wrote:
> > I think the root cause of this thread and [1] are same. We don't use
> the Partition Key collation but column's
> > collation to fill
wise grouping is not the same as when
> enable_partitionwise_aggregate is off.
>
LGTM
--
Thanks,
Tender Wang
x27;s not
> the same as partcoll.
>
Me, too.
>
> Attached 0002 is what I came up with. One thing that's different from
> what Jian proposed is that match_expr_to_partition_keys() returns -1
>
Agree.
(expr not matched to any key) when the collation is also not matched
> instead of using a separate output parameter for that.
>
In have_partkey_equi_join()
...
if (exprs_known_equal(root, expr1, expr2, btree_opfamily))
{
Oid partcoll2 = rel1->part_scheme->partcollation[ipk];
I think we should use rel2 here, not rel1.
--
Thanks,
Tender Wang
jian he 于2024年10月29日周二 14:15写道：
> On Thu, Oct 24, 2024 at 3:01 PM Tender Wang wrote:
> >
> > I feel that it's hard only to use one struct(for example, X), which just
> calls equal(X, expr)
> > can check both the expression match and the collation match.
> >
Alvaro Herrera 于2024年10月28日周一 17:16写道：
> On 2024-Oct-27, Tender Wang wrote:
>
> > BTW, while reviewing the v2 patch, I found the parentConTup in
> > foreach(cell, fks) block
> > didn't need it anymore. We can remove the related codes.
>
> True. Done so in thi
d_att->natts of pt is 2.
It will not go into tp1 because tp1 is a partition of pt. But after
detach, the rel->rd_att->natts of tp1 is 1,
so "ERROR: invalid attribute number 2" will report.
CREATE TABLE tp1... will ignore the dropped column of parent, so the natts
of tp1 is 1, but its parent is 2.
--
Thanks,
Tender Wang
Alvaro Herrera 于2024年10月27日周日 05:47写道：
> On 2024-Oct-25, Alvaro Herrera wrote:
>
> > On 2024-Oct-25, Tender Wang wrote:
> >
> > > Thanks for reporting. I can reproduce this memory invalid access on
> HEAD.
> > > After debuging codes, I found the root c
Alvaro Herrera 于2024年10月25日周五 16:30写道：
> On 2024-Oct-25, Tender Wang wrote:
>
> > Thanks for reporting. I can reproduce this memory invalid access on HEAD.
> > After debuging codes, I found the root cause.
> > In DetachPartitionFinalize(), below code:
> > att =
e:
att = TupleDescAttr(RelationGetDescr(partRel),
attmap->attnums[conkey[i] - 1] - 1);
We should use confkey[i] -1 not conkey[i] - 1;
In this case, the length of attmap is 2, conkey= {2,3}, confkey={1,2},
attmap->attnums[conkey[1] -1] will trigger
memory invalid
i (pquery.c:1316)
> ==00:00:00:07.887 1079077==by 0x7D3431: PortalRun (pquery.c:791)
>
> Reproduced on REL_15_STABLE .. master.
>
Sorry, I can't reproduce this leak on master.
--
Thanks,
Tender Wang
QUERY PLAN
-
Seq Scan on pktable (cost=0.00..27.00 rows=7 width=32)
Filter: (x = 'Å'::text COLLATE ignore_accents)
(2 rows)
The filter expr in the two queries is different. And I debug the texteq;
the collid is also different.
So the result of the two queries is different. I don't look execute more
in details.
--
Thanks,
Tender Wang
Tender Wang 于2024年10月23日周三 21:48写道：
> Hi all,
>
> I find another issue as $SUBJECT when I work on [1].
>
When I continue to work on this, I find below issue. But I'm not sure
whether it is a bug.
postgres=# create table part_index(a text primary key) partition by list (
Amit Langote 于2024年10月24日周四 14:33写道：
> Hi,
>
> On Thu, Oct 24, 2024 at 1:46 PM Tender Wang wrote:
> > Tender Wang 于2024年10月23日周三 21:48写道：
> >>
> >> Hi all,
> >>
> >> I find another issue as $SUBJECT when I work on [1].
> >
> > W
Tender Wang 于2024年10月23日周三 21:48写道：
> Hi all,
>
>
> I think the root cause of this thread and [1] are same. We don't use the
> Partition Key collation but column's
> collation to fill the RelOptInfo partexprs field in
> set_baserel_partition_key_exprs().
>
me, I was unsure if it was the correct fix.
Until I find this thread issue, I think we should do it this way.
In the attached patch, I include this thread test and [1] test case.
I have two questions in my head:
1. Does partition pruning logic still check the collation match with this
patch.
Alvaro Herrera 于2024年10月22日周二 05:52写道：
> On 2024-Oct-21, Tender Wang wrote:
>
> > I suspect that we don't need the below if
> > statement anymore.
> > /*
> > * If the referenced side is partitioned (which we know because our
> > * parent's const
the referenced side is partitioned (which we know because our
* parent's constraint points to a different relation than ours) then
* we must, in addition to the above, create pg_constraint rows that
* point to each partition, each with its own action triggers.
*/
if (parentConForm->conrelid != conform->conrelid)
{
...
}
The above contidion is always true according to my test.
I haven't figured out an anti-case.
Any thoughts?
[1]
https://www.postgresql.org/message-id/CAHewXNkuU2V7GfgFkwd265RJ99%2BBfJueNEZhrHSk39o3thqxNA%40mail.gmail.com
--
Thanks,
Tender Wang
only need to provide its
> full definition (= include the other header file) if you actually want
> to access the struct's fields.
>
>
Yeah. There are many examples. For example as below:
in struct RelOptInfos,
/* use "struct FdwRoutine" to avoid including fdwapi.h here */
struct FdwRoutine *fdwroutine pg_node_attr(read_write_ignore);
--
Thanks,
Tender Wang
elids) will not execute due to short
circuit.
So I think we can remove the "!bms_is_member(var->varno, outerrel->relids)"
from if.
Any thoughts?
--
Thanks,
Tender Wang
0001-Remove-an-unnecessary-check-as-Var-can-only-belong-t.patch
Description: Binary data
wording might need work.
>
The indexing test case in regress failed with v4 patch.
alter table only idxpart add primary key (a); -- fail, no not-null
constraint
-ERROR: column a of table idxpart0 is not marked not null
+ERROR: column "a" of table "idxpart0" is not marked NOT NULL
It seemed the error message forgot to change.
--
Thanks,
Tender Wang
https://www.openpie.com/
his made me realize that there is a more general problem, to
> wit, that pg_dump is not dumping not-null constraint names correctly --
> sometimes they just not dumped, which is Not Good. I'll have to look
> into that once more.
>
>
> (Also: there are still a few additional test stanzas in regress/ that
> ought to be removed; also, I haven't re-tested sepgsql, so it's probably
> broken ATM.)
>
> --
> Álvaro Herrera PostgreSQL Developer —
> https://www.EnterpriseDB.com/
>
--
Thanks,
Tender Wang
create table cc3() inherits(pp1,cc1,cc2);
>
> alter table pp1 alter f1 set not null;
> ERROR: tuple already updated by self
>
I guess some place needs call CommandCounterIncrement().
--
Thanks,
Tender Wang
Tender Wang 于2024年9月4日周三 11:48写道：
>
>
> Richard Guo 于2024年8月21日周三 15:11写道：
>
>> On Fri, Aug 16, 2024 at 4:14 PM Richard Guo
>> wrote:
>> > I had a self-review of this patchset and made some refactoring,
>> > especially to the function that creates
*/
partially_grouped_rel->reltarget =
make_partial_grouping_target(root, grouped_rel->reltarget,
extra->havingQual);
--
Thanks,
Tender Wang
jian he 于2024年9月9日周一 16:31写道：
> On Mon, Sep 2, 2024 at 6:33 PM Tender Wang wrote:
> >
> >
> >
> > The attached patch adds List *nnconstraints, which store the not-null
> definition, in struct CreateStmt.
> > This makes me a little confused about List
Alvaro Herrera 于2024年8月8日周四 06:50写道：
> On 2024-Jul-26, Tender Wang wrote:
>
> > Junwang Zhao 于2024年7月26日周五 14:57写道：
> >
> > > There is a bug report[0] Tender comments might be the same issue as
> > > this one, but I tried Alvaro's and mine patch, neit
ses
is_dummy_rel(). Other commiters use IS_DUMMY_REL.
3. The attached patch does not consider FDW when creating a path for
grouped_rel or grouped_join.
Do we need to think about FDW?
I haven't finished reviewing the patch set. I will continue to learn this
feature.
--
Thanks,
Tender Wang
how-current-patch=diff' to see the failed patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".
--
Thanks,
Tender Wang
Jehan-Guillaume de Rorthais 于2024年9月3日周二 17:26写道：
> Hi Tender,
>
> On Tue, 3 Sep 2024 10:16:44 +0800
> Tender Wang wrote:
>
> > Jehan-Guillaume de Rorthais 于2024年9月3日周二 05:02写道：
> […]
> > > * Constraint & trigger catalog cleanup [1] (this thre
n reset their
attnotnull flags below."
However, there are no related codes that reflect the above comments.
--
Thanks,
Tender Wang
on this topic.
>
> This bug really needs more discussion and design consideration. I have
> thought about this problem and haven't found any solution that don't
> involve
> breaking the current core behavior. It really looks like an impossible
> bug to
> fix without dropping the constraint itself. On both side. Maybe the only
> sane
> behavior would be to forbid detaching the partition if it would break the
> constraint.
>
> But let's discuss this on the related thread, should we?
>
>
> Thank you for reading me all the way down to the bottom!
>
> Regards,
>
> [1] https://www.postgresql.org/message-id/20230705233028.2f554f73%40karst
> [2] https://www.postgresql.org/message-id/20230420144344.40744130%40karst
> [3] https://www.postgresql.org/message-id/20230707175859.17c91538%40karst
>
>
>
>
--
Tender Wang
ll call AdjustNotNullInheritance1() in
AddRelationNewConstraints().
The comments
before entering AdjustNotNullInheritance1() in AddRelationNewConstraints()
look confusing to me.
Because constraint is not inherited.
--
Tender Wang
or working on this again.
AT_PASS_OLD_COL_ATTRS, I didn't see any other code that used it. I don't
think it's necessary.
I will take the time to look over the attached patch.
--
Tender Wang
Richard Guo 于2024年8月29日周四 10:46写道：
> On Wed, Aug 28, 2024 at 9:01 PM Robert Haas wrote:
> > On Tue, Aug 27, 2024 at 11:57 PM Tender Wang wrote:
> > > I haven't look all of them. I just pick few simple plan test(e.g.
> 19.sql, 45.sql).
> > > For example, 19.
Richard Guo 于2024年8月29日周四 10:46写道：
> On Wed, Aug 28, 2024 at 9:01 PM Robert Haas wrote:
> > On Tue, Aug 27, 2024 at 11:57 PM Tender Wang wrote:
> > > I haven't look all of them. I just pick few simple plan test(e.g.
> 19.sql, 45.sql).
> > > For example, 19.
lan test(e.g. 19.sql,
45.sql).
For example, 19.sql, eager agg pushdown doesn't get large gain, but a little
performance regress.
I will continue to do benchmark on this feature.
[1] https://github.com/tenderwg/eager_agg
--
Tender Wang
Alvaro Herrera 于2024年8月23日周五 02:41写道：
> On 2024-Aug-22, Tender Wang wrote:
>
> > I apply the v14 patch on branch REL_14_STABLE. I run this thread issue
> and I
> > find below error.
> > [...]
> > ERROR: cache lookup failed for constraint 16400
> >
>
Tender Wang 于2024年8月22日周四 11:19写道：
>
>
> Alvaro Herrera 于2024年8月22日周四 06:00写道：
>
>> On 2024-Aug-19, Alvaro Herrera wrote:
>>
>> > I haven't pushed it yet, mostly because of being unsure about not doing
>> > anything for the oldest branches (14 and
nt 16400
I haven't look into details to find out where cause above error.
--
Tender Wang
Richard Guo 于2024年8月22日周四 10:53写道：
> On Wed, Aug 21, 2024 at 6:25 PM Tender Wang wrote:
> >Oversight in 7ff9afbbd; I think we can do the same way for the
> ATExecAddColumn().
>
> LGTM. Pushed.
>
Thanks for pushing.
--
Tender Wang
Hi,
Oversight in 7ff9afbbd; I think we can do the same way for the
ATExecAddColumn().
--
Tender Wang
v1-0001-Small-code-simplification.patch
Description: Binary data
Alvaro Herrera 于2024年8月20日周二 10:25写道：
> On 2024-Aug-20, Tender Wang wrote:
>
> > > As I understand, this fix needs to be applied all the way back to 12,
> > > because the overall functionality is that old. However, in branches 14
> > > and back, the patch does
Alvaro Herrera 于2024年8月8日周四 06:50写道：
> On 2024-Jul-26, Tender Wang wrote:
>
> > Junwang Zhao 于2024年7月26日周五 14:57写道：
> >
> > > There is a bug report[0] Tender comments might be the same issue as
> > > this one, but I tried Alvaro's and mine patch, neit
Alvaro Herrera 于2024年8月8日周四 06:50写道：
> On 2024-Jul-26, Tender Wang wrote:
>
> > Junwang Zhao 于2024年7月26日周五 14:57写道：
> >
> > > There is a bug report[0] Tender comments might be the same issue as
> > > this one, but I tried Alvaro's and mine patch, neit
Alvaro Herrera 于2024年8月8日周四 06:50写道：
> On 2024-Jul-26, Tender Wang wrote:
>
> > Junwang Zhao 于2024年7月26日周五 14:57写道：
> >
> > > There is a bug report[0] Tender comments might be the same issue as
> > > this one, but I tried Alvaro's and mine patch, neit
Senglee Choi 于2024年8月5日周一 09:24写道：
> Fixed a minor typo in src/include/storage/bufpage.h.
> Please let me know if any further action is required.
>
Good catch. +1
--
Tender Wang
ipt below in case you are interested.
>
My earlier patch should handle Alexander reported case. But I did not do
more
test. I'm not sure that wether or not has dismatching between pg_constraint
and pg_trigger.
I aggred with Alvaro said that "requires a much more invasive solution".
--
Tender Wang
e an individual table having the same foreign
> key.
>
I don't find the useful queries in your last email. Can you provide them.
Thanks.
--
Tender Wang
16402
(4 rows)
--
Tender Wang
://www.postgresql.org/message-id/18541-628a61bc267cd2d3%40postgresql.org
[2]
https://www.postgresql.org/message-id/GVAP278MB02787E7134FD691861635A8BC9032%40GVAP278MB0278.CHEP278.PROD.OUTLOOK.COM
--
Tender Wang
v3-0001-Fix-partition-detach-issue.patch
Description: Binary data
v3-0002-Add-test-case.patch
Description: Binary data
Richard Guo 于2024年7月12日周五 10:30写道：
> On Sat, Jul 6, 2024 at 5:32 PM Richard Guo wrote:
> > Here is a new rebase.
> >
> > I'm planning to push it next week, barring any objections.
>
> Pushed.
>
> Thanks
> Richard
>
Thanks for pushing.
--
Tender Wang
Richard Guo 于2024年6月18日周二 17:24写道：
> On Tue, Jun 4, 2024 at 6:51 PM Tender Wang wrote:
> > Yeah, Richard commented the v1 patch about JOIN_UNIQUE_INNER in [1]
> >
> > * I think we should not consider materializing the cheapest inner path
> > if we're doing JO
to know if it is ready to move to the next status "Ready for
commiter".
Thanks.
--
Tender Wang
fujii.y...@df.mitsubishielectric.co.jp <
fujii.y...@df.mitsubishielectric.co.jp> 于2024年6月5日周三 09:26写道：
> Hi. Tender.
>
> Thank you for modification.
>
> > From: Tender Wang
> > Sent: Tuesday, June 4, 2024 7:51 PM
> > Please add more tests. Espec
Tomasz Rybak 于2024年5月31日周五 04:21写道：
> On Tue, 2024-04-23 at 16:59 +0800, Tender Wang wrote:
> >
> [ cut ]
> >
> > I have rebased master and fixed a plan diff case.
>
> We (me, Paul Jungwirth, and Yuki Fujii) reviewed this patch
> at PgConf.dev Patch Review Works
be useful or not since we can't estimate the number of times
the subplan will be called until the outer plan is generated."
git show b6002a796d
--
Tender Wang
OpenPie: https://en.openpie.com/
quot; are all about
a base rel.
Every field has a comment. I think that's already helpful for understanding
what information
we need to optimize a base rel.
--
Tender Wang
OpenPie: https://en.openpie.com/
1 - 100 of 160 matches
Mail list logo
