回复：回复：回复：Bug about drop index concurrently

2019-10-23 Thread 李杰(慎追)
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

Re: 回复：回复：Bug about drop index concurrently

2019-10-23 Thread Tomas Vondra
On Wed, Oct 23, 2019 at 02:38:45PM +0800, 李杰(慎追) wrote: I'm a bit confused. You shouldn't see any crashes and/or core files in this scenario, for two reasons. Firstly, I assume you're running a regular build without asserts. Secondly, I had to add an extra assert to trigger the failure. So what

回复：Bug about drop index concurrently

2019-10-22 Thread 李杰(慎追)
年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 > >

回复：回复：Bug about drop index concurrently

2019-10-22 Thread 李杰(慎追)
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, 李杰(慎追)

Re: Bug about drop index concurrently

2019-10-22 Thread Tomas Vondra
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 CREATE TABLE t (a int, b int); INSERT INTO t SELECT i, i FROM generate_series(1,1) s(i); and run pgbench with this

Re: 回复：Bug about drop index concurrently

2019-10-22 Thread Tomas Vondra
On Tue, Oct 22, 2019 at 03:24:41PM +0800, 李杰(慎追) wrote: Hi all, I am sorry to bother you again. I want to consult again, about the last time I raised a bug about drop index, are you going to deal with it in the future? Is it to ban it or to propose a repair plan, what is your next plan? It d

Re: 回复：Bug about drop index concurrently

2019-10-22 Thread Tomas Vondra
On Mon, Oct 21, 2019 at 10:36:04AM +0800, 李杰(慎追) wrote: Thanks for the quick reply. And sorry I haven’t got back to you sooner . I have seen this backtrace in the core file, and I also looked at the bug in the standby because there is no lock in the drop index concurrently. I'm a bit confuse

回复：Bug about drop index concurrently

2019-10-22 Thread 李杰(慎追)
. -- 发件人：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

回复：Bug about drop index concurrently

2019-10-20 Thread 李杰(慎追)
：李杰(慎追) 抄　送：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

Re: Bug about drop index concurrently

2019-10-18 Thread Tomas Vondra
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 pgbench with this script DROP INDEX CONCURRENTLY IF EXISTS t_a_idx; CREATE

Bug about drop index concurrently

2019-10-16 Thread 李杰(慎追)
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