Hi, David
Your answer explains that we still need to ModifyTable node without Leaf
partitions.
You are right about this.
But you can review the source code again,
```
/*
* Fetch rows from subplan, and execute the required table modification
* for each row.
Hi hackers,
Recently, I noticed a great patch in pg 14.
"Rework planning and execution of UPDATE and DELETE.
(86dc90056dfdbd9d1b891718d2e5614e3e432f35)"
This changes the DML execution of the partitioned table and makes it more
friendly.
But I am very confused about the following changes:
```
+
Hi commiter,
Many of our customers expect to use BR triggers in partitioned tables.
After I followed your discussion, I also checked your patch.
Here are two questions confusing me:
1. Your modification removes the check BR triggers against partitioned table,
and a more friendly error message i
Hi commiter,
Many of our customers expect to use BR triggers in partitioned tables.
After I followed your discussion, I also checked your patch.
Here are two questions confusing me:
1. Your modification removes the check BR triggers against partitioned table,
and a more friendly error message i
sistent.
Do you think that scheme is more suitable for CIC?
Thank you very much,
Regards, Adger
--
发件人：Michael Paquier
发送时间：2020年6月18日(星期四) 10:41
收件人：李杰(慎追)
抄 送：Justin Pryzby ; pgsql-hackers
; 曾文旌(义从) ;
Alvaro Herrera
主
> We can refer to the implementation in the ReindexRelationConcurrently,
> in the three phases of the REINDEX CONCURRENTLY,
> all indexes of the partitions are operated one by one in each phase.
> In this way, we can maintain the consistency of the entire partitioned table
> index.
> After we impl
Jsutin,
Which scheme do you think is more helpful to realize CIC?
----------
发件人：Michael Paquier
发送时间：2020年6月16日(星期二) 09:02
收件人：李杰(慎追)
抄 送：Justin Pryzby ; pgsql-hackers
; 曾文旌(义从) ;
Alvaro Herrera
主 题：Re: 回复：回复：how to create index conc
s to use frequently,
the creation of other partition indexes is delayed.
Is it worth doing this?
Regards, Adger
--
发件人：Michael Paquier
发送时间：2020年6月15日(星期一) 20:37
收件人：李杰(慎追)
抄 送：Justin Pryzby ; pgsql-hackers
; 曾文旌(义从) ;
Alvaro
ror.
Therefore, in our first case, it should not be what we expected that the third
partition has no index.
That is to say, when our CIC goes wrong, either roll back all or go down
instead of stopping in the middle.
This is my shallow opinion, please take it as your reference.
Thank you
Hi Justin,
> Maybe I'm wrong, but I don't think there's any known difficulty - just that>
> nobody did it yet. You should pay attention to what happens on error, but
> hopefully you wouldn't need to add much code and can rely on existing code to
> paths to handle that right.
yes, I am trying t
>On Sat, Jun 06, 2020 at 09:23:32AM -0500, Justin Pryzby wrote:
> > On Wed, Jun 03, 2020 at 08:22:29PM +0800, 李杰(慎追) wrote:
> > > Partitioning is necessary for very large tables.
> > > However, I found that postgresql does not support create index
> > >
Hi hackers,
Partitioning is necessary for very large tables.
However, I found that postgresql does not support create index concurrently on
partitioned tables.
The document show that we need to create an index on each partition
individually and then finally create the partitioned index non-conc
elay to the log apply on standb, resulting in
inconsistent data between the master and the standby.
All in all, I think this bug is a flaw in postgres design. We need to think
carefully about how to handle it better. Even we can learn from other database
products. I hope I can help you.
Thank you very much for your attention.
Regards.
adg
年10月23日(星期三) 06:49
收件人：李杰(慎追)
抄 送：pgsql-hackers
主 题：Re: Bug about drop index concurrently
On Fri, Oct 18, 2019 at 05:00:54PM +0200, Tomas Vondra wrote:
>Hi,
>
>I can trivially reproduce this - it's enough to create a master-standby
>setup, and then do this on the master
>
>
ng the standby application
log delay, so we gave up that.
--
发件人：Tomas Vondra
发送时间：2019年10月23日(星期三) 01:47
收件人：李杰(慎追)
抄 送：pgsql-hackers
主 题：Re: 回复：Bug about drop index concurrently
On Mon, Oct 21, 2019 at 10:36:04AM +0800, 李杰(慎追)
.
--
发件人：Tomas Vondra
发送时间：2019年10月19日(星期六) 02:00
收件人：李杰(慎追)
抄 送：pgsql-hackers
主 题：Re: Bug about drop index concurrently
Hi,
I can trivially reproduce this - it's enough to create a master-standby
setup, and then do this on the m
：李杰(慎追)
抄 送：pgsql-hackers
主 题：Re: Bug about drop index concurrently
Hi,
I can trivially reproduce this - it's enough to create a master-standby
setup, and then do this on the master
CREATE TABLE t (a int, b int);
INSERT INTO t SELECT i, i FROM generate_series(1,1) s(i);
and run pg
Hi hackers,
In recently, I discovered a postgres bug, and I hope I can ask you for the best
solution.
The problem is as follows:
postgres=# explain analyze select * from xxx where a=500;
ERROR: could not open relation with OID 25989
The structure of my table is as follows:
postgres=# \d xxx
Ta
18 matches
Mail list logo
