agora inbox for pgsql-hackers@postgresql.org
help / color / mirror / Atom feeddisplay previous query string of idle-in-transaction
32+ messages / 15 participants
[nested] [flat]
* display previous query string of idle-in-transaction
@ 2009-03-25 09:08 Tatsuhito Kasahara <kasahara.tatsuhito@oss.ntt.co.jp>
2009-03-25 09:59 ` Re: display previous query string of idle-in-transaction Gurjeet Singh <singh.gurjeet@gmail.com>
2009-03-25 16:48 ` Re: display previous query string of idle-in-transaction hubert depesz lubaczewski <depesz@depesz.com>
2009-03-26 18:14 ` Re: display previous query string of idle-in-transaction Simon Riggs <simon@2ndQuadrant.com>
0 siblings, 3 replies; 32+ messages in thread
From: Tatsuhito Kasahara @ 2009-03-25 09:08 UTC (permalink / raw)
To: pgsql-hackers
Hi.
Now, we can check the running query string by pg_stat_activity.current_query.
If we can also check previous query_string of idle-in-transaction,
it is useful for analysis of long transaction problem.
Long-transaction is a trouble, because it prevents defragmentation of HOT and VACUUM.
And long-transaction tends to be it in a state of "idle in transaction".
(BEGIN -> SOME SQL -> .... (long-transactin) ....)
So, I sometimes want to know what query (main cause) was done before
transaction which have been practiced for a long time.
I think that we are glad when we can confirm it in the following form.
# We will be able to use debug_query_string in postgres.c for this purpose.
=================================================================
=# SELECT current_query FROM pg_stat_activity
WHERE procpid <> pg_backend_pid();
current_query
---------------------------------------------------------------
<IDLE> in transaction [prev]: SELECT * FROM pg_class limit 1;
=================================================================
Thoughts?
Best regards.
--
Tatsuhito Kasahara
kasahara.tatsuhito@oss.ntt.co.jp
^ permalink raw reply [nested|flat] 32+ messages in thread
* Re: display previous query string of idle-in-transaction
2009-03-25 09:08 display previous query string of idle-in-transaction Tatsuhito Kasahara <kasahara.tatsuhito@oss.ntt.co.jp>
@ 2009-03-25 09:59 ` Gurjeet Singh <singh.gurjeet@gmail.com>
2 siblings, 0 replies; 32+ messages in thread
From: Gurjeet Singh @ 2009-03-25 09:59 UTC (permalink / raw)
To: Tatsuhito Kasahara <kasahara.tatsuhito@oss.ntt.co.jp>; +Cc: pgsql-hackers
This sure is a desirable feature. I have seen quite a few instances, where
the app is in 'IDLE in Transaction' state, and we are left with the only
choice of killing such processes from OS. (Remember pg_cancel_backend() does
not work for sessions in IDLE or IDLE in transaction state)
Also, it should be introduced as a new column, rather than tacking on the
existing string. Although this column will be of little use in cases where
current query is visible, but having a separate column looks like a cleaner
and simpler implementation.
Best regards,
2009/3/25 Tatsuhito Kasahara <kasahara.tatsuhito@oss.ntt.co.jp>
> Hi.
>
> Now, we can check the running query string by
> pg_stat_activity.current_query.
> If we can also check previous query_string of idle-in-transaction,
> it is useful for analysis of long transaction problem.
>
> Long-transaction is a trouble, because it prevents defragmentation of HOT
> and VACUUM.
> And long-transaction tends to be it in a state of "idle in transaction".
> (BEGIN -> SOME SQL -> .... (long-transactin) ....)
>
> So, I sometimes want to know what query (main cause) was done before
> transaction which have been practiced for a long time.
>
> I think that we are glad when we can confirm it in the following form.
> # We will be able to use debug_query_string in postgres.c for this purpose.
>
> =================================================================
> =# SELECT current_query FROM pg_stat_activity
> WHERE procpid <> pg_backend_pid();
>
> current_query
> ---------------------------------------------------------------
> <IDLE> in transaction [prev]: SELECT * FROM pg_class limit 1;
>
> =================================================================
>
> Thoughts?
>
> Best regards.
>
> --
> Tatsuhito Kasahara
> kasahara.tatsuhito@oss.ntt.co.jp
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>
--
gurjeet[.singh]@EnterpriseDB.com
singh.gurjeet@{ gmail | hotmail | indiatimes | yahoo }.com
EnterpriseDB http://www.enterprisedb.com
Mail sent from my BlackLaptop device
^ permalink raw reply [nested|flat] 32+ messages in thread
* Re: display previous query string of idle-in-transaction
2009-03-25 09:08 display previous query string of idle-in-transaction Tatsuhito Kasahara <kasahara.tatsuhito@oss.ntt.co.jp>
@ 2009-03-25 16:48 ` hubert depesz lubaczewski <depesz@depesz.com>
2009-03-25 17:07 ` Re: display previous query string of idle-in-transaction Guillaume Smet <guillaume.smet@gmail.com>
2 siblings, 1 reply; 32+ messages in thread
From: hubert depesz lubaczewski @ 2009-03-25 16:48 UTC (permalink / raw)
To: Tatsuhito Kasahara <kasahara.tatsuhito@oss.ntt.co.jp>; +Cc: pgsql-hackers
On Wed, Mar 25, 2009 at 06:08:43PM +0900, Tatsuhito Kasahara wrote:
> So, I sometimes want to know what query (main cause) was done before
> transaction which have been practiced for a long time.
> Thoughts?
I would love to get it, but when I suggested it some time in the past
Tom shot it down as bad idea.
http://archives.postgresql.org/message-id/20071016132131.GA4438@depesz.com
To be honest - I have yet to see case described by Ton (commit; begin;).
Best regards,
depesz
--
Linkedin: http://www.linkedin.com/in/depesz / blog: http://www.depesz.com/
jid/gtalk: depesz@depesz.com / aim:depeszhdl / skype:depesz_hdl / gg:6749007
^ permalink raw reply [nested|flat] 32+ messages in thread
* Re: display previous query string of idle-in-transaction
2009-03-25 09:08 display previous query string of idle-in-transaction Tatsuhito Kasahara <kasahara.tatsuhito@oss.ntt.co.jp>
2009-03-25 16:48 ` Re: display previous query string of idle-in-transaction hubert depesz lubaczewski <depesz@depesz.com>
@ 2009-03-25 17:07 ` Guillaume Smet <guillaume.smet@gmail.com>
2009-03-26 08:16 ` Re: display previous query string of idle-in-transaction Tatsuhito Kasahara <kasahara.tatsuhito@oss.ntt.co.jp>
0 siblings, 1 reply; 32+ messages in thread
From: Guillaume Smet @ 2009-03-25 17:07 UTC (permalink / raw)
To: depesz@depesz.com; +Cc: Tatsuhito Kasahara <kasahara.tatsuhito@oss.ntt.co.jp>; pgsql-hackers
On Wed, Mar 25, 2009 at 5:48 PM, hubert depesz lubaczewski
<depesz@depesz.com> wrote:
> I would love to get it, but when I suggested it some time in the past
> Tom shot it down as bad idea.
>
> http://archives.postgresql.org/message-id/20071016132131.GA4438@depesz.com
I agree with Tom here. I tracked a lot of idle in transaction problems
and you need the whole sequence of queries of all the backends to
really understand what happens.
The last query executed is mostly useless to solve this sort of
problem. At least, it was for me in every case I had to deal with.
--
Guillaume
^ permalink raw reply [nested|flat] 32+ messages in thread
* Re: display previous query string of idle-in-transaction
2009-03-25 09:08 display previous query string of idle-in-transaction Tatsuhito Kasahara <kasahara.tatsuhito@oss.ntt.co.jp>
2009-03-25 16:48 ` Re: display previous query string of idle-in-transaction hubert depesz lubaczewski <depesz@depesz.com>
2009-03-25 17:07 ` Re: display previous query string of idle-in-transaction Guillaume Smet <guillaume.smet@gmail.com>
@ 2009-03-26 08:16 ` Tatsuhito Kasahara <kasahara.tatsuhito@oss.ntt.co.jp>
2009-03-26 09:21 ` Re: display previous query string of idle-in-transaction ITAGAKI Takahiro <itagaki.takahiro@oss.ntt.co.jp>
0 siblings, 1 reply; 32+ messages in thread
From: Tatsuhito Kasahara @ 2009-03-26 08:16 UTC (permalink / raw)
To: Guillaume Smet <guillaume.smet@gmail.com>; +Cc: depesz@depesz.com; pgsql-hackers
Guillaume Smet wrote:
> On Wed, Mar 25, 2009 at 5:48 PM, hubert depesz lubaczewski
> <depesz@depesz.com> wrote:
>> I would love to get it, but when I suggested it some time in the past
>> Tom shot it down as bad idea.
>>
>> http://archives.postgresql.org/message-id/20071016132131.GA4438@depesz.com
>
> I agree with Tom here. I tracked a lot of idle in transaction problems
> and you need the whole sequence of queries of all the backends to
> really understand what happens.
> The last query executed is mostly useless to solve this sort of
> problem. At least, it was for me in every case I had to deal with.
I think so too. But last-query-string may be a useful *hint*.
It is a hard work to trace the whole sequence of queries.
In most cases, last query string is enough information to solve the
long transaction problem. And I want a easy way to get the informarion.
# last query string is also a key to trace queries.
"COMMIT;BEGIN;idle in transaction" is not a problem on 8.3 or later, but
"(BEGIN;)SOME SQL;idle in transaction" is a problem.
So, main purpose of displaying the last query string is ..
- check whether "idle in transaction (running long time) process
after SOME SQL" is exists or not.
- check the content of "SOME SQL".
best regards,
--
Tatsuhito Kasahara
kasahara.tatsuhito@oss.ntt.co.jp
^ permalink raw reply [nested|flat] 32+ messages in thread
* Re: display previous query string of idle-in-transaction
2009-03-25 09:08 display previous query string of idle-in-transaction Tatsuhito Kasahara <kasahara.tatsuhito@oss.ntt.co.jp>
2009-03-25 16:48 ` Re: display previous query string of idle-in-transaction hubert depesz lubaczewski <depesz@depesz.com>
2009-03-25 17:07 ` Re: display previous query string of idle-in-transaction Guillaume Smet <guillaume.smet@gmail.com>
2009-03-26 08:16 ` Re: display previous query string of idle-in-transaction Tatsuhito Kasahara <kasahara.tatsuhito@oss.ntt.co.jp>
@ 2009-03-26 09:21 ` ITAGAKI Takahiro <itagaki.takahiro@oss.ntt.co.jp>
2009-03-26 11:00 ` Re: display previous query string of idle-in-transaction Tatsuhito Kasahara <kasahara.tatsuhito@oss.ntt.co.jp>
0 siblings, 1 reply; 32+ messages in thread
From: ITAGAKI Takahiro @ 2009-03-26 09:21 UTC (permalink / raw)
To: Tatsuhito Kasahara <kasahara.tatsuhito@oss.ntt.co.jp>; +Cc: Guillaume Smet <guillaume.smet@gmail.com>; depesz@depesz.com; pgsql-hackers
Tatsuhito Kasahara <kasahara.tatsuhito@oss.ntt.co.jp> wrote:
> So, main purpose of displaying the last query string is ..
> - check whether "idle in transaction (running long time) process
> after SOME SQL" is exists or not.
> - check the content of "SOME SQL".
The feature could be achieved by an extension module using new executor
hooks in 8.4. It is just like contrib/pg_stat_statements; Backends store
their queries history in process-local or shared memory. If you store
queries in local memory, you could dump them at some of callback routines
called at the end of transaction. On the other hand, if you use shared
memory, it might be possitble to define a SRF function which return history
of queries:
CREATE FUNCTION query_history(backend_pid integer) RETURNS SETOF text;
Required memory for query history is not so much.
"1kB of query text * 100 connection * 10 queries" consumes just 1MB.
You can discard old queries at the end of transaction or out of memory.
If there are some interesting queries in it, you can dump them into
server logs. For example, logging configurations something like
'idle_in_transaction_min_duration' and 'total_transaction_min_duration'
will be possible.
I'm not sure this feature should be in the core or not.
Regards,
---
ITAGAKI Takahiro
NTT Open Source Software Center
^ permalink raw reply [nested|flat] 32+ messages in thread
* Re: display previous query string of idle-in-transaction
2009-03-25 09:08 display previous query string of idle-in-transaction Tatsuhito Kasahara <kasahara.tatsuhito@oss.ntt.co.jp>
2009-03-25 16:48 ` Re: display previous query string of idle-in-transaction hubert depesz lubaczewski <depesz@depesz.com>
2009-03-25 17:07 ` Re: display previous query string of idle-in-transaction Guillaume Smet <guillaume.smet@gmail.com>
2009-03-26 08:16 ` Re: display previous query string of idle-in-transaction Tatsuhito Kasahara <kasahara.tatsuhito@oss.ntt.co.jp>
2009-03-26 09:21 ` Re: display previous query string of idle-in-transaction ITAGAKI Takahiro <itagaki.takahiro@oss.ntt.co.jp>
@ 2009-03-26 11:00 ` Tatsuhito Kasahara <kasahara.tatsuhito@oss.ntt.co.jp>
0 siblings, 0 replies; 32+ messages in thread
From: Tatsuhito Kasahara @ 2009-03-26 11:00 UTC (permalink / raw)
To: ITAGAKI Takahiro <itagaki.takahiro@oss.ntt.co.jp>; +Cc: Guillaume Smet <guillaume.smet@gmail.com>; depesz@depesz.com; pgsql-hackers
ITAGAKI Takahiro wrote:
> The feature could be achieved by an extension module using new executor
> hooks in 8.4. It is just like contrib/pg_stat_statements;
Well, it is a good idea.
Displaying last-query-string may be useful, but it is not a feature for
general purpose. So, it may be an external module.
Now, I have two choice.
1. Displaying last-query-string by pg_stat_activity (suggested by Gurjeet):
Extends the pg_stat_activity to display "previous_query".
We can check only a previous query.
2. Displaying query-string-history by external module (suggested by Itagaki):
Using executor hook to get a query string and stores it in
shared memory.
We can check specified number of query string history.
I think I will try mainly 2.
# Or this feature may merge to pg_stat_statements.
Any comments welcome.
Best regards,
--
Tatsuhito Kasahara
kasahara.tatsuhito@oss.ntt.co.jp
^ permalink raw reply [nested|flat] 32+ messages in thread
* Re: display previous query string of idle-in-transaction
2009-03-25 09:08 display previous query string of idle-in-transaction Tatsuhito Kasahara <kasahara.tatsuhito@oss.ntt.co.jp>
@ 2009-03-26 18:14 ` Simon Riggs <simon@2ndQuadrant.com>
2009-03-27 06:44 ` Re: display previous query string of idle-in-transaction Tatsuhito Kasahara <kasahara.tatsuhito@oss.ntt.co.jp>
2 siblings, 1 reply; 32+ messages in thread
From: Simon Riggs @ 2009-03-26 18:14 UTC (permalink / raw)
To: Tatsuhito Kasahara <kasahara.tatsuhito@oss.ntt.co.jp>; +Cc: pgsql-hackers
On Wed, 2009-03-25 at 18:08 +0900, Tatsuhito Kasahara wrote:
> If we can also check previous query_string of idle-in-transaction,
> it is useful for analysis of long transaction problem.
I'm more interested in the problem itself. Why do you think there is a
problem and why does knowing this help you? I had similar problems
recently, so I'm interested in thoughts around this.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
^ permalink raw reply [nested|flat] 32+ messages in thread
* Re: display previous query string of idle-in-transaction
2009-03-25 09:08 display previous query string of idle-in-transaction Tatsuhito Kasahara <kasahara.tatsuhito@oss.ntt.co.jp>
2009-03-26 18:14 ` Re: display previous query string of idle-in-transaction Simon Riggs <simon@2ndQuadrant.com>
@ 2009-03-27 06:44 ` Tatsuhito Kasahara <kasahara.tatsuhito@oss.ntt.co.jp>
2009-03-27 07:27 ` Re: display previous query string of idle-in-transaction Guillaume Smet <guillaume.smet@gmail.com>
2009-03-27 07:36 ` Re: display previous query string of idle-in-transaction Simon Riggs <simon@2ndQuadrant.com>
0 siblings, 2 replies; 32+ messages in thread
From: Tatsuhito Kasahara @ 2009-03-27 06:44 UTC (permalink / raw)
To: Simon Riggs <simon@2ndQuadrant.com>; +Cc: pgsql-hackers
Simon Riggs wrote:
>> If we can also check previous query_string of idle-in-transaction,
>> it is useful for analysis of long transaction problem.
>
> I'm more interested in the problem itself. Why do you think there is a
> problem and why does knowing this help you? I had similar problems
> recently, so I'm interested in thoughts around this.
In many case, applications don't know what queries they are doing.
So, if a long transaction problem (unworking defragmnetation by HOT and
VACUUM) occured, I don't understand which application is the cause with
only "<IDLE> in transaction" message.
But if I can also check last query string, I guess which apllication
do that and point out the problem point.
# As I said, I think a long transaction is not a problem itself.
Does that answer your question ?
Best regards,
--
Tatsuhito Kasahara
kasahara.tatsuhito@oss.ntt.co.jp
^ permalink raw reply [nested|flat] 32+ messages in thread
* Re: display previous query string of idle-in-transaction
2009-03-25 09:08 display previous query string of idle-in-transaction Tatsuhito Kasahara <kasahara.tatsuhito@oss.ntt.co.jp>
2009-03-26 18:14 ` Re: display previous query string of idle-in-transaction Simon Riggs <simon@2ndQuadrant.com>
2009-03-27 06:44 ` Re: display previous query string of idle-in-transaction Tatsuhito Kasahara <kasahara.tatsuhito@oss.ntt.co.jp>
@ 2009-03-27 07:27 ` Guillaume Smet <guillaume.smet@gmail.com>
2009-03-27 07:38 ` Re: display previous query string of idle-in-transaction Guillaume Smet <guillaume.smet@gmail.com>
1 sibling, 1 reply; 32+ messages in thread
From: Guillaume Smet @ 2009-03-27 07:27 UTC (permalink / raw)
To: Tatsuhito Kasahara <kasahara.tatsuhito@oss.ntt.co.jp>; +Cc: Simon Riggs <simon@2ndquadrant.com>; pgsql-hackers
2009/3/27 Tatsuhito Kasahara <kasahara.tatsuhito@oss.ntt.co.jp>:
> But if I can also check last query string, I guess which apllication
> do that and point out the problem point.
Oh, I just understand why you want this patch. I usually have one
database per server so I didn't see your point.
Considering this usage, +1 for me.
--
Guillaume
^ permalink raw reply [nested|flat] 32+ messages in thread
* Re: display previous query string of idle-in-transaction
2009-03-25 09:08 display previous query string of idle-in-transaction Tatsuhito Kasahara <kasahara.tatsuhito@oss.ntt.co.jp>
2009-03-26 18:14 ` Re: display previous query string of idle-in-transaction Simon Riggs <simon@2ndQuadrant.com>
2009-03-27 06:44 ` Re: display previous query string of idle-in-transaction Tatsuhito Kasahara <kasahara.tatsuhito@oss.ntt.co.jp>
2009-03-27 07:27 ` Re: display previous query string of idle-in-transaction Guillaume Smet <guillaume.smet@gmail.com>
@ 2009-03-27 07:38 ` Guillaume Smet <guillaume.smet@gmail.com>
2009-03-30 07:08 ` Re: display previous query string of idle-in-transaction Tatsuhito Kasahara <kasahara.tatsuhito@oss.ntt.co.jp>
0 siblings, 1 reply; 32+ messages in thread
From: Guillaume Smet @ 2009-03-27 07:38 UTC (permalink / raw)
To: Tatsuhito Kasahara <kasahara.tatsuhito@oss.ntt.co.jp>; +Cc: Simon Riggs <simon@2ndquadrant.com>; pgsql-hackers
On Fri, Mar 27, 2009 at 8:27 AM, Guillaume Smet
<guillaume.smet@gmail.com> wrote:
> 2009/3/27 Tatsuhito Kasahara <kasahara.tatsuhito@oss.ntt.co.jp>:
>> But if I can also check last query string, I guess which apllication
>> do that and point out the problem point.
>
> Oh, I just understand why you want this patch. I usually have one
> database per server so I didn't see your point.
Thinking a bit more about it: the datname column in the
pg_stat_activity view gives you the database concerned and usename the
user used. So I still don't see your point: you can use different user
to distinguish the applications.
Moreover, if you're using connection pooling (which is more and more
common) and the same user for connecting to the database, you won't be
able to know if it's really the last query which causes the problem
(from my experience, it's usually not).
Being able to detect which application is running which query on the
very same database with the very same user seems like something not so
obvious and the use case seems to be pretty narrow. And IMHO, even if
we suppose you can make the difference between the applications with
only one query, you won't be able to limit your investigation to this
application.
So, in fact, I'm still not convinced. Could you detail a bit more how
you plan to use it?
--
Guillaume
^ permalink raw reply [nested|flat] 32+ messages in thread
* Re: display previous query string of idle-in-transaction
2009-03-25 09:08 display previous query string of idle-in-transaction Tatsuhito Kasahara <kasahara.tatsuhito@oss.ntt.co.jp>
2009-03-26 18:14 ` Re: display previous query string of idle-in-transaction Simon Riggs <simon@2ndQuadrant.com>
2009-03-27 06:44 ` Re: display previous query string of idle-in-transaction Tatsuhito Kasahara <kasahara.tatsuhito@oss.ntt.co.jp>
2009-03-27 07:27 ` Re: display previous query string of idle-in-transaction Guillaume Smet <guillaume.smet@gmail.com>
2009-03-27 07:38 ` Re: display previous query string of idle-in-transaction Guillaume Smet <guillaume.smet@gmail.com>
@ 2009-03-30 07:08 ` Tatsuhito Kasahara <kasahara.tatsuhito@oss.ntt.co.jp>
0 siblings, 0 replies; 32+ messages in thread
From: Tatsuhito Kasahara @ 2009-03-30 07:08 UTC (permalink / raw)
To: Guillaume Smet <guillaume.smet@gmail.com>; +Cc: Simon Riggs <simon@2ndquadrant.com>; pgsql-hackers
(Sorry for delay..)
Guillaume Smet wrote:
> Being able to detect which application is running which query on the
> very same database with the very same user seems like something not so
> obvious and the use case seems to be pretty narrow. And IMHO, even if
> we suppose you can make the difference between the applications with
> only one query, you won't be able to limit your investigation to this
> application.
Yes, I won't be able to *completely* detect which application is running
long transaction with a last query.
But, as I said, I can get a hint for guessing causes from it.
And, as Simon said, I can detect a problem point with collaboration
from other information (app's log, app's source, operation procedure, and so on).
> So, in fact, I'm still not convinced. Could you detail a bit more how
> you plan to use it?
Well, Now, I can't get enough information from pg_stat_activity.
So, I have to check huge logs or reproduce the same problem.
(They are annoying works.)
If I can check last and more queries, I can use it as a hint for narrowing
down problem points with app's log and so on.
# And search the point and fix (or suggesting action) it.
I hope it would be able to narrowing down problem points more easily.
Best regards,
--
Tatsuhito Kasahara
kasahara.tatsuhito@oss.ntt.co.jp
^ permalink raw reply [nested|flat] 32+ messages in thread
* Re: display previous query string of idle-in-transaction
2009-03-25 09:08 display previous query string of idle-in-transaction Tatsuhito Kasahara <kasahara.tatsuhito@oss.ntt.co.jp>
2009-03-26 18:14 ` Re: display previous query string of idle-in-transaction Simon Riggs <simon@2ndQuadrant.com>
2009-03-27 06:44 ` Re: display previous query string of idle-in-transaction Tatsuhito Kasahara <kasahara.tatsuhito@oss.ntt.co.jp>
@ 2009-03-27 07:36 ` Simon Riggs <simon@2ndQuadrant.com>
2009-03-27 07:49 ` Re: display previous query string of idle-in-transaction Tatsuhito Kasahara <kasahara.tatsuhito@oss.ntt.co.jp>
2009-05-12 15:37 ` Re: display previous query string of idle-in-transaction decibel <decibel@decibel.org>
1 sibling, 2 replies; 32+ messages in thread
From: Simon Riggs @ 2009-03-27 07:36 UTC (permalink / raw)
To: Tatsuhito Kasahara <kasahara.tatsuhito@oss.ntt.co.jp>; +Cc: pgsql-hackers
On Fri, 2009-03-27 at 15:44 +0900, Tatsuhito Kasahara wrote:
> Simon Riggs wrote:
> >> If we can also check previous query_string of idle-in-transaction,
> >> it is useful for analysis of long transaction problem.
> >
> > I'm more interested in the problem itself. Why do you think there is a
> > problem and why does knowing this help you? I had similar problems
> > recently, so I'm interested in thoughts around this.
> In many case, applications don't know what queries they are doing.
> So, if a long transaction problem (unworking defragmnetation by HOT and
> VACUUM) occured, I don't understand which application is the cause with
> only "<IDLE> in transaction" message.
>
> But if I can also check last query string, I guess which apllication
> do that and point out the problem point.
> # As I said, I think a long transaction is not a problem itself.
>
> Does that answer your question ?
Not really. I want to understand the actual problem with
idle-in-transaction so we can consider all ways to solve it, rather than
just focus on one method.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
^ permalink raw reply [nested|flat] 32+ messages in thread
* Re: display previous query string of idle-in-transaction
2009-03-25 09:08 display previous query string of idle-in-transaction Tatsuhito Kasahara <kasahara.tatsuhito@oss.ntt.co.jp>
2009-03-26 18:14 ` Re: display previous query string of idle-in-transaction Simon Riggs <simon@2ndQuadrant.com>
2009-03-27 06:44 ` Re: display previous query string of idle-in-transaction Tatsuhito Kasahara <kasahara.tatsuhito@oss.ntt.co.jp>
2009-03-27 07:36 ` Re: display previous query string of idle-in-transaction Simon Riggs <simon@2ndQuadrant.com>
@ 2009-03-27 07:49 ` Tatsuhito Kasahara <kasahara.tatsuhito@oss.ntt.co.jp>
2009-03-27 08:07 ` Re: display previous query string of idle-in-transaction Simon Riggs <simon@2ndQuadrant.com>
1 sibling, 1 reply; 32+ messages in thread
From: Tatsuhito Kasahara @ 2009-03-27 07:49 UTC (permalink / raw)
To: Simon Riggs <simon@2ndQuadrant.com>; +Cc: pgsql-hackers
Simon Riggs wrote:
>> Does that answer your question ?
>
> Not really. I want to understand the actual problem with
> idle-in-transaction so we can consider all ways to solve it, rather than
> just focus on one method.
"idle in transaction timeout" feature may be one of the ways.
But I have no specific idea about it now.
--
Tatsuhito Kasahara
kasahara.tatsuhito@oss.ntt.co.jp
^ permalink raw reply [nested|flat] 32+ messages in thread
* Re: display previous query string of idle-in-transaction
2009-03-25 09:08 display previous query string of idle-in-transaction Tatsuhito Kasahara <kasahara.tatsuhito@oss.ntt.co.jp>
2009-03-26 18:14 ` Re: display previous query string of idle-in-transaction Simon Riggs <simon@2ndQuadrant.com>
2009-03-27 06:44 ` Re: display previous query string of idle-in-transaction Tatsuhito Kasahara <kasahara.tatsuhito@oss.ntt.co.jp>
2009-03-27 07:36 ` Re: display previous query string of idle-in-transaction Simon Riggs <simon@2ndQuadrant.com>
2009-03-27 07:49 ` Re: display previous query string of idle-in-transaction Tatsuhito Kasahara <kasahara.tatsuhito@oss.ntt.co.jp>
@ 2009-03-27 08:07 ` Simon Riggs <simon@2ndQuadrant.com>
2009-03-27 09:57 ` Re: display previous query string of idle-in-transaction Guillaume Smet <guillaume.smet@gmail.com>
0 siblings, 1 reply; 32+ messages in thread
From: Simon Riggs @ 2009-03-27 08:07 UTC (permalink / raw)
To: Tatsuhito Kasahara <kasahara.tatsuhito@oss.ntt.co.jp>; +Cc: pgsql-hackers
On Fri, 2009-03-27 at 16:49 +0900, Tatsuhito Kasahara wrote:
> Simon Riggs wrote:
> >> Does that answer your question ?
> >
> > Not really. I want to understand the actual problem with
> > idle-in-transaction so we can consider all ways to solve it, rather than
> > just focus on one method.
> "idle in transaction timeout" feature may be one of the ways.
> But I have no specific idea about it now.
Or take it further back still and think about why "idle in transaction"
occurs at all and fix *that*. Maybe not in Postgres at all, possibly in
the driver or even higher up client stack.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
^ permalink raw reply [nested|flat] 32+ messages in thread
* Re: display previous query string of idle-in-transaction
2009-03-25 09:08 display previous query string of idle-in-transaction Tatsuhito Kasahara <kasahara.tatsuhito@oss.ntt.co.jp>
2009-03-26 18:14 ` Re: display previous query string of idle-in-transaction Simon Riggs <simon@2ndQuadrant.com>
2009-03-27 06:44 ` Re: display previous query string of idle-in-transaction Tatsuhito Kasahara <kasahara.tatsuhito@oss.ntt.co.jp>
2009-03-27 07:36 ` Re: display previous query string of idle-in-transaction Simon Riggs <simon@2ndQuadrant.com>
2009-03-27 07:49 ` Re: display previous query string of idle-in-transaction Tatsuhito Kasahara <kasahara.tatsuhito@oss.ntt.co.jp>
2009-03-27 08:07 ` Re: display previous query string of idle-in-transaction Simon Riggs <simon@2ndQuadrant.com>
@ 2009-03-27 09:57 ` Guillaume Smet <guillaume.smet@gmail.com>
0 siblings, 0 replies; 32+ messages in thread
From: Guillaume Smet @ 2009-03-27 09:57 UTC (permalink / raw)
To: Simon Riggs <simon@2ndquadrant.com>; +Cc: Tatsuhito Kasahara <kasahara.tatsuhito@oss.ntt.co.jp>; pgsql-hackers
On Fri, Mar 27, 2009 at 9:07 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
> Or take it further back still and think about why "idle in transaction"
> occurs at all and fix *that*. Maybe not in Postgres at all, possibly in
> the driver or even higher up client stack.
^ permalink raw reply [nested|flat] 32+ messages in thread
* Re: display previous query string of idle-in-transaction
2009-03-25 09:08 display previous query string of idle-in-transaction Tatsuhito Kasahara <kasahara.tatsuhito@oss.ntt.co.jp>
2009-03-26 18:14 ` Re: display previous query string of idle-in-transaction Simon Riggs <simon@2ndQuadrant.com>
2009-03-27 06:44 ` Re: display previous query string of idle-in-transaction Tatsuhito Kasahara <kasahara.tatsuhito@oss.ntt.co.jp>
2009-03-27 07:36 ` Re: display previous query string of idle-in-transaction Simon Riggs <simon@2ndQuadrant.com>
@ 2009-05-12 15:37 ` decibel <decibel@decibel.org>
2009-05-13 04:56 ` Re: display previous query string of idle-in-transaction Asko Oja <ascoja@gmail.com>
1 sibling, 1 reply; 32+ messages in thread
From: decibel @ 2009-05-12 15:37 UTC (permalink / raw)
To: Simon Riggs <simon@2ndQuadrant.com>; +Cc: Tatsuhito Kasahara <kasahara.tatsuhito@oss.ntt.co.jp>; pgsql-hackers
On Mar 27, 2009, at 2:36 AM, Simon Riggs wrote:
> Not really. I want to understand the actual problem with
> idle-in-transaction so we can consider all ways to solve it, rather
> than
> just focus on one method.
I have to distinct problems with idle in transaction. One is
reporting users / the tools they're using. I'll often find
transactions that have been open for minutes or hours. But, that's
not a big deal for me, because that's only impacting londiste slaves,
and I have no problem just killing those backends.
What does concern me is seeing idle in transaction from our web
servers that lasts anything more than a few fractions of a second.
Those cases worry me because I have to wonder if that's happening due
to bad code. Right now I can't think of any way to figure out if
that's the case other than a lot of complex logfile processing
(assuming that would even work). But if I knew what the previous
query was, I'd at least have half a chance to know what portion of
the code was responsible, and could then look at the code to see if
the idle state was expected or not.
--
Decibel!, aka Jim C. Nasby, Database Architect decibel@decibel.org
Give your computer some brain candy! www.distributed.net Team #1828
^ permalink raw reply [nested|flat] 32+ messages in thread
* Re: display previous query string of idle-in-transaction
2009-03-25 09:08 display previous query string of idle-in-transaction Tatsuhito Kasahara <kasahara.tatsuhito@oss.ntt.co.jp>
2009-03-26 18:14 ` Re: display previous query string of idle-in-transaction Simon Riggs <simon@2ndQuadrant.com>
2009-03-27 06:44 ` Re: display previous query string of idle-in-transaction Tatsuhito Kasahara <kasahara.tatsuhito@oss.ntt.co.jp>
2009-03-27 07:36 ` Re: display previous query string of idle-in-transaction Simon Riggs <simon@2ndQuadrant.com>
2009-05-12 15:37 ` Re: display previous query string of idle-in-transaction decibel <decibel@decibel.org>
@ 2009-05-13 04:56 ` Asko Oja <ascoja@gmail.com>
2009-07-24 05:28 ` Re: display previous query string of idle-in-transaction daveg <daveg@sonic.net>
0 siblings, 1 reply; 32+ messages in thread
From: Asko Oja @ 2009-05-13 04:56 UTC (permalink / raw)
To: decibel <decibel@decibel.org>; +Cc: Simon Riggs <simon@2ndquadrant.com>; Tatsuhito Kasahara <kasahara.tatsuhito@oss.ntt.co.jp>; pgsql-hackers
After taking look at our monitoring system i think some hint about previous
SQL might be useful.
dba db70 db_name WARNING 1 long transactions, duration >
2690min user=postgres pid=7887 waiting=False query=<IDLE> in transaction
Currently i have no idea what exactly did i kill without digging in logs
which might have rotated anyway by now.
regards,
Asko
On Tue, May 12, 2009 at 6:37 PM, decibel <decibel@decibel.org> wrote:
> On Mar 27, 2009, at 2:36 AM, Simon Riggs wrote:
>
>> Not really. I want to understand the actual problem with
>> idle-in-transaction so we can consider all ways to solve it, rather than
>> just focus on one method.
>>
>
>
> I have to distinct problems with idle in transaction. One is reporting
> users / the tools they're using. I'll often find transactions that have been
> open for minutes or hours. But, that's not a big deal for me, because that's
> only impacting londiste slaves, and I have no problem just killing those
> backends.
>
> What does concern me is seeing idle in transaction from our web servers
> that lasts anything more than a few fractions of a second. Those cases worry
> me because I have to wonder if that's happening due to bad code. Right now I
> can't think of any way to figure out if that's the case other than a lot of
> complex logfile processing (assuming that would even work). But if I knew
> what the previous query was, I'd at least have half a chance to know what
> portion of the code was responsible, and could then look at the code to see
> if the idle state was expected or not.
> --
> Decibel!, aka Jim C. Nasby, Database Architect decibel@decibel.org
> Give your computer some brain candy! www.distributed.net Team #1828
>
>
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>
^ permalink raw reply [nested|flat] 32+ messages in thread
* Re: display previous query string of idle-in-transaction
2009-03-25 09:08 display previous query string of idle-in-transaction Tatsuhito Kasahara <kasahara.tatsuhito@oss.ntt.co.jp>
2009-03-26 18:14 ` Re: display previous query string of idle-in-transaction Simon Riggs <simon@2ndQuadrant.com>
2009-03-27 06:44 ` Re: display previous query string of idle-in-transaction Tatsuhito Kasahara <kasahara.tatsuhito@oss.ntt.co.jp>
2009-03-27 07:36 ` Re: display previous query string of idle-in-transaction Simon Riggs <simon@2ndQuadrant.com>
2009-05-12 15:37 ` Re: display previous query string of idle-in-transaction decibel <decibel@decibel.org>
2009-05-13 04:56 ` Re: display previous query string of idle-in-transaction Asko Oja <ascoja@gmail.com>
@ 2009-07-24 05:28 ` daveg <daveg@sonic.net>
2009-07-24 14:47 ` Re: display previous query string of idle-in-transaction Kevin Grittner <Kevin.Grittner@wicourts.gov>
0 siblings, 1 reply; 32+ messages in thread
From: daveg @ 2009-07-24 05:28 UTC (permalink / raw)
To: Robert Haas <robertmhaas@gmail.com>; +Cc: Tatsuhito Kasahara <kasahara.tatsuhito@oss.ntt.co.jp>; Kevin Grittner <Kevin.Grittner@wicourts.gov>; Greg Stark <stark@enterprisedb.com>; Asko Oja <ascoja@gmail.com>; Simon Riggs <simon@2ndquadrant.com>; decibel <decibel@decibel.org>; pgsql-hackers
On Thu, Jun 04, 2009 at 10:22:41PM -0400, Robert Haas wrote:
> The only thing I don't like about this is that I think it's kind of a
> hack to shove the <IDLE> in transaction designation and the query
> string into the same database column. I've never liked having to
> write:
>
> select sum(1) from pg_stat_activity where current_query = '<IDLE> in
> transaction';
>
> ...and I like it even less if I now have to modify that query to use
> "like". We should find some way to represent this as structured
> data... maybe make a separate column called "idle" that's a boolean,
> or something, and let the query column contain the most recent query
> (whether or not it's still executing).
I like this idea a lot. Possibly it would be useful to have the end time
of the last query too, then one could find idle sessions that were old and
truly idle rather than just waiting for a busy client to send the next query.
select ... from pg_stat_activity
where idle
and last_statement_endtime < now() - interval '1 minute';
-dg
--
David Gould daveg@sonic.net 510 536 1443 510 282 0869
If simplicity worked, the world would be overrun with insects.
^ permalink raw reply [nested|flat] 32+ messages in thread
* Re: display previous query string of idle-in-transaction
2009-03-25 09:08 display previous query string of idle-in-transaction Tatsuhito Kasahara <kasahara.tatsuhito@oss.ntt.co.jp>
2009-03-26 18:14 ` Re: display previous query string of idle-in-transaction Simon Riggs <simon@2ndQuadrant.com>
2009-03-27 06:44 ` Re: display previous query string of idle-in-transaction Tatsuhito Kasahara <kasahara.tatsuhito@oss.ntt.co.jp>
2009-03-27 07:36 ` Re: display previous query string of idle-in-transaction Simon Riggs <simon@2ndQuadrant.com>
2009-05-12 15:37 ` Re: display previous query string of idle-in-transaction decibel <decibel@decibel.org>
2009-05-13 04:56 ` Re: display previous query string of idle-in-transaction Asko Oja <ascoja@gmail.com>
2009-07-24 05:28 ` Re: display previous query string of idle-in-transaction daveg <daveg@sonic.net>
@ 2009-07-24 14:47 ` Kevin Grittner <Kevin.Grittner@wicourts.gov>
2009-07-24 14:58 ` Re: display previous query string of idle-in-transaction Robert Haas <robertmhaas@gmail.com>
0 siblings, 1 reply; 32+ messages in thread
From: Kevin Grittner @ 2009-07-24 14:47 UTC (permalink / raw)
To: Robert Haas <robertmhaas@gmail.com>; daveg <daveg@sonic.net>; +Cc: Simon Riggs <simon@2ndquadrant.com>; decibel <decibel@decibel.org>; Greg Stark <stark@enterprisedb.com>; Asko Oja <ascoja@gmail.com>; Tatsuhito Kasahara <kasahara.tatsuhito@oss.ntt.co.jp>; pgsql-hackers
daveg <daveg@sonic.net> wrote:
> On Thu, Jun 04, 2009 at 10:22:41PM -0400, Robert Haas wrote:
>> maybe make a separate column called "idle" that's a boolean,
>> or something, and let the query column contain the most recent
>> query (whether or not it's still executing).
+1
> I like this idea a lot. Possibly it would be useful to have the end
> time of the last query too, then one could find idle sessions that
> were old and truly idle rather than just waiting for a busy client
> to send the next query.
>
> select ... from pg_stat_activity
> where idle
> and last_statement_endtime < now() - interval '1 minute';
+1
Of course, you might be more interested in those which are idle in a
transaction, but that's easily done with these changes -- just throw
in xact_start IS NULL.
-Kevin
^ permalink raw reply [nested|flat] 32+ messages in thread
* Re: display previous query string of idle-in-transaction
2009-03-25 09:08 display previous query string of idle-in-transaction Tatsuhito Kasahara <kasahara.tatsuhito@oss.ntt.co.jp>
2009-03-26 18:14 ` Re: display previous query string of idle-in-transaction Simon Riggs <simon@2ndQuadrant.com>
2009-03-27 06:44 ` Re: display previous query string of idle-in-transaction Tatsuhito Kasahara <kasahara.tatsuhito@oss.ntt.co.jp>
2009-03-27 07:36 ` Re: display previous query string of idle-in-transaction Simon Riggs <simon@2ndQuadrant.com>
2009-05-12 15:37 ` Re: display previous query string of idle-in-transaction decibel <decibel@decibel.org>
2009-05-13 04:56 ` Re: display previous query string of idle-in-transaction Asko Oja <ascoja@gmail.com>
2009-07-24 05:28 ` Re: display previous query string of idle-in-transaction daveg <daveg@sonic.net>
2009-07-24 14:47 ` Re: display previous query string of idle-in-transaction Kevin Grittner <Kevin.Grittner@wicourts.gov>
@ 2009-07-24 14:58 ` Robert Haas <robertmhaas@gmail.com>
2009-07-24 15:06 ` Re: display previous query string of idle-in-transaction Kevin Grittner <Kevin.Grittner@wicourts.gov>
2009-07-24 15:15 ` Re: display previous query string of idle-in-transaction Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 2 replies; 32+ messages in thread
From: Robert Haas @ 2009-07-24 14:58 UTC (permalink / raw)
To: Kevin Grittner <Kevin.Grittner@wicourts.gov>; +Cc: daveg <daveg@sonic.net>; Simon Riggs <simon@2ndquadrant.com>; decibel <decibel@decibel.org>; Greg Stark <stark@enterprisedb.com>; Asko Oja <ascoja@gmail.com>; Tatsuhito Kasahara <kasahara.tatsuhito@oss.ntt.co.jp>; pgsql-hackers
On Fri, Jul 24, 2009 at 10:47 AM, Kevin
Grittner<Kevin.Grittner@wicourts.gov> wrote:
> daveg <daveg@sonic.net> wrote:
>> On Thu, Jun 04, 2009 at 10:22:41PM -0400, Robert Haas wrote:
>
>>> maybe make a separate column called "idle" that's a boolean,
>>> or something, and let the query column contain the most recent
>>> query (whether or not it's still executing).
>
> +1
>
>> I like this idea a lot. Possibly it would be useful to have the end
>> time of the last query too, then one could find idle sessions that
>> were old and truly idle rather than just waiting for a busy client
>> to send the next query.
>>
>> select ... from pg_stat_activity
>> where idle
>> and last_statement_endtime < now() - interval '1 minute';
>
> +1
Hmm, I don't think we'd need two columns for this, actually. You
could just have one column last_statement_endtime (not sure if it's
the best name, but something along those lines) which would be NULL if
the statement was still in progress and the appropriate timestamp if
not. You could infer idle from whether or not that column was NULL.
> Of course, you might be more interested in those which are idle in a
> transaction, but that's easily done with these changes -- just throw
> in xact_start IS NULL.
Surely if xact_start is NULL it is not in a transaction at all?
...Robert
^ permalink raw reply [nested|flat] 32+ messages in thread
* Re: display previous query string of idle-in-transaction
2009-03-25 09:08 display previous query string of idle-in-transaction Tatsuhito Kasahara <kasahara.tatsuhito@oss.ntt.co.jp>
2009-03-26 18:14 ` Re: display previous query string of idle-in-transaction Simon Riggs <simon@2ndQuadrant.com>
2009-03-27 06:44 ` Re: display previous query string of idle-in-transaction Tatsuhito Kasahara <kasahara.tatsuhito@oss.ntt.co.jp>
2009-03-27 07:36 ` Re: display previous query string of idle-in-transaction Simon Riggs <simon@2ndQuadrant.com>
2009-05-12 15:37 ` Re: display previous query string of idle-in-transaction decibel <decibel@decibel.org>
2009-05-13 04:56 ` Re: display previous query string of idle-in-transaction Asko Oja <ascoja@gmail.com>
2009-07-24 05:28 ` Re: display previous query string of idle-in-transaction daveg <daveg@sonic.net>
2009-07-24 14:47 ` Re: display previous query string of idle-in-transaction Kevin Grittner <Kevin.Grittner@wicourts.gov>
2009-07-24 14:58 ` Re: display previous query string of idle-in-transaction Robert Haas <robertmhaas@gmail.com>
@ 2009-07-24 15:06 ` Kevin Grittner <Kevin.Grittner@wicourts.gov>
1 sibling, 0 replies; 32+ messages in thread
From: Kevin Grittner @ 2009-07-24 15:06 UTC (permalink / raw)
To: Robert Haas <robertmhaas@gmail.com>; +Cc: Simon Riggs <simon@2ndquadrant.com>; decibel <decibel@decibel.org>; Greg Stark <stark@enterprisedb.com>; Asko Oja <ascoja@gmail.com>; Tatsuhito Kasahara <kasahara.tatsuhito@oss.ntt.co.jp>; pgsql-hackers; daveg <daveg@sonic.net>
Robert Haas <robertmhaas@gmail.com> wrote:
> Hmm, I don't think we'd need two columns for this, actually. You
> could just have one column last_statement_endtime (not sure if it's
> the best name, but something along those lines) which would be NULL
> if the statement was still in progress and the appropriate timestamp
> if not. You could infer idle from whether or not that column was
> NULL.
That would lose the ability to tell what the idle time was before the
latest statement began, but maybe that's not interesting enough to
justify another column....
>> Of course, you might be more interested in those which are idle in
>> a transaction, but that's easily done with these changes -- just
>> throw in xact_start IS NULL.
>
> Surely if xact_start is NULL it is not in a transaction at all?
That's exactly the point I was trying to make. Sorry if that appeared
to be saying anything else.
-Kevin
^ permalink raw reply [nested|flat] 32+ messages in thread
* Re: display previous query string of idle-in-transaction
2009-03-25 09:08 display previous query string of idle-in-transaction Tatsuhito Kasahara <kasahara.tatsuhito@oss.ntt.co.jp>
2009-03-26 18:14 ` Re: display previous query string of idle-in-transaction Simon Riggs <simon@2ndQuadrant.com>
2009-03-27 06:44 ` Re: display previous query string of idle-in-transaction Tatsuhito Kasahara <kasahara.tatsuhito@oss.ntt.co.jp>
2009-03-27 07:36 ` Re: display previous query string of idle-in-transaction Simon Riggs <simon@2ndQuadrant.com>
2009-05-12 15:37 ` Re: display previous query string of idle-in-transaction decibel <decibel@decibel.org>
2009-05-13 04:56 ` Re: display previous query string of idle-in-transaction Asko Oja <ascoja@gmail.com>
2009-07-24 05:28 ` Re: display previous query string of idle-in-transaction daveg <daveg@sonic.net>
2009-07-24 14:47 ` Re: display previous query string of idle-in-transaction Kevin Grittner <Kevin.Grittner@wicourts.gov>
2009-07-24 14:58 ` Re: display previous query string of idle-in-transaction Robert Haas <robertmhaas@gmail.com>
@ 2009-07-24 15:15 ` Tom Lane <tgl@sss.pgh.pa.us>
2009-07-24 16:53 ` Re: display previous query string of idle-in-transaction Robert Haas <robertmhaas@gmail.com>
2009-07-28 11:43 ` Re: display previous query string of idle-in-transaction Peter Eisentraut <peter_e@gmx.net>
1 sibling, 2 replies; 32+ messages in thread
From: Tom Lane @ 2009-07-24 15:15 UTC (permalink / raw)
To: Robert Haas <robertmhaas@gmail.com>; +Cc: Kevin Grittner <Kevin.Grittner@wicourts.gov>; daveg <daveg@sonic.net>; Simon Riggs <simon@2ndquadrant.com>; decibel <decibel@decibel.org>; Greg Stark <stark@enterprisedb.com>; Asko Oja <ascoja@gmail.com>; Tatsuhito Kasahara <kasahara.tatsuhito@oss.ntt.co.jp>; pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> Hmm, I don't think we'd need two columns for this, actually. You
> could just have one column last_statement_endtime (not sure if it's
> the best name, but something along those lines) which would be NULL if
> the statement was still in progress and the appropriate timestamp if
> not. You could infer idle from whether or not that column was NULL.
Yeah, but "where idle" or "where not idle" is a lot easier to type.
I think the extra column is justified on usability grounds. I'm also
not entirely convinced that we want last_statement_endtime, because
introducing that will cost us an extra kernel call per query in a lot of
scenarios. And gettimeofday() is not cheap everywhere.
Another question is that this proposal effectively redefines the
current_query column as not the "current" query, but something that
might be better be described as "latest_query". Should we change the
name? We'd probably break some client code if we did, but on the other
hand the semantics change might break such code anyway. Intentional
breakage might not be such a bad thing if it forces people to take a
fresh look at their code.
regards, tom lane
^ permalink raw reply [nested|flat] 32+ messages in thread
* Re: display previous query string of idle-in-transaction
2009-03-25 09:08 display previous query string of idle-in-transaction Tatsuhito Kasahara <kasahara.tatsuhito@oss.ntt.co.jp>
2009-03-26 18:14 ` Re: display previous query string of idle-in-transaction Simon Riggs <simon@2ndQuadrant.com>
2009-03-27 06:44 ` Re: display previous query string of idle-in-transaction Tatsuhito Kasahara <kasahara.tatsuhito@oss.ntt.co.jp>
2009-03-27 07:36 ` Re: display previous query string of idle-in-transaction Simon Riggs <simon@2ndQuadrant.com>
2009-05-12 15:37 ` Re: display previous query string of idle-in-transaction decibel <decibel@decibel.org>
2009-05-13 04:56 ` Re: display previous query string of idle-in-transaction Asko Oja <ascoja@gmail.com>
2009-07-24 05:28 ` Re: display previous query string of idle-in-transaction daveg <daveg@sonic.net>
2009-07-24 14:47 ` Re: display previous query string of idle-in-transaction Kevin Grittner <Kevin.Grittner@wicourts.gov>
2009-07-24 14:58 ` Re: display previous query string of idle-in-transaction Robert Haas <robertmhaas@gmail.com>
2009-07-24 15:15 ` Re: display previous query string of idle-in-transaction Tom Lane <tgl@sss.pgh.pa.us>
@ 2009-07-24 16:53 ` Robert Haas <robertmhaas@gmail.com>
1 sibling, 0 replies; 32+ messages in thread
From: Robert Haas @ 2009-07-24 16:53 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Kevin Grittner <Kevin.Grittner@wicourts.gov>; daveg <daveg@sonic.net>; Simon Riggs <simon@2ndquadrant.com>; decibel <decibel@decibel.org>; Greg Stark <stark@enterprisedb.com>; Asko Oja <ascoja@gmail.com>; Tatsuhito Kasahara <kasahara.tatsuhito@oss.ntt.co.jp>; pgsql-hackers
On Fri, Jul 24, 2009 at 11:15 AM, Tom Lane<tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> Hmm, I don't think we'd need two columns for this, actually. You
>> could just have one column last_statement_endtime (not sure if it's
>> the best name, but something along those lines) which would be NULL if
>> the statement was still in progress and the appropriate timestamp if
>> not. You could infer idle from whether or not that column was NULL.
>
> Yeah, but "where idle" or "where not idle" is a lot easier to type.
> I think the extra column is justified on usability grounds. I'm also
> not entirely convinced that we want last_statement_endtime, because
> introducing that will cost us an extra kernel call per query in a lot of
> scenarios. And gettimeofday() is not cheap everywhere.
I hate redundancy, but I don't care enough to argue about it.
> Another question is that this proposal effectively redefines the
> current_query column as not the "current" query, but something that
> might be better be described as "latest_query". Should we change the
> name? We'd probably break some client code if we did, but on the other
> hand the semantics change might break such code anyway. Intentional
> breakage might not be such a bad thing if it forces people to take a
> fresh look at their code.
+1 for intentional breakage. I like the name, too.
...Robert
^ permalink raw reply [nested|flat] 32+ messages in thread
* Re: display previous query string of idle-in-transaction
2009-03-25 09:08 display previous query string of idle-in-transaction Tatsuhito Kasahara <kasahara.tatsuhito@oss.ntt.co.jp>
2009-03-26 18:14 ` Re: display previous query string of idle-in-transaction Simon Riggs <simon@2ndQuadrant.com>
2009-03-27 06:44 ` Re: display previous query string of idle-in-transaction Tatsuhito Kasahara <kasahara.tatsuhito@oss.ntt.co.jp>
2009-03-27 07:36 ` Re: display previous query string of idle-in-transaction Simon Riggs <simon@2ndQuadrant.com>
2009-05-12 15:37 ` Re: display previous query string of idle-in-transaction decibel <decibel@decibel.org>
2009-05-13 04:56 ` Re: display previous query string of idle-in-transaction Asko Oja <ascoja@gmail.com>
2009-07-24 05:28 ` Re: display previous query string of idle-in-transaction daveg <daveg@sonic.net>
2009-07-24 14:47 ` Re: display previous query string of idle-in-transaction Kevin Grittner <Kevin.Grittner@wicourts.gov>
2009-07-24 14:58 ` Re: display previous query string of idle-in-transaction Robert Haas <robertmhaas@gmail.com>
2009-07-24 15:15 ` Re: display previous query string of idle-in-transaction Tom Lane <tgl@sss.pgh.pa.us>
@ 2009-07-28 11:43 ` Peter Eisentraut <peter_e@gmx.net>
1 sibling, 0 replies; 32+ messages in thread
From: Peter Eisentraut @ 2009-07-28 11:43 UTC (permalink / raw)
To: pgsql-hackers; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; Robert Haas <robertmhaas@gmail.com>; Kevin Grittner <Kevin.Grittner@wicourts.gov>; daveg <daveg@sonic.net>; Simon Riggs <simon@2ndquadrant.com>; decibel <decibel@decibel.org>; Greg Stark <stark@enterprisedb.com>; Asko Oja <ascoja@gmail.com>; Tatsuhito Kasahara <kasahara.tatsuhito@oss.ntt.co.jp>
On Friday 24 July 2009 18:15:00 Tom Lane wrote:
> Another question is that this proposal effectively redefines the
> current_query column as not the "current" query, but something that
> might be better be described as "latest_query". Should we change the
> name? We'd probably break some client code if we did, but on the other
> hand the semantics change might break such code anyway. Intentional
> breakage might not be such a bad thing if it forces people to take a
> fresh look at their code.
That breakage could be pretty widespread, though. Maybe have current_query
and last_query.
^ permalink raw reply [nested|flat] 32+ messages in thread
* [PATCH v4 1/2] mark_async_capable(): subpath should match subplan
@ 2023-07-21 09:05 Alexander Pyhalov <a.pyhalov@postgrespro.ru>
0 siblings, 0 replies; 32+ messages in thread
From: Alexander Pyhalov @ 2023-07-21 09:05 UTC (permalink / raw)
---
src/backend/optimizer/plan/createplan.c | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/src/backend/optimizer/plan/createplan.c b/src/backend/optimizer/plan/createplan.c
index 63fe6637155..0053befc8db 100644
--- a/src/backend/optimizer/plan/createplan.c
+++ b/src/backend/optimizer/plan/createplan.c
@@ -1139,10 +1139,10 @@ mark_async_capable_plan(Plan *plan, Path *path)
SubqueryScan *scan_plan = (SubqueryScan *) plan;
/*
- * If the generated plan node includes a gating Result node,
- * we can't execute it asynchronously.
+ * If the generated plan node includes a gating Result node or
+ * a Sort node, we can't execute it asynchronously.
*/
- if (IsA(plan, Result))
+ if (IsA(plan, Result) || IsA(plan, Sort))
return false;
/*
@@ -1160,10 +1160,10 @@ mark_async_capable_plan(Plan *plan, Path *path)
FdwRoutine *fdwroutine = path->parent->fdwroutine;
/*
- * If the generated plan node includes a gating Result node,
- * we can't execute it asynchronously.
+ * If the generated plan node includes a gating Result node or
+ * a Sort node, we can't execute it asynchronously.
*/
- if (IsA(plan, Result))
+ if (IsA(plan, Result) || IsA(plan, Sort))
return false;
Assert(fdwroutine != NULL);
@@ -1176,9 +1176,9 @@ mark_async_capable_plan(Plan *plan, Path *path)
/*
* If the generated plan node includes a Result node for the
- * projection, we can't execute it asynchronously.
+ * projection or a Sort node, we can't execute it asynchronously.
*/
- if (IsA(plan, Result))
+ if (IsA(plan, Result) || IsA(plan, Sort))
return false;
/*
--
2.47.3
--nfti2epu7uxujyyg
Content-Type: text/x-diff; charset=utf-8
Content-Disposition: attachment;
filename="v4-0002-MergeAppend-should-support-Async-Foreign-Scan-sub.patch"
^ permalink raw reply [nested|flat] 32+ messages in thread
* [PATCH v4] meson: Restore implicit warning/debug/optimize flags for extensions
@ 2024-03-15 09:27 Sutou Kouhei <kou@clear-code.com>
0 siblings, 0 replies; 32+ messages in thread
From: Sutou Kouhei @ 2024-03-15 09:27 UTC (permalink / raw)
Meson specifies warning/debug/optimize flags such as "-Wall", "-g" and
"-O2" automatically based on "--warnlevel" and "--buildtype"
options. And we use "--warning_level=1" and
"--buildtype=debugoptimized" by default.
We don't specify warning/debug/optimize flags explicitly to build
PostgreSQL with Meson. Because Meson does it automatically as we said.
But Meson doesn't care about flags in Makefile.global and
pg_config. So we need to care about them manually.
This changes do it. They detect warning/debug/optimize flags based on
warning_level/debug/optimization option values because Meson doesn't
tell us flags Meson guessed.
---
meson.build | 40 ++++++++++++++++++++++++++++++++++++++++
src/include/meson.build | 4 ++--
2 files changed, 42 insertions(+), 2 deletions(-)
diff --git a/meson.build b/meson.build
index c8fdfeb0ec..3c5c449a0a 100644
--- a/meson.build
+++ b/meson.build
@@ -1824,6 +1824,46 @@ endif
vectorize_cflags = cc.get_supported_arguments(['-ftree-vectorize'])
unroll_loops_cflags = cc.get_supported_arguments(['-funroll-loops'])
+# They aren't used for building PostgreSQL itself because Meson does
+# everything internally. They are used by extensions via pg_config or
+# Makefile.global.
+common_builtin_flags = []
+
+warning_level = get_option('warning_level')
+# See https://mesonbuild.com/Builtin-options.html#details-for-warning_level for
+# warning_level values.
+if warning_level == '1'
+ common_builtin_flags += ['-Wall', '/W2']
+elif warning_level == '2'
+ common_builtin_flags += ['-Wall', '-Wextra', '/W3']
+elif warning_level == '3'
+ common_builtin_flags += ['-Wall', '-Wextra', '-Wpedantic', '/W4']
+elif warning_level == 'everything'
+ common_builtin_flags += ['-Weverything', '/Wall']
+endif
+
+if get_option('debug')
+ common_builtin_flags += ['-g']
+endif
+
+optimization = get_option('optimization')
+if optimization == '0'
+ common_builtin_flags += ['-O0']
+elif optimization == '1'
+ common_builtin_flags += ['-O1']
+elif optimization == '2'
+ common_builtin_flags += ['-O2']
+elif optimization == '3'
+ common_builtin_flags += ['-O3']
+elif optimization == 's'
+ common_builtin_flags += ['-Os']
+endif
+
+cflags_builtin = cc.get_supported_arguments(common_builtin_flags)
+if llvm.found()
+ cxxflags_builtin = cpp.get_supported_arguments(common_builtin_flags)
+endif
+
common_warning_flags = [
'-Wmissing-prototypes',
'-Wpointer-arith',
diff --git a/src/include/meson.build b/src/include/meson.build
index a28f115d86..58b7a9c1e7 100644
--- a/src/include/meson.build
+++ b/src/include/meson.build
@@ -44,9 +44,9 @@ config_paths_data.set_quoted('MANDIR', dir_prefix / dir_man)
var_cc = ' '.join(cc.cmd_array())
var_cpp = ' '.join(cc.cmd_array() + ['-E'])
-var_cflags = ' '.join(cflags + cflags_warn + get_option('c_args'))
+var_cflags = ' '.join(cflags + cflags_builtin + cflags_warn + get_option('c_args'))
if llvm.found()
- var_cxxflags = ' '.join(cxxflags + cxxflags_warn + get_option('cpp_args'))
+ var_cxxflags = ' '.join(cxxflags + cxxflags_builtin + cxxflags_warn + get_option('cpp_args'))
else
var_cxxflags = ''
endif
--
2.43.0
----Next_Part(Fri_Mar_15_18_36_55_2024_733)----
^ permalink raw reply [nested|flat] 32+ messages in thread
* [PATCH v4] meson: Restore implicit warning/debug/optimize flags for extensions
@ 2024-03-15 09:27 Sutou Kouhei <kou@clear-code.com>
0 siblings, 0 replies; 32+ messages in thread
From: Sutou Kouhei @ 2024-03-15 09:27 UTC (permalink / raw)
Meson specifies warning/debug/optimize flags such as "-Wall", "-g" and
"-O2" automatically based on "--warnlevel" and "--buildtype"
options. And we use "--warning_level=1" and
"--buildtype=debugoptimized" by default.
We don't specify warning/debug/optimize flags explicitly to build
PostgreSQL with Meson. Because Meson does it automatically as we said.
But Meson doesn't care about flags in Makefile.global and
pg_config. So we need to care about them manually.
This changes do it. They detect warning/debug/optimize flags based on
warning_level/debug/optimization option values because Meson doesn't
tell us flags Meson guessed.
---
meson.build | 40 ++++++++++++++++++++++++++++++++++++++++
src/include/meson.build | 4 ++--
2 files changed, 42 insertions(+), 2 deletions(-)
diff --git a/meson.build b/meson.build
index c8fdfeb0ec..3c5c449a0a 100644
--- a/meson.build
+++ b/meson.build
@@ -1824,6 +1824,46 @@ endif
vectorize_cflags = cc.get_supported_arguments(['-ftree-vectorize'])
unroll_loops_cflags = cc.get_supported_arguments(['-funroll-loops'])
+# They aren't used for building PostgreSQL itself because Meson does
+# everything internally. They are used by extensions via pg_config or
+# Makefile.global.
+common_builtin_flags = []
+
+warning_level = get_option('warning_level')
+# See https://mesonbuild.com/Builtin-options.html#details-for-warning_level for
+# warning_level values.
+if warning_level == '1'
+ common_builtin_flags += ['-Wall', '/W2']
+elif warning_level == '2'
+ common_builtin_flags += ['-Wall', '-Wextra', '/W3']
+elif warning_level == '3'
+ common_builtin_flags += ['-Wall', '-Wextra', '-Wpedantic', '/W4']
+elif warning_level == 'everything'
+ common_builtin_flags += ['-Weverything', '/Wall']
+endif
+
+if get_option('debug')
+ common_builtin_flags += ['-g']
+endif
+
+optimization = get_option('optimization')
+if optimization == '0'
+ common_builtin_flags += ['-O0']
+elif optimization == '1'
+ common_builtin_flags += ['-O1']
+elif optimization == '2'
+ common_builtin_flags += ['-O2']
+elif optimization == '3'
+ common_builtin_flags += ['-O3']
+elif optimization == 's'
+ common_builtin_flags += ['-Os']
+endif
+
+cflags_builtin = cc.get_supported_arguments(common_builtin_flags)
+if llvm.found()
+ cxxflags_builtin = cpp.get_supported_arguments(common_builtin_flags)
+endif
+
common_warning_flags = [
'-Wmissing-prototypes',
'-Wpointer-arith',
diff --git a/src/include/meson.build b/src/include/meson.build
index a28f115d86..58b7a9c1e7 100644
--- a/src/include/meson.build
+++ b/src/include/meson.build
@@ -44,9 +44,9 @@ config_paths_data.set_quoted('MANDIR', dir_prefix / dir_man)
var_cc = ' '.join(cc.cmd_array())
var_cpp = ' '.join(cc.cmd_array() + ['-E'])
-var_cflags = ' '.join(cflags + cflags_warn + get_option('c_args'))
+var_cflags = ' '.join(cflags + cflags_builtin + cflags_warn + get_option('c_args'))
if llvm.found()
- var_cxxflags = ' '.join(cxxflags + cxxflags_warn + get_option('cpp_args'))
+ var_cxxflags = ' '.join(cxxflags + cxxflags_builtin + cxxflags_warn + get_option('cpp_args'))
else
var_cxxflags = ''
endif
--
2.43.0
----Next_Part(Fri_Mar_15_18_36_55_2024_733)----
^ permalink raw reply [nested|flat] 32+ messages in thread
* [PATCH v6] meson: Restore implicit warning/debug/optimize flags for extensions
@ 2024-03-15 09:27 Sutou Kouhei <kou@clear-code.com>
0 siblings, 0 replies; 32+ messages in thread
From: Sutou Kouhei @ 2024-03-15 09:27 UTC (permalink / raw)
Meson specifies warning/debug/optimize flags such as "-Wall", "-g" and
"-O2" automatically based on "--warnlevel" and "--buildtype"
options. And we use "--warning_level=1" and
"--buildtype=debugoptimized" by default.
We don't specify warning/debug/optimize flags explicitly to build
PostgreSQL with Meson. Because Meson does it automatically as we said.
But Meson doesn't care about flags in Makefile.global and
pg_config. So we need to care about them manually.
This changes do it. They detect debug/optimize flags based on
debug/optimization option values because Meson doesn't tell us flags
Meson guessed. We always use -Wall for warning flags.
---
meson.build | 27 +++++++++++++++++++++++++++
src/include/meson.build | 4 ++--
2 files changed, 29 insertions(+), 2 deletions(-)
diff --git a/meson.build b/meson.build
index d6401fb8e30..d7239dbb114 100644
--- a/meson.build
+++ b/meson.build
@@ -1851,6 +1851,33 @@ endif
vectorize_cflags = cc.get_supported_arguments(['-ftree-vectorize'])
unroll_loops_cflags = cc.get_supported_arguments(['-funroll-loops'])
+# They aren't used for building PostgreSQL itself because Meson does
+# everything internally. They are used by extensions via pg_config or
+# Makefile.global.
+common_builtin_flags = ['-Wall']
+
+if get_option('debug')
+ common_builtin_flags += ['-g']
+endif
+
+optimization = get_option('optimization')
+if optimization == '0'
+ common_builtin_flags += ['-O0']
+elif optimization == '1'
+ common_builtin_flags += ['-O1']
+elif optimization == '2'
+ common_builtin_flags += ['-O2']
+elif optimization == '3'
+ common_builtin_flags += ['-O3']
+elif optimization == 's'
+ common_builtin_flags += ['-Os']
+endif
+
+cflags_builtin = cc.get_supported_arguments(common_builtin_flags)
+if llvm.found()
+ cxxflags_builtin = cpp.get_supported_arguments(common_builtin_flags)
+endif
+
common_warning_flags = [
'-Wmissing-prototypes',
'-Wpointer-arith',
diff --git a/src/include/meson.build b/src/include/meson.build
index a28f115d867..58b7a9c1e7e 100644
--- a/src/include/meson.build
+++ b/src/include/meson.build
@@ -44,9 +44,9 @@ config_paths_data.set_quoted('MANDIR', dir_prefix / dir_man)
var_cc = ' '.join(cc.cmd_array())
var_cpp = ' '.join(cc.cmd_array() + ['-E'])
-var_cflags = ' '.join(cflags + cflags_warn + get_option('c_args'))
+var_cflags = ' '.join(cflags + cflags_builtin + cflags_warn + get_option('c_args'))
if llvm.found()
- var_cxxflags = ' '.join(cxxflags + cxxflags_warn + get_option('cpp_args'))
+ var_cxxflags = ' '.join(cxxflags + cxxflags_builtin + cxxflags_warn + get_option('cpp_args'))
else
var_cxxflags = ''
endif
--
2.43.0
----Next_Part(Wed_May_29_15_47_08_2024_215)----
^ permalink raw reply [nested|flat] 32+ messages in thread
* [PATCH v6] meson: Restore implicit warning/debug/optimize flags for extensions
@ 2024-03-15 09:27 Sutou Kouhei <kou@clear-code.com>
0 siblings, 0 replies; 32+ messages in thread
From: Sutou Kouhei @ 2024-03-15 09:27 UTC (permalink / raw)
Meson specifies warning/debug/optimize flags such as "-Wall", "-g" and
"-O2" automatically based on "--warnlevel" and "--buildtype"
options. And we use "--warning_level=1" and
"--buildtype=debugoptimized" by default.
We don't specify warning/debug/optimize flags explicitly to build
PostgreSQL with Meson. Because Meson does it automatically as we said.
But Meson doesn't care about flags in Makefile.global and
pg_config. So we need to care about them manually.
This changes do it. They detect debug/optimize flags based on
debug/optimization option values because Meson doesn't tell us flags
Meson guessed. We always use -Wall for warning flags.
---
meson.build | 27 +++++++++++++++++++++++++++
src/include/meson.build | 4 ++--
2 files changed, 29 insertions(+), 2 deletions(-)
diff --git a/meson.build b/meson.build
index d6401fb8e30..d7239dbb114 100644
--- a/meson.build
+++ b/meson.build
@@ -1851,6 +1851,33 @@ endif
vectorize_cflags = cc.get_supported_arguments(['-ftree-vectorize'])
unroll_loops_cflags = cc.get_supported_arguments(['-funroll-loops'])
+# They aren't used for building PostgreSQL itself because Meson does
+# everything internally. They are used by extensions via pg_config or
+# Makefile.global.
+common_builtin_flags = ['-Wall']
+
+if get_option('debug')
+ common_builtin_flags += ['-g']
+endif
+
+optimization = get_option('optimization')
+if optimization == '0'
+ common_builtin_flags += ['-O0']
+elif optimization == '1'
+ common_builtin_flags += ['-O1']
+elif optimization == '2'
+ common_builtin_flags += ['-O2']
+elif optimization == '3'
+ common_builtin_flags += ['-O3']
+elif optimization == 's'
+ common_builtin_flags += ['-Os']
+endif
+
+cflags_builtin = cc.get_supported_arguments(common_builtin_flags)
+if llvm.found()
+ cxxflags_builtin = cpp.get_supported_arguments(common_builtin_flags)
+endif
+
common_warning_flags = [
'-Wmissing-prototypes',
'-Wpointer-arith',
diff --git a/src/include/meson.build b/src/include/meson.build
index a28f115d867..58b7a9c1e7e 100644
--- a/src/include/meson.build
+++ b/src/include/meson.build
@@ -44,9 +44,9 @@ config_paths_data.set_quoted('MANDIR', dir_prefix / dir_man)
var_cc = ' '.join(cc.cmd_array())
var_cpp = ' '.join(cc.cmd_array() + ['-E'])
-var_cflags = ' '.join(cflags + cflags_warn + get_option('c_args'))
+var_cflags = ' '.join(cflags + cflags_builtin + cflags_warn + get_option('c_args'))
if llvm.found()
- var_cxxflags = ' '.join(cxxflags + cxxflags_warn + get_option('cpp_args'))
+ var_cxxflags = ' '.join(cxxflags + cxxflags_builtin + cxxflags_warn + get_option('cpp_args'))
else
var_cxxflags = ''
endif
--
2.43.0
----Next_Part(Wed_May_29_15_47_08_2024_215)----
^ permalink raw reply [nested|flat] 32+ messages in thread
* [PATCH v5] meson: Restore implicit warning/debug/optimize flags for extensions
@ 2024-03-15 09:27 Sutou Kouhei <kou@clear-code.com>
0 siblings, 0 replies; 32+ messages in thread
From: Sutou Kouhei @ 2024-03-15 09:27 UTC (permalink / raw)
Meson specifies warning/debug/optimize flags such as "-Wall", "-g" and
"-O2" automatically based on "--warnlevel" and "--buildtype"
options. And we use "--warning_level=1" and
"--buildtype=debugoptimized" by default.
We don't specify warning/debug/optimize flags explicitly to build
PostgreSQL with Meson. Because Meson does it automatically as we said.
But Meson doesn't care about flags in Makefile.global and
pg_config. So we need to care about them manually.
This changes do it. They detect warning/debug/optimize flags based on
warning_level/debug/optimization option values because Meson doesn't
tell us flags Meson guessed.
---
meson.build | 41 +++++++++++++++++++++++++++++++++++++++++
src/include/meson.build | 4 ++--
2 files changed, 43 insertions(+), 2 deletions(-)
diff --git a/meson.build b/meson.build
index 5acf083ce3c..11bd56f79a7 100644
--- a/meson.build
+++ b/meson.build
@@ -1848,6 +1848,47 @@ endif
vectorize_cflags = cc.get_supported_arguments(['-ftree-vectorize'])
unroll_loops_cflags = cc.get_supported_arguments(['-funroll-loops'])
+# They aren't used for building PostgreSQL itself because Meson does
+# everything internally. They are used by extensions via pg_config or
+# Makefile.global.
+common_builtin_flags = []
+
+warning_level = get_option('warning_level')
+# See https://mesonbuild.com/Builtin-options.html#details-for-warning_level for
+# warning_level values.
+#
+# We don't use "/W*" flags here because we don't need to care about MSVC here.
+#
+# We don't have "warning_level == 3" and "warning_level ==
+# 'everything'" here because we don't use these warning levels.
+if warning_level == '1'
+ common_builtin_flags += ['-Wall']
+elif warning_level == '2'
+ common_builtin_flags += ['-Wall', '-Wextra']
+endif
+
+if get_option('debug')
+ common_builtin_flags += ['-g']
+endif
+
+optimization = get_option('optimization')
+if optimization == '0'
+ common_builtin_flags += ['-O0']
+elif optimization == '1'
+ common_builtin_flags += ['-O1']
+elif optimization == '2'
+ common_builtin_flags += ['-O2']
+elif optimization == '3'
+ common_builtin_flags += ['-O3']
+elif optimization == 's'
+ common_builtin_flags += ['-Os']
+endif
+
+cflags_builtin = cc.get_supported_arguments(common_builtin_flags)
+if llvm.found()
+ cxxflags_builtin = cpp.get_supported_arguments(common_builtin_flags)
+endif
+
common_warning_flags = [
'-Wmissing-prototypes',
'-Wpointer-arith',
diff --git a/src/include/meson.build b/src/include/meson.build
index a28f115d867..58b7a9c1e7e 100644
--- a/src/include/meson.build
+++ b/src/include/meson.build
@@ -44,9 +44,9 @@ config_paths_data.set_quoted('MANDIR', dir_prefix / dir_man)
var_cc = ' '.join(cc.cmd_array())
var_cpp = ' '.join(cc.cmd_array() + ['-E'])
-var_cflags = ' '.join(cflags + cflags_warn + get_option('c_args'))
+var_cflags = ' '.join(cflags + cflags_builtin + cflags_warn + get_option('c_args'))
if llvm.found()
- var_cxxflags = ' '.join(cxxflags + cxxflags_warn + get_option('cpp_args'))
+ var_cxxflags = ' '.join(cxxflags + cxxflags_builtin + cxxflags_warn + get_option('cpp_args'))
else
var_cxxflags = ''
endif
--
2.43.0
----Next_Part(Mon_Apr__8_10_01_17_2024_730)----
^ permalink raw reply [nested|flat] 32+ messages in thread
* [PATCH v5] meson: Restore implicit warning/debug/optimize flags for extensions
@ 2024-03-15 09:27 Sutou Kouhei <kou@clear-code.com>
0 siblings, 0 replies; 32+ messages in thread
From: Sutou Kouhei @ 2024-03-15 09:27 UTC (permalink / raw)
Meson specifies warning/debug/optimize flags such as "-Wall", "-g" and
"-O2" automatically based on "--warnlevel" and "--buildtype"
options. And we use "--warning_level=1" and
"--buildtype=debugoptimized" by default.
We don't specify warning/debug/optimize flags explicitly to build
PostgreSQL with Meson. Because Meson does it automatically as we said.
But Meson doesn't care about flags in Makefile.global and
pg_config. So we need to care about them manually.
This changes do it. They detect warning/debug/optimize flags based on
warning_level/debug/optimization option values because Meson doesn't
tell us flags Meson guessed.
---
meson.build | 41 +++++++++++++++++++++++++++++++++++++++++
src/include/meson.build | 4 ++--
2 files changed, 43 insertions(+), 2 deletions(-)
diff --git a/meson.build b/meson.build
index 5acf083ce3c..11bd56f79a7 100644
--- a/meson.build
+++ b/meson.build
@@ -1848,6 +1848,47 @@ endif
vectorize_cflags = cc.get_supported_arguments(['-ftree-vectorize'])
unroll_loops_cflags = cc.get_supported_arguments(['-funroll-loops'])
+# They aren't used for building PostgreSQL itself because Meson does
+# everything internally. They are used by extensions via pg_config or
+# Makefile.global.
+common_builtin_flags = []
+
+warning_level = get_option('warning_level')
+# See https://mesonbuild.com/Builtin-options.html#details-for-warning_level for
+# warning_level values.
+#
+# We don't use "/W*" flags here because we don't need to care about MSVC here.
+#
+# We don't have "warning_level == 3" and "warning_level ==
+# 'everything'" here because we don't use these warning levels.
+if warning_level == '1'
+ common_builtin_flags += ['-Wall']
+elif warning_level == '2'
+ common_builtin_flags += ['-Wall', '-Wextra']
+endif
+
+if get_option('debug')
+ common_builtin_flags += ['-g']
+endif
+
+optimization = get_option('optimization')
+if optimization == '0'
+ common_builtin_flags += ['-O0']
+elif optimization == '1'
+ common_builtin_flags += ['-O1']
+elif optimization == '2'
+ common_builtin_flags += ['-O2']
+elif optimization == '3'
+ common_builtin_flags += ['-O3']
+elif optimization == 's'
+ common_builtin_flags += ['-Os']
+endif
+
+cflags_builtin = cc.get_supported_arguments(common_builtin_flags)
+if llvm.found()
+ cxxflags_builtin = cpp.get_supported_arguments(common_builtin_flags)
+endif
+
common_warning_flags = [
'-Wmissing-prototypes',
'-Wpointer-arith',
diff --git a/src/include/meson.build b/src/include/meson.build
index a28f115d867..58b7a9c1e7e 100644
--- a/src/include/meson.build
+++ b/src/include/meson.build
@@ -44,9 +44,9 @@ config_paths_data.set_quoted('MANDIR', dir_prefix / dir_man)
var_cc = ' '.join(cc.cmd_array())
var_cpp = ' '.join(cc.cmd_array() + ['-E'])
-var_cflags = ' '.join(cflags + cflags_warn + get_option('c_args'))
+var_cflags = ' '.join(cflags + cflags_builtin + cflags_warn + get_option('c_args'))
if llvm.found()
- var_cxxflags = ' '.join(cxxflags + cxxflags_warn + get_option('cpp_args'))
+ var_cxxflags = ' '.join(cxxflags + cxxflags_builtin + cxxflags_warn + get_option('cpp_args'))
else
var_cxxflags = ''
endif
--
2.43.0
----Next_Part(Mon_Apr__8_10_01_17_2024_730)----
^ permalink raw reply [nested|flat] 32+ messages in thread
end of thread, other threads:[~2024-03-15 09:27 UTC | newest]
Thread overview: 32+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2009-03-25 09:08 display previous query string of idle-in-transaction Tatsuhito Kasahara <kasahara.tatsuhito@oss.ntt.co.jp>
2009-03-25 09:59 ` Gurjeet Singh <singh.gurjeet@gmail.com>
2009-03-25 16:48 ` hubert depesz lubaczewski <depesz@depesz.com>
2009-03-25 17:07 ` Guillaume Smet <guillaume.smet@gmail.com>
2009-03-26 08:16 ` Tatsuhito Kasahara <kasahara.tatsuhito@oss.ntt.co.jp>
2009-03-26 09:21 ` ITAGAKI Takahiro <itagaki.takahiro@oss.ntt.co.jp>
2009-03-26 11:00 ` Tatsuhito Kasahara <kasahara.tatsuhito@oss.ntt.co.jp>
2009-03-26 18:14 ` Simon Riggs <simon@2ndQuadrant.com>
2009-03-27 06:44 ` Tatsuhito Kasahara <kasahara.tatsuhito@oss.ntt.co.jp>
2009-03-27 07:27 ` Guillaume Smet <guillaume.smet@gmail.com>
2009-03-27 07:38 ` Guillaume Smet <guillaume.smet@gmail.com>
2009-03-30 07:08 ` Tatsuhito Kasahara <kasahara.tatsuhito@oss.ntt.co.jp>
2009-03-27 07:36 ` Simon Riggs <simon@2ndQuadrant.com>
2009-03-27 07:49 ` Tatsuhito Kasahara <kasahara.tatsuhito@oss.ntt.co.jp>
2009-03-27 08:07 ` Simon Riggs <simon@2ndQuadrant.com>
2009-03-27 09:57 ` Guillaume Smet <guillaume.smet@gmail.com>
2009-05-12 15:37 ` decibel <decibel@decibel.org>
2009-05-13 04:56 ` Asko Oja <ascoja@gmail.com>
2009-07-24 05:28 ` daveg <daveg@sonic.net>
2009-07-24 14:47 ` Kevin Grittner <Kevin.Grittner@wicourts.gov>
2009-07-24 14:58 ` Robert Haas <robertmhaas@gmail.com>
2009-07-24 15:06 ` Kevin Grittner <Kevin.Grittner@wicourts.gov>
2009-07-24 15:15 ` Tom Lane <tgl@sss.pgh.pa.us>
2009-07-24 16:53 ` Robert Haas <robertmhaas@gmail.com>
2009-07-28 11:43 ` Peter Eisentraut <peter_e@gmx.net>
2023-07-21 09:05 [PATCH v4 1/2] mark_async_capable(): subpath should match subplan Alexander Pyhalov <a.pyhalov@postgrespro.ru>
2024-03-15 09:27 [PATCH v4] meson: Restore implicit warning/debug/optimize flags for extensions Sutou Kouhei <kou@clear-code.com>
2024-03-15 09:27 [PATCH v4] meson: Restore implicit warning/debug/optimize flags for extensions Sutou Kouhei <kou@clear-code.com>
2024-03-15 09:27 [PATCH v6] meson: Restore implicit warning/debug/optimize flags for extensions Sutou Kouhei <kou@clear-code.com>
2024-03-15 09:27 [PATCH v6] meson: Restore implicit warning/debug/optimize flags for extensions Sutou Kouhei <kou@clear-code.com>
2024-03-15 09:27 [PATCH v5] meson: Restore implicit warning/debug/optimize flags for extensions Sutou Kouhei <kou@clear-code.com>
2024-03-15 09:27 [PATCH v5] meson: Restore implicit warning/debug/optimize flags for extensions Sutou Kouhei <kou@clear-code.com>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox