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 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 core are you talking about?
Also, it's not clear to me what do you mean by "bug in the standby" or
no lock in the drop index concurrently. Can you explain?
However, when our business will perform a large number of queries in
the standby, this problem will occur more frequently. So we are trying
to solve this problem, and the solution we are currently dealing with
is to ban it.
Hmm, so you observe the issue with regular queries, not just EXPLAIN
ANALYZE?
Of course, we considered applying the method of waiting to detect the
query lock on the master to the standby, but worried about affecting
the standby application log delay, so we gave up that.
I don't understand? What method?
If you have a better solution in the future, please push it to the new
version, or email it, thank you very much.
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
