[HACKERS] Something is rotten in publication drop

Поиск
Список
Период
Сортировка
От Tom Lane
Тема [HACKERS] Something is rotten in publication drop
Дата
Msg-id 27692.1496980409@sss.pgh.pa.us
обсуждение исходный текст
Ответы Re: [HACKERS] Something is rotten in publication drop  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Список pgsql-hackers
I'm looking at this recent failure:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=mandrill&dt=2017-06-08%2023%3A54%3A12
which is

*** /home/nm/farm/xlc32/HEAD/pgsql.build/src/test/regress/expected/matview.out    Thu Jun  8 23:55:50 2017
--- /home/nm/farm/xlc32/HEAD/pgsql.build/src/test/regress/results/matview.out    Fri Jun  9 00:18:12 2017
***************
*** 155,171 ****  SET search_path = mvtest_mvschema, public; \d+ mvtest_tvm
!                       Materialized view "mvtest_mvschema.mvtest_tvm"
!  Column |  Type   | Collation | Nullable | Default | Storage  | Stats target | Description
! --------+---------+-----------+----------+---------+----------+--------------+-------------
!  type   | text    |           |          |         | extended |              |
!  totamt | numeric |           |          |         | main     |              |
! View definition:
!  SELECT mvtest_tv.type,
!     mvtest_tv.totamt
!    FROM mvtest_tv
!   ORDER BY mvtest_tv.type;
!  -- modify the underlying table data INSERT INTO mvtest_t VALUES (6, 'z', 13); -- confirm pre- and post-refresh
contentsof fairly simple materialized views 
--- 155,161 ----  SET search_path = mvtest_mvschema, public; \d+ mvtest_tvm
! ERROR:  publication "addr_pub" does not exist -- modify the underlying table data INSERT INTO mvtest_t VALUES (6,
'z',13); -- confirm pre- and post-refresh contents of fairly simple materialized views 

This appears to have something to do with the concurrently-running
object_address test script, which creates and then drops a publication
named "addr_pub".  However, there is no visible connection between
mvtest_tvm (or any of the objects it depends on) and addr_pub or any
of the objects it is told to publish.  So what happened here, and
isn't this a bug?
        regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] PostgreSQL 10 changes in exclusion constraints - did something change? CASE WHEN behavior oddity
Следующее
От: Thomas Munro
Дата:
Сообщение: Re: [HACKERS] transition table behavior with inheritance appearsbroken (was: Declarative partitioning - another take)