Thread: PGAdmin4 2.1 OSX Query Tool - messages delayed by one execution
I'm noticing that when executing a batch with multiple statements, the messages returned by the second statement onwards are kept over to the next execution and appear before the first message from the new batch. Steps to reproduce: Compile the following function which raises a notice: create or replace function noticetest (vIn varchar) returns varchar as $$ begin raise notice 'You said %', vIn; return vIn; end $$ language plpgsql; Then in a Query Tool window, execute the following statements in a single execution: select noticetest('One'); select noticetest('Two'); Observe the Messages pane, which displays the output: NOTICE: You said One Successfully run. Total query runtime: 91 msec. 1 rows affected. Only the first message is shown in the window, the notice raised from the second statement is not shown. Now execute the following statement in the same execution: select noticetest('Three'); select noticetest('Four'); And observe the Messages pane: NOTICE: You said Two NOTICE: You said Three Successfully run. Total query runtime: 75 msec. 1 rows affected. The missing message from the first execution appears along with only the notice raised in the first statement of the second batch executed. Finally, execute a single statement: The messages pane shows: select noticetest('Five'); NOTICE: You said Four NOTICE: You said Five Successfully run. Total query runtime: 67 msec. 1 rows affected. Again the same behaviour as before. It seems that PgAdmin doesn't fully read the message array from each multi-statement execution, only the first but then somehow catches up prior to the next execution, falling behind again if there's multiple statements. As the results window only shows the last result set, I use notices a fair bit for dba functions that are frequently executed in batch to keep track of the non-critical success state of individual operations. It'd be nice if I could see the outcome of notices raised without having to execute a second batch. The workaround currently is to execute a separate statement after the main batch e.g.: select ''; .. and observe the message output in that execution. Thanks, Neil. -- Sent from: http://www.postgresql-archive.org/PostgreSQL-pgadmin-support-f2191615.html
Hi,
The similar issue has been reported by another user and the work is in progress to fix it. You can add the extra information in the same RM.
Thanks,
Khushboo
On Thu, Feb 22, 2018 at 1:27 PM, iPeel <dabs@peely.com> wrote:
I'm noticing that when executing a batch with multiple statements, the
messages returned by the second statement onwards are kept over to the next
execution and appear before the first message from the new batch.
Steps to reproduce:
Compile the following function which raises a notice:
create or replace function noticetest (vIn varchar) returns varchar as
$$
begin
raise notice 'You said %', vIn;
return vIn;
end
$$
language plpgsql;
Then in a Query Tool window, execute the following statements in a single
execution:
select noticetest('One');
select noticetest('Two');
Observe the Messages pane, which displays the output:
NOTICE: You said One
Successfully run. Total query runtime: 91 msec.
1 rows affected.
Only the first message is shown in the window, the notice raised from the
second statement is not shown. Now execute the following statement in the
same execution:
select noticetest('Three');
select noticetest('Four');
And observe the Messages pane:
NOTICE: You said Two
NOTICE: You said Three
Successfully run. Total query runtime: 75 msec.
1 rows affected.
The missing message from the first execution appears along with only the
notice raised in the first statement of the second batch executed. Finally,
execute a single statement:
The messages pane shows:
select noticetest('Five');
NOTICE: You said Four
NOTICE: You said Five
Successfully run. Total query runtime: 67 msec.
1 rows affected.
Again the same behaviour as before. It seems that PgAdmin doesn't fully read
the message array from each multi-statement execution, only the first but
then somehow catches up prior to the next execution, falling behind again if
there's multiple statements.
As the results window only shows the last result set, I use notices a fair
bit for dba functions that are frequently executed in batch to keep track of
the non-critical success state of individual operations. It'd be nice if I
could see the outcome of notices raised without having to execute a second
batch.
The workaround currently is to execute a separate statement after the main
batch e.g.:
select '';
.. and observe the message output in that execution.
Thanks,
Neil.
--
Sent from: http://www.postgresql-archive.org/PostgreSQL-pgadmin- support-f2191615.html
Bug 3094 updated. -- Sent from: http://www.postgresql-archive.org/PostgreSQL-pgadmin-support-f2191615.html