Обсуждение: Small bug on CREATE EXTENSION pgq...

Hackers; I noticed this trying to import a large pg_dump file with
warnings supressed.

It seems loading pgq sets client_min_messages to warning and leaves it
this way which defeats an attempt to change the setting prior and have
it stick.

I tested with several other extensions in same DB and only pgq has the
problem.

Sorry if this is known/fixed already.

Thanks


sj$ cat q
select version();

create database foo template template0;
\c foo

show client_min_messages;

create extension pgq;

show client_min_messages;
reset client_min_messages;
show client_min_messages;

create extension pgq_node;

show client_min_messages;

\c postgres

drop database foo;


sj$ /usr/local/postgresql-9.3/bin/psql -ef q  --no-psqlrc
select version();                                          version                                            
----------------------------------------------------------------------------------------------PostgreSQL 9.3.4 on
x86_64-unknown-linux-gnu,compiled by gcc (Debian 4.7.2-5) 4.7.2, 64-bit
 
(1 row)

create database foo template template0;
CREATE DATABASE
psql (9.3.5, server 9.3.4)
You are now connected to database "foo" as user "jsievers".
show client_min_messages;client_min_messages 
---------------------notice
(1 row)

create extension pgq;
CREATE EXTENSION
show client_min_messages;client_min_messages 
---------------------warning
(1 row)

reset client_min_messages;
RESET
show client_min_messages;client_min_messages 
---------------------notice
(1 row)

create extension pgq_node;
CREATE EXTENSION
show client_min_messages;client_min_messages 
---------------------notice
(1 row)

psql (9.3.5, server 9.3.4)
You are now connected to database "postgres" as user "jsievers".
drop database foo;
DROP DATABASE
sj$ 
-- 
Jerry Sievers
Postgres DBA/Development Consulting
e: postgres.consulting@comcast.net
p: 312.241.7800

Jerry Sievers-3 wrote
> Hackers; I noticed this trying to import a large pg_dump file with
> warnings supressed.
> 
> It seems loading pgq sets client_min_messages to warning and leaves it
> this way which defeats an attempt to change the setting prior and have
> it stick.
> 
> I tested with several other extensions in same DB and only pgq has the
> problem.
> 
> Sorry if this is known/fixed already.

This is not part of PostgreSQL proper and thus not supported by -hackers;
you should report this directly to the authors.

David J.



--
View this message in context: http://postgresql.nabble.com/Small-bug-on-CREATE-EXTENSION-pgq-tp5835899p5835900.html
Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.

* David G Johnston (david.g.johnston@gmail.com) wrote:
> Jerry Sievers-3 wrote
> > Hackers; I noticed this trying to import a large pg_dump file with
> > warnings supressed.
> >
> > It seems loading pgq sets client_min_messages to warning and leaves it
> > this way which defeats an attempt to change the setting prior and have
> > it stick.
> >
> > I tested with several other extensions in same DB and only pgq has the
> > problem.
> >
> > Sorry if this is known/fixed already.
>
> This is not part of PostgreSQL proper and thus not supported by -hackers;
> you should report this directly to the authors.

Ehh..  Shouldn't we try to take a bit more care that we reset things
after a CREATE EXTENSION is run?  Not really sure how much effort we
want to put into it, but I see a bit of blame on both sides here.
Thanks,
    Stephen

* David G Johnston (david.g.johnston@gmail.com) wrote:
> Jerry Sievers-3 wrote
> > Hackers; I noticed this trying to import a large pg_dump file with
> > warnings supressed.
> >
> > It seems loading pgq sets client_min_messages to warning and leaves it
> > this way which defeats an attempt to change the setting prior and have
> > it stick.
> >
> > I tested with several other extensions in same DB and only pgq has the
> > problem.
> >
> > Sorry if this is known/fixed already.
>
> This is not part of PostgreSQL proper and thus not supported by -hackers;
> you should report this directly to the authors.

Ehh..  Shouldn't we try to take a bit more care that we reset things
after a CREATE EXTENSION is run?  Not really sure how much effort we
want to put into it, but I see a bit of blame on both sides here.

* David Johnston (david.g.johnston@gmail.com) wrote:
> On Wednesday, January 28, 2015, Stephen Frost <sfrost@snowman.net> wrote:
> > Ehh..  Shouldn't we try to take a bit more care that we reset things
> > after a CREATE EXTENSION is run?  Not really sure how much effort we
> > want to put into it, but I see a bit of blame on both sides here.
>
> Fair enough but "reset" to what?  I don't know the internal mechanics but
> if the session default is "warning" and a local change sets it to "notice"
> then an unconditional reset would not get us back to the intended value.

Yeah, we'd really want to reset it to "what it was before."

> Now, if extensions can be handled similarly to how functions operate, where
> one can define function/extension -local settings and have them revert
> after resolution that might be ok.

That, imv, is really what should be happening inside the create
extension script..  I'm not anxious to look into how to make that happen
though.

> That said, while there isn't any way to prevent it the log_min GUCs should
> not be changed by extensions; that decision should be left up to the user.
> The complaint is not that it should be reset but that the installation
> script should not even care what the setting is.

I agree that the script really shouldn't be changing it.
Thanks!
    Stephen

Stephen Frost <sfrost@snowman.net> writes:
> * David Johnston (david.g.johnston@gmail.com) wrote:
>> Fair enough but "reset" to what?  I don't know the internal mechanics but
>> if the session default is "warning" and a local change sets it to "notice"
>> then an unconditional reset would not get us back to the intended value.

> Yeah, we'd really want to reset it to "what it was before."

An extension script runs as a single transaction, so SET LOCAL could've
been used to accomplish the result without trashing the session-lifespan
setting.

I'm not sure whether or not there was good reason to be changing the
setting at all, but it's entirely on the extension script's head that
it didn't do this in a less invasive way.
        regards, tom lane

On 1/28/15 10:25 PM, Tom Lane wrote:
> Stephen Frost <sfrost@snowman.net> writes:
>> * David Johnston (david.g.johnston@gmail.com) wrote:
>>> Fair enough but "reset" to what?  I don't know the internal mechanics but
>>> if the session default is "warning" and a local change sets it to "notice"
>>> then an unconditional reset would not get us back to the intended value.
>
>> Yeah, we'd really want to reset it to "what it was before."
>
> An extension script runs as a single transaction, so SET LOCAL could've
> been used to accomplish the result without trashing the session-lifespan
> setting.
>
> I'm not sure whether or not there was good reason to be changing the
> setting at all, but it's entirely on the extension script's head that
> it didn't do this in a less invasive way.

+1

One thing I have wished for is something akin to SET LOCAL that reverts at the end of a subtransaction. Typically I
onlyneed to tweak something like client_min_messages for a single command, so I'd prefer to
 

SAVEPOINT old_setting;
SET LOCAL blah;
command;
RELEASE old_setting;
-- 
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com