Обсуждение: [GENERAL] After upgrade to 9.6: waiting column does not exist

Поиск
Список
Период
Сортировка

[GENERAL] After upgrade to 9.6: waiting column does not exist

От
Johann Spies
Дата:
We did a pg_upgrade from 9.5 to 9.6

Now, when running the 9.6 server the following error message shows up regularly in the log:

postgres@template1 ERROR:  column "waiting" does not exist at character 217


As far as I understand the following remark in the release notes, the column 'waiting'  should not exist:

  • Improve the pg_stat_activity view's information about what a process is waiting for (Amit Kapila, Ildus Kurbangaliev)

    Historically a process has only been shown as waiting if it was waiting for a heavyweight lock. Now waits for lightweight locks and buffer pins are also shown in pg_stat_activity. Also, the type of lock being waited for is now visible. These changes replace the waiting column with wait_event_type and wait_event.


How do I correct this?

Regards
Johann

--
Because experiencing your loyal love is better than life itself,
my lips will praise you.  (Psalm 63:3)

Re: [GENERAL] After upgrade to 9.6: waiting column does not exist

От
John R Pierce
Дата:
On 12/8/2016 11:59 PM, Johann Spies wrote:
Now, when running the 9.6 server the following error message shows up regularly in the log:

postgres@template1 ERROR:  column "waiting" does not exist at character 217


As far as I understand the following remark in the release notes, the column 'waiting'  should not exist:

  • Improve the pg_stat_activity view's information about what a process is waiting for (Amit Kapila, Ildus Kurbangaliev)

    Historically a process has only been shown as waiting if it was waiting for a heavyweight lock. Now waits for lightweight locks and buffer pins are also shown in pg_stat_activity. Also, the type of lock being waited for is now visible. These changes replace the waiting column with wait_event_type and wait_event.


How do I correct this?

are you running some sort of monitoring software thats periodically looking at pg_stat_activity ?   whatever query its doing needs to be rewritten to take into account the pg_stat_activity changes in 9.6


-- 
john r pierce, recycling bits in santa cruz

Re: [GENERAL] After upgrade to 9.6: waiting column does not exist

От
Achilleas Mantzios
Дата:
On 09/12/2016 10:04, John R Pierce wrote:
On 12/8/2016 11:59 PM, Johann Spies wrote:
Now, when running the 9.6 server the following error message shows up regularly in the log:

postgres@template1 ERROR:  column "waiting" does not exist at character 217


As far as I understand the following remark in the release notes, the column 'waiting'  should not exist:

  • Improve the pg_stat_activity view's information about what a process is waiting for (Amit Kapila, Ildus Kurbangaliev)

    Historically a process has only been shown as waiting if it was waiting for a heavyweight lock. Now waits for lightweight locks and buffer pins are also shown in pg_stat_activity. Also, the type of lock being waited for is now visible. These changes replace the waiting column with wait_event_type and wait_event.


How do I correct this?

are you running some sort of monitoring software thats periodically looking at pg_stat_activity ?   whatever query its doing needs to be rewritten to take into account the pg_stat_activity changes in 9.6


Also It would help to modify your log line prefix (log_line_prefix) to include client's address, PID, and application name.

-- 
john r pierce, recycling bits in santa cruz


-- 
Achilleas Mantzios
IT DEV Lead
IT DEPT
Dynacom Tankers Mgmt

Re: [GENERAL] After upgrade to 9.6: waiting column does not exist

От
Johann Spies
Дата:


On 9 December 2016 at 10:13, Achilleas Mantzios <achill@matrix.gatewaynet.com> wrote:

On 09/12/2016 10:04, John R Pierce wrote:

are you running some sort of monitoring software thats periodically looking at pg_stat_activity ?   whatever query its doing needs to be rewritten to take into account the pg_stat_activity changes in 9.6


Thanks John.  I see munin queries the 'waiting'  column.

Also It would help to modify your log line prefix (log_line_prefix) to include client's address, PID, and application name.


Thanks for the hint Achilleas.  It makes a lot of sense.

Regards
Johann
--
Because experiencing your loyal love is better than life itself,
my lips will praise you.  (Psalm 63:3)