tender wang
[image: 附件]14:51 (2小时前)
发送至 pgsql-hackers
Hi hackers.
This query has different result on 16devel and 15.2.
select
sample_3.n_regionkey as c0,
ref_7.l_linenumber as c3,
sample_4.l_quantity as c6,
sample_5.n_nationkey as c7,
sample_3.n_name as c8
from
++++
(0 rows)
tender wang 于2023年3月6日周一 22:48写道：
> Results on 16devel:
> c0 | c3 | c6 | c7 |c8
> ++++---
> 0 |||| ALGERIA
> 0 |||| ETHIOPIA
> 0 |||| KENYA
> 0 ||
nstraint if has the
tuple. if attnotnull is ture, but pg_constraint
doesn't has that tuple. Aboved error will report.
It will be confuesed for users. Because \d shows the column c0 has not
null, and we cann't insert NULL value. But it
reports errore when users drop the NOT NULL constraint.
Alvaro Herrera 于2024年3月26日周二 23:25写道：
> On 2024-Mar-26, Tender Wang wrote:
>
> > postgres=# CREATE TABLE t1(c0 int, c1 int);
> > postgres=# ALTER TABLE t1 ADD CONSTRAINT Q PRIMARY KEY(c0, c1);
> > postgres=# ALTER TABLE t1 DROP c1;
> >
> > postgres=# ALT
Alvaro Herrera 于2024年3月26日周二 23:25写道：
> On 2024-Mar-26, Tender Wang wrote:
>
> > postgres=# CREATE TABLE t1(c0 int, c1 int);
> > postgres=# ALTER TABLE t1 ADD CONSTRAINT Q PRIMARY KEY(c0, c1);
> > postgres=# ALTER TABLE t1 DROP c1;
> >
> > postgres=# ALT
Alvaro Herrera 于2024年3月26日周二 23:25写道：
> On 2024-Mar-26, Tender Wang wrote:
>
> > postgres=# CREATE TABLE t1(c0 int, c1 int);
> > postgres=# ALTER TABLE t1 ADD CONSTRAINT Q PRIMARY KEY(c0, c1);
> > postgres=# ALTER TABLE t1 DROP c1;
> >
> > postgres=# ALT
jian he 于2024年3月28日周四 13:18写道：
> On Wed, Mar 27, 2024 at 10:26 PM Tender Wang wrote:
> >
> > Alvaro Herrera 于2024年3月26日周二 23:25写道：
> >>
> >> On 2024-Mar-26, Tender Wang wrote:
> >>
> >> > postgres=# CREATE TABLE t1(c0 int, c1 int);
> >
Alvaro Herrera 于2024年3月26日周二 23:25写道：
> On 2024-Mar-26, Tender Wang wrote:
>
> > postgres=# CREATE TABLE t1(c0 int, c1 int);
> > postgres=# ALTER TABLE t1 ADD CONSTRAINT Q PRIMARY KEY(c0, c1);
> > postgres=# ALTER TABLE t1 DROP c1;
> >
> > postgres=# ALT
Alvaro Herrera 于2024年3月28日周四 17:18写道：
> On 2024-Mar-28, Tender Wang wrote:
>
> > RemoveConstraintById() should think recurse(e.g. partition table)? I'm
> not
> > sure now.
> > If we should think process recurse in RemoveConstraintById(), the
> > func
constraint will be broken.
>
> other than that, the change in RemoveConstraintById looks sane.
>
Above comments want to say that after pk constranit dropped, if there are
tuples in
pg_constraint, that means the definition of column has not-null constraint.
So we can't
set pg_attribute.attnotnull to false.
For example:
create table t1(a int not null);
alter table t1 add constraint t1_pk primary key(a);
alter table t1 drop constraint t1_pk;
--
Tender Wang
OpenPie: https://en.openpie.com/
It has been several days since the last email. Do you have any
suggestions, please?
What I'm concerned about is that adding a new AT_PASS is good fix? Is it
a big try?
More concerned is that it can cover all ALTER TABLE cases?
Any thoughts.
--
Tender Wang
OpenPie: https://en.openpie.com/
e loss because mass inserts into indexes may be much slower
> than building indexes from scratch.
> I think both aspects need to be carefully considered. Even if we
> accept them, this needs to be documented. I think now it's too late
> for both of these. So, this should wait fo
Andrey M. Borodin 于2024年4月8日周一 17:40写道：
>
>
> > On 27 Sep 2023, at 16:06, tender wang wrote:
> >
> >Do you have any comments or suggestions on this issue? Thanks.
> Hi Tender,
>
> there are some review comments in the thread, that you might be interested
jian he 于2024年4月10日周三 14:10写道：
> On Wed, Apr 10, 2024 at 1:29 AM Alvaro Herrera
> wrote:
> >
> > On 2024-Mar-29, Tender Wang wrote:
> >
> > > I think aboved case can explain what's meaning about comments in
> > > dropconstraint_internal.
> >
er | | not null |
postgres=# alter table notnull_tbl1 alter c0 drop not null;
ERROR: could not find not-null constraint on column "c0", relation
"notnull_tbl1"
--
Tender Wang
OpenPie: https://en.openpie.com/
rors from error
messages and code comments [1] .
Except those issues, @Alexander Lakhin has found
some bugs [2]
I have some concerns that whether this patch is ready to commit.
[1]
https://www.postgresql.org/message-id/CAHewXNkGMPU50QG7V6Q60JGFORfo8LfYO1_GCkCa0VWbmB-fEw%40mail.gmail.com
[2]
https://www.postgresql.org/message-id/dbc8b96c-3cf0-d1ee-860d-0e491da20485%40gmail.com
--
Tender Wang
OpenPie: https://en.openpie.com/
y thoughts? Thanks.
--
Tender Wang
OpenPie: https://en.openpie.com/
database0.log
Description: Binary data
0001-Fix-RangeType-oid-not-found-when-doing-Memoize.patch
Description: Binary data
rei Lepikhov
> > mailto:a.lepik...@postgrespro.ru>> wrote:
> >
> > On 26/2/2024 12:44, Tender Wang wrote:
> > > Make sense. I found MemoizeState already has a MemoryContext, so
> > I used it.
> > > I update the patch.
> > This approach is b
I read Memoize code and how other node use ResetExprContext() recently.
The comments about per_tuple_memory said that :
* ecxt_per_tuple_memory is a short-term context for expression results.
* As the name suggests, it will typically be reset once per tuple,
* before we begin to evaluate exp
te now.
[1]
https://www.postgresql.org/message-id/83281eed63c74e4f940317186372abfd%40cft.ru
--
Tender Wang
OpenPie: https://en.openpie.com/
v6-0001-Fix-wrong-used-ResetExprContext-in-ExecMemoize.patch
Description: Binary data
Andrei Lepikhov 于2024年3月5日周二 17:36写道：
> On 1/3/2024 14:18, Tender Wang wrote:
> > During debug, I learned that numeric_add doesn't have type check like
> > rangetype, so aboved query will not report "type with xxx does not
> exist".
> >
> > And
Andrei Lepikhov 于2024年3月6日周三 11:37写道：
> I think, it is a bug. Should it be fixed (and back-patched) earlier?
>
Agreed. Need David to review it as he knows this area best.
--
Tender Wang
OpenPie: https://en.openpie.com/
David Rowley 于2024年3月11日周一 13:25写道：
> On Thu, 7 Mar 2024 at 22:50, David Rowley wrote:
> >
> > On Thu, 7 Mar 2024 at 15:24, Tender Wang wrote:
> > >
> > > Andrei Lepikhov 于2024年3月6日周三 11:37写道：
> > >> I think, it is a bug. Should it be fixed (
e Filter: false
-> Hash
-> Result
One-Time Filter: false
(13 rows)
regards, tender
wang
Attached file included table schema information, but no data.
tender wang 于2023年4月4日周二 10:53写道：
> Hi hackers,
> I encounter a problem, as shown below:
>
> query:
> select
> ref_0.ps_suppkey as c0,
> ref_1.c_acctbal as c1,
> ref_2.o_totalprice as c2,
>
Richard Guo 于2023年4月21日周五 15:35写道：
> There was discussion in [1] about improvements to list manipulation in
> several places. But since the discussion is not related to the topic in
> that thread, fork a new thread here and attach a patch to show my
> thoughts.
>
> Some are just cosmetic changes
Is there a problem if using
table_close()?
> What's more, the comment for it seems useless, just delete it.
>
> Thanks!
>
regard, tender wang
Bharath Rupireddy 于2023年5月10日周三
22:17写道：
> On Sat, Mar 18, 2023 at 12:34 PM Xiaoran Wang wrote:
> >
> > Hi hackers,
> >
> > In heap_create_with_catalog, the Relation new_rel_desc is created
> > by RelationBuildLocalRelation, not table_open. So it's better to
> > call RelationClose to release it
Tom Lane 于2023年5月11日周四 00:32写道：
> Bharath Rupireddy writes:
> > And, the /* do not unlock till end of xact */, it looks like it's been
> > there from day 1. It may be indicating that the ref count fo the new
> > relation created in heap_create_with_catalog() will be decremented at
> > the end of
Hi
Is there any conclusion to this issue?
Jehan-Guillaume de Rorthais 于2023年8月10日周四 23:03写道：
> On Thu, 3 Aug 2023 11:02:43 +0200
> Alvaro Herrera wrote:
>
> > On 2023-Aug-03, tender wang wrote:
> >
> > > I think old "sub-FK" should not be dropped, t
my idea about this issue. Hope
to get your reply.
Alvaro Herrera 于2023年10月25日周三 20:13写道：
> On 2023-Oct-25, tender wang wrote:
>
> > Hi
> >Is there any conclusion to this issue?
>
> None yet. I intend to work on this at some point, hopefull
The v8-0001 patch failed to apply in my local repo as below:
git apply v8-0001-Make-all-SLRU-buffer-sizes-configurable.patch
error: patch failed: src/backend/access/transam/multixact.c:1851
error: src/backend/access/transam/multixact.c: patch does not apply
error: patch failed: src/backend/access/
Andrey M. Borodin 于2023年12月14日周四 17:02写道：
>
>
> > On 14 Dec 2023, at 08:12, Amul Sul wrote:
> >
> >
> > + int bankno = pageno & ctl->bank_mask;
> >
> > I am a bit uncomfortable seeing it as a mask, why can't it be simply a
> number
> > of banks (num_banks) and get the bank number through modulus
Andrey M. Borodin 于2023年12月14日周四 17:35写道：
>
>
> > On 14 Dec 2023, at 14:28, tender wang wrote:
> >
> > Now that AND is more faster, Can we replace the '%
> SLRU_MAX_BANKLOCKS' operation in SimpleLruGetBankLock() with '& 127'
>
>
This thread [1] also Improving the heapgetpage function, and looks like
this thread.
[1]
https://www.postgresql.org/message-id/a9f40066-3d25-a240-4229-ec2fbe94e7a5%40yeah.net
Muhammad Malik 于2023年9月1日周五 04:04写道：
> Hi,
>
> Is there a plan to merge this patch in PG16?
>
> Thanks,
> Muhammad
>
> -
Hi all,
I recently run benchmark[1] on master, but I found performance problem
as below:
explain analyze select
subq_0.c0 as c0,
subq_0.c1 as c1,
subq_0.c2 as c2
from
(select
ref_0.l_shipmode as c0,
sample_0.l_orderkey as c1,
sample_0.l_quantity as c2,
r
: 160571.476 ms
(20 rows)
tender wang 于2023年9月5日周二 16:52写道：
> Hi all,
>
>I recently run benchmark[1] on master, but I found performance problem
> as below:
>
> explain analyze select
> subq_0.c0 as c0,
> subq_0.c1 as c1,
> subq_0.c2 as c2
> from
> (se
Richard Guo 于2023年9月5日周二 18:51写道：
>
> On Tue, Sep 5, 2023 at 4:52 PM tender wang wrote:
>
>>I recently run benchmark[1] on master, but I found performance problem
>> as below:
>> ...
>>
>> I debug the code and find consider_parallel_nestloop() doesn
Hi tom,
Do you have any comments or suggestions on this issue? Thanks.
Richard Guo 于2023年9月8日周五 14:06写道：
>
> On Fri, Sep 8, 2023 at 3:15 AM Robert Haas wrote:
>
>> The example query provided here seems rather artificial. Surely few
>> people write a join clause that references neither of the
The comment /* not needed for Consts */ may be more better close to if
(!IsA(expr, Const)).
Others look good to me.
David Rowley 于2023年10月9日周一 07:28写道：
> On Sat, 7 Oct 2023 at 03:11, Sergei Glukhov
> wrote:
> > I noticed that combination of prepared statement with generic plan and
> > 'IS NUL
For hash partition table, if partition key is IS NULL clause, the
condition in if in get_steps_using_prefix_recurse:
if (cur_keyno < step_lastkeyno - 1)
is not enough.
Like the decode crashed case, explain select * from hp where a = 1 and b is
null and c = 1;
prefix list just has a = 1 clause.
I
David Rowley 于2023年10月11日周三 15:52写道：
> On Wed, 11 Oct 2023 at 15:49, David Rowley wrote:
> > It might have been better if PartClauseInfo could also describe IS
> > NULL quals, but I feel if we do that now then it would require lots of
> > careful surgery in partprune.c to account for that. Prob
es.
With kindest regards, tender wang
urrent_query;
+ return result;
}
regards, tender wang
ubq_0.c1
-> Result
One-Time Filter: false
(4 rows)
Attached file included table schema info.
regards, tender wang
dbt3-s0.01-janm.sql
Description: Binary data
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
to know if it is ready to move to the next status "Ready for
commiter".
Thanks.
--
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
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
I think old "sub-FK" should not be dropped, that will be violates foreign
key constraint. For example :
postgres=# insert into r values(1,1);
INSERT 0 1
postgres=# ALTER TABLE r DETACH PARTITION r_1;
ALTER TABLE
postgres=# delete from p_1 where id = 1;
DELETE 1
postgres=# select * from r_1;
id |
try to fix this problem in the attached patch.
Any thoughts.
Alvaro Herrera 于2023年8月3日周四 17:02写道：
> On 2023-Aug-03, tender wang wrote:
>
> > I think old "sub-FK" should not be dropped, that will be violates
> foreign
> > key constraint.
>
> Yeah, I'
present in table "p".
After detach operation, r_1 is normal relation and the inherited foreign
key 'r_p_id_fkey' should be removed.
tender wang 于2023年8月3日周四 17:34写道：
> I think the code to determine that fk of a partition is inherited or not
> is not enough.
> For example,
ction like GetParentedForeignKeyRefs(), but the
ScanKey should be conrelid field not confrelid.
I quickly test on my above solution in my env, can be solve above issue.
tender wang 于2023年8月4日周五 17:04写道：
> Oversight the DetachPartitionFinalize(), I found another bug below:
>
> postgres=# CREATE TABLE p ( id
The foreign key still works even though partition was detached. Is this
behavior expected?
I can't find the answer in the document. If it is expected behavior ,
please ignore the bug I reported a few days ago.
tender wang 于2023年8月4日周五 17:04写道：
> Oversight the DetachPartitionFinalize(),
I have an range partition and query below:
create table p_range(a int, b int) partition by range (a,b); create table
p_range1 partition of p_range for values from (1,1) to (3,3); create table
p_range2 partition of p_range for values from (4,4) to (6,6); explain
select * from p_range where b =2;
e do is set attnotnull = false, and call CatalogTupleUpdate.
--
> Álvaro Herrera 48°01'N 7°57'E —
> https://www.EnterpriseDB.com/
> "Postgres is bloatware by design: it was built to house
> PhD theses." (Joey Hellerstein, SIGMOD annual conferen
OP c1;
> +\d+ notnull_tbl1
> + Table "public.notnull_tbl1"
> + Column | Type | Collation | Nullable | Default | Storage | Stats
> target | Description
>
> ++-+---+--+-----+-+--+-
> + c0 | integer | | not null | | plain |
> |
> +
>
> this is not what we expected?
> "not null" for "c0" now should be false?
> am I missing something?
>
Yeah, now this is expected behavior.
Users can drop manually not-null of "c0" if they want, and no error
reporte.
--
Tender Wang
OpenPie: https://en.openpie.com/
se must do for this
case.
If the standard does not specify, then it depends on each database vendor's
decision.
Some people like not-null retained, other people may like not-null removed.
I think it will be ok if people can drop not-null or add not-null back
again after dropping pk.
In Master, not-null will reset when we drop PK directly. I hope dropping pk
indirectly
is consistent with dropping PK directly.
--
Tender Wang
OpenPie: https://en.openpie.com/
or somewhere else.
Except AT_SetAttNotNull type, other types add a AT pass to tab->subcmds.
Because
not-null should be added before re-adding index, there is no right AT pass
in current AlterTablePass.
So a new AT pass ahead AT_PASS_OLD_INDEX is needed.
Another reason is that it can
to ensure the pg_upgrade behavior is sane. I intend to get
> this pushed tomorrow, if nothing ugly comes up.
>
The new patch looks good to me.
>
> CI run: https://cirrus-ci.com/build/5471117953990656
>
>
--
Tender Wang
OpenPie: https://en.openpie.com/
Andrey M. Borodin 于2024年4月8日周一 17:40写道：
>
>
> > On 27 Sep 2023, at 16:06, tender wang wrote:
> >
> >Do you have any comments or suggestions on this issue? Thanks.
> Hi Tender,
>
> there are some review comments in the thread, that you might be interested
>
> another potential incompatibilities issue:
> ALTER TABLE DROP PRIMARY KEY
>
> see:
>
> https://www.postgresql.org/message-id/202404181849.6frtmajobe27%40alvherre.pgsql
>
>
Since Alvaro has reverted all changes to not-null constraints, so will not
have potential incompatibilities issue.
--
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/
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/
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
t1 RIGHT OUTER JOIN ONLY t2 ON t2.c0 RIGHT OUTER JOIN
v0 ON ((t2.c1)=(0.08182310538090898))) as res;
ERROR: wrong varnullingrels (b 5 7) (expected (b)) for Var 3/3
regards, tender wang
謝東霖 于2023年6月3日周六 23:21写道：
> Hello hackers
>
> Attached is my first patch for PostgreSQL, which is a simple one-liner
> that I believe can improve the code.
>
> In the "join_search_one_level" function, I noticed that the variable
> "other_rels_list" always refers to "joinrels[1]" even when the (le
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
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
nt 16400
I haven't look into details to find out where cause above error.
--
Tender Wang
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
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
> >
>
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
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.
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
ll call AdjustNotNullInheritance1() in
AddRelationNewConstraints().
The comments
before entering AdjustNotNullInheritance1() in AddRelationNewConstraints()
look confusing to me.
Because constraint is not inherited.
--
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
n reset their
attnotnull flags below."
However, there are no related codes that reflect the above comments.
--
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
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
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
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
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
*/
partially_grouped_rel->reltarget =
make_partial_grouping_target(root, grouped_rel->reltarget,
extra->havingQual);
--
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
://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
16402
(4 rows)
--
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
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
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
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
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
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
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
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
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
1 - 100 of 161 matches
Mail list logo
