Horton

Re: Fixing findDependentObjects()'s dependency on scan order (regressions in DROP diagnostic messages)

Andrei Lepikhov <a.lepikhov@postgrespro.ru>

View thread View on postgr.es
From: Andrey Lepikhov <a.lepikhov@postgrespro.ru>
To: Peter Geoghegan <pg@bowt.ie>
Cc: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>, Alvaro Herrera <alvherre@2ndquadrant.com>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2018-12-18T06:52:50Z
Lists: pgsql-hackers 

On 08.12.2018 6:58, Peter Geoghegan wrote:
>   I have no idea what you mean here. I'm proposing a patch that stops
> it being a game of chance, while preserving the existing
> slightly-random behavior to the greatest extent possible. I think that
> my patch would have stopped that problem altogether. Are you
> suggesting that it wouldn't have?

I did many tests of your solution inside the 'quick vacuum' strategy [1] 
and the background worker called 'heap cleaner' [2]. I must admit that 
when I  use your patch, there is no problem with dependencies.
This patch needs opinion of an another reviewer.

[1] 
https://www.postgresql.org/message-id/425db134-8bba-005c-b59d-56e50de3b41e%40postgrespro.ru
[2] 
https://www.postgresql.org/message-id/f49bb262-d246-829d-f835-3950ddac503c%40postgrespro.ru

-- 
Andrey Lepikhov
Postgres Professional
https://postgrespro.com
The Russian Postgres Company

Commits

  1. Redesign the partition dependency mechanism.

  2. Fix trigger drop procedure

  3. Sort the dependent objects before recursing in findDependentObjects().

  4. Avoid sometimes printing both tables and their columns in DROP CASCADE.