Re: [HACKERS] Request: pg_cancel_backend variant that handles 'idle in transaction' sessions

2015-11-04 21:56 GMT+01:00 Joshua D. Drake : > On 11/04/2015 12:31 PM, Merlin Moncure wrote: > > My issue isn't long statements, but broken client, that is broken in wrong >>> state - connect is still active, but no any statement will coming. >>> >> >> Right, 'Idle in

Re: [HACKERS] Request: pg_cancel_backend variant that handles 'idle in transaction' sessions

2015-11-04 21:31 GMT+01:00 Merlin Moncure : > On Wed, Nov 4, 2015 at 2:09 PM, Pavel Stehule > wrote: > > 2015-11-04 20:35 GMT+01:00 Merlin Moncure : > >> > >> On Wed, Nov 4, 2015 at 11:26 AM, Pavel Stehule

Re: [HACKERS] Request: pg_cancel_backend variant that handles 'idle in transaction' sessions

On 11/04/2015 01:24 PM, Alvaro Herrera wrote: > I agree with Pavel. Having a transaction timeout just does not make any > sense. I can see absolutely no use for it. An idle-in-transaction > timeout, on the other hand, is very useful. +1 -- agreed Joe -- Crunchy Data - http://crunchydata.com

Re: [HACKERS] Request: pg_cancel_backend variant that handles 'idle in transaction' sessions

* Joe Conway (m...@joeconway.com) wrote: > On 11/04/2015 01:24 PM, Alvaro Herrera wrote: > > I agree with Pavel. Having a transaction timeout just does not make any > > sense. I can see absolutely no use for it. An idle-in-transaction > > timeout, on the other hand, is very useful. > > +1 --

Re: [HACKERS] Request: pg_cancel_backend variant that handles 'idle in transaction' sessions

On 11/04/2015 01:55 PM, Stephen Frost wrote: * Joe Conway (m...@joeconway.com) wrote: On 11/04/2015 01:24 PM, Alvaro Herrera wrote: I agree with Pavel. Having a transaction timeout just does not make any sense. I can see absolutely no use for it. An idle-in-transaction timeout, on the other

Re: [HACKERS] Request: pg_cancel_backend variant that handles 'idle in transaction' sessions

* Joshua D. Drake (j...@commandprompt.com) wrote: > On 11/04/2015 01:55 PM, Stephen Frost wrote: > >* Joe Conway (m...@joeconway.com) wrote: > >>On 11/04/2015 01:24 PM, Alvaro Herrera wrote: > >>>I agree with Pavel. Having a transaction timeout just does not make any > >>>sense. I can see

Re: [HACKERS] Request: pg_cancel_backend variant that handles 'idle in transaction' sessions

Pavel Stehule wrote: > 2015-11-04 22:14 GMT+01:00 Joshua D. Drake : > > > On 11/04/2015 01:11 PM, Pavel Stehule wrote: > > > >> I am sorry, but I have a different experience from GoodData. The few > >> hours autovacuum is usual. So probably, there should be exception for >

Re: [HACKERS] Request: pg_cancel_backend variant that handles 'idle in transaction' sessions

On 11/04/2015 02:07 PM, Joshua D. Drake wrote: > On 11/04/2015 01:55 PM, Stephen Frost wrote: >> * Joe Conway (m...@joeconway.com) wrote: >>> On 11/04/2015 01:24 PM, Alvaro Herrera wrote: I agree with Pavel. Having a transaction timeout just does not make any sense. I can see

Re: [HACKERS] Request: pg_cancel_backend variant that handles 'idle in transaction' sessions

On 11/04/2015 02:15 PM, Stephen Frost wrote: Yeah but anything holding a lock that long can be terminated via statement_timeout can it not? Well, no? statement_timeout is per-statement, while transaction_timeout is, well, per transaction. If there's a process which is going and has an open

Re: [HACKERS] Bitmap index scans use of filters on available columns

Jeff Janes writes: > On Wed, Nov 4, 2015 at 7:14 AM, Tom Lane wrote: >> You're missing my point: that is possible in an indexscan, but *not* in a >> bitmap indexscan, because the index AM APIs are totally different in the >> two cases. In a bitmap scan,

Re: [HACKERS] Request: pg_cancel_backend variant that handles 'idle in transaction' sessions

2015-11-04 22:14 GMT+01:00 Joshua D. Drake : > On 11/04/2015 01:11 PM, Pavel Stehule wrote: > > >> I am sorry, but I have a different experience from GoodData. The few >> hours autovacuum is usual. So probably, there should be exception for >> autovacuum, dump, .. >> > >

Re: [HACKERS] Request: pg_cancel_backend variant that handles 'idle in transaction' sessions

On Wed, Nov 4, 2015 at 2:09 PM, Pavel Stehule wrote: > 2015-11-04 20:35 GMT+01:00 Merlin Moncure : >> >> On Wed, Nov 4, 2015 at 11:26 AM, Pavel Stehule >> > it doesn't help. How I can set transaction_timeout if I have series

Re: [HACKERS] Request: pg_cancel_backend variant that handles 'idle in transaction' sessions

On 11/04/2015 12:31 PM, Merlin Moncure wrote: My issue isn't long statements, but broken client, that is broken in wrong state - connect is still active, but no any statement will coming. Right, 'Idle in transaction'. Agree that a setting directed purely at that problem could set a much

Re: [HACKERS] Request: pg_cancel_backend variant that handles 'idle in transaction' sessions

On 11/04/2015 01:55 PM, Stephen Frost wrote: > * Joe Conway (m...@joeconway.com) wrote: >> On 11/04/2015 01:24 PM, Alvaro Herrera wrote: >>> I agree with Pavel. Having a transaction timeout just does not make any >>> sense. I can see absolutely no use for it. An idle-in-transaction >>> timeout,

Re: [HACKERS] Request: pg_cancel_backend variant that handles 'idle in transaction' sessions

JD, On Wednesday, November 4, 2015, Joshua D. Drake wrote: > On 11/04/2015 02:15 PM, Stephen Frost wrote: > > Yeah but anything holding a lock that long can be terminated via >>> statement_timeout can it not? >>> >> >> Well, no? statement_timeout is per-statement, while

Re: [HACKERS] [patch] Proposal for \rotate in psql

2015-11-04 17:20 GMT+01:00 Joe Conway : > On 11/04/2015 04:09 AM, Pavel Stehule wrote: > > I am looking on this last patch. I talked about the name of this command > > with more people, and the name "rotate" is unhappy. The correct name for > > this visualization technique is

Re: [HACKERS] Request: pg_cancel_backend variant that handles 'idle in transaction' sessions

On 10/30/2015 10:20 PM, Merlin Moncure wrote: > Idle hanging transactions from poorly written applications are the > bane of my existence. Several months back one of them took down one > of hour production websites for several hours. > > Unfortunately, the only way to deal with them is to

Re: [HACKERS] Request: pg_cancel_backend variant that handles 'idle in transaction' sessions

On 11/04/2015 01:11 PM, Pavel Stehule wrote: I am sorry, but I have a different experience from GoodData. The few hours autovacuum is usual. So probably, there should be exception for autovacuum, dump, .. But autovacuum and dump are not idle in transaction or am I missing something? JD

Re: [HACKERS] patch for geqo tweaks

Alvaro Herrera writes: > Tom Lane wrote: >> Having said that, though, I believe that it's also probably a >> *different* initial shuffle, which may well mean that GEQO gives >> different plans in some cases. That doesn't bother me as long as >> we only make the change

Re: [HACKERS] WIP: Make timestamptz_out less slow.

On Fri, Sep 11, 2015 at 9:00 AM, David Rowley wrote: > Attached is also timestamp_delta.patch which changes pg_ltostr() to use the > INT_MIN special case that pg_ltoa also uses. I didn't make a similar change > to pg_ltostr_zeropad() as I'd need to add even more

Re: [HACKERS] Foreign join pushdown vs EvalPlanQual

Hi, I've caught up again. > OK, so if we all agree that the joined-tuple optimization is just an > option for the case where all the component tables use ROW_MARK_COPY, > I'd propose to leave that for 9.6. I still think that ExecScan is called under EPQ recheck without EQP tuple for the *scan*.

Re: [HACKERS] [patch] Proposal for \rotate in psql

Pavel Stehule wrote: > I am looking on this last patch. I talked about the name of this command > with more people, and the name "rotate" is unhappy. The correct name for > this visualization technique is "crosstab" (see google "crosstab"). The > conflict with our extension is unhappy,

Re: [HACKERS] Foreign join pushdown vs EvalPlanQual

> -Original Message- > From: Kyotaro HORIGUCHI [mailto:horiguchi.kyot...@lab.ntt.co.jp] > Sent: Thursday, November 05, 2015 10:02 AM > To: fujita.ets...@lab.ntt.co.jp > Cc: Kaigai Kouhei(海外 浩平); robertmh...@gmail.com; t...@sss.pgh.pa.us; > pgsql-hackers@postgresql.org;

Re: [HACKERS] Bitmap index scans use of filters on available columns

Hi, On 11/04/2015 11:32 PM, Tom Lane wrote: Jeff Janes writes: On Wed, Nov 4, 2015 at 7:14 AM, Tom Lane wrote: You're missing my point: that is possible in an indexscan, but *not* in a bitmap indexscan, because the index AM APIs are totally

Re: [HACKERS] Request: pg_cancel_backend variant that handles 'idle in transaction' sessions

2015-11-04 23:53 GMT+01:00 Stephen Frost : > JD, > > On Wednesday, November 4, 2015, Joshua D. Drake > wrote: > >> On 11/04/2015 02:15 PM, Stephen Frost wrote: >> >> Yeah but anything holding a lock that long can be terminated via

Re: [HACKERS] WIP: Make timestamptz_out less slow.

On 5 November 2015 at 13:20, Peter Geoghegan wrote: > On Fri, Sep 11, 2015 at 9:00 AM, David Rowley > wrote: > > Attached is also timestamp_delta.patch which changes pg_ltostr() to use > the > > INT_MIN special case that pg_ltoa also uses. I didn't

Re: [HACKERS] [patch] Proposal for \rotate in psql

2015-11-05 0:07 GMT+01:00 Daniel Verite : > Pavel Stehule wrote: > > > I am looking on this last patch. I talked about the name of this command > > with more people, and the name "rotate" is unhappy. The correct name for > > this visualization technique is

Re: [HACKERS] [patch] Proposal for \rotate in psql

On Wed, Nov 04, 2015 at 08:20:28AM -0800, Joe Conway wrote: > On 11/04/2015 04:09 AM, Pavel Stehule wrote: > > I am looking on this last patch. I talked about the name of this command > > with more people, and the name "rotate" is unhappy. The correct name for > > this visualization technique is

Re: [HACKERS] [patch] Proposal for \rotate in psql

Joe Conway wrote: > but if you don't want to conflict with the name > crosstab, perhaps "pivot" would be better? Initially I had chosen \pivot without much thought about it, but the objection was raised that a PIVOT/UNPIVOT SQL feature would likely exist in core in a next release

Re: [HACKERS] Request: pg_cancel_backend variant that handles 'idle in transaction' sessions

On 11/04/2015 02:53 PM, Stephen Frost wrote: This implies that a statement used takes a long time. It may not. The lock is held at the transaction level not the statement level, which is why a transaction level timeout is actually more useful than a statement level timeout. What I'm most

Re: [HACKERS] Re: BUG #13685: Archiving while idle every archive_timeout with wal_level hot_standby

On Wed, Nov 4, 2015 at 7:33 PM, Andres Freund wrote: > On 2015-11-04 16:01:28 +0900, Michael Paquier wrote: >> On Wed, Nov 4, 2015 at 8:39 AM, Andres Freund wrote: >> > On November 4, 2015 12:37:02 AM GMT+01:00, Michael Paquier wrote: >> >>On a completely

Re: [HACKERS] proposal: PL/Pythonu - function ereport

On Wed, Nov 4, 2015 at 10:12 AM, Pavel Stehule wrote: > It helped me lot of, thank you Welcome, I learned quite some from the process as well. >> >> >> There's just the doc part left then. > > > done We're almost there but not quite. There's still a typo in the docs:

Re: [HACKERS] [patch] Proposal for \rotate in psql

On 5 November 2015 at 05:22, Pavel Stehule wrote: > If I understand to text on wiki, the name is used for tool, that can do > little bit more things, but it is often used for this technique (so it is > much better than "rotate"). I don't understand well, why "crosstab"

Re: [HACKERS] OS X El Capitan and DYLD_LIBRARY_PATH

On 11/3/15 6:36 AM, Andres Freund wrote: > I wonder if we could fix this by using install_name_tool during the > tempinstall to add an appropriate rpath. > > Alternatively we could, apparently, specify a relative path to libraries > as explained here: >

Re: [HACKERS] OS X El Capitan and DYLD_LIBRARY_PATH

On Thu, Nov 5, 2015 at 12:17 PM, Peter Eisentraut wrote: > On 11/3/15 6:36 AM, Andres Freund wrote: >> I wonder if we could fix this by using install_name_tool during the >> tempinstall to add an appropriate rpath. >> >> Alternatively we could, apparently, specify a relative path

Re: [HACKERS] OS X El Capitan and DYLD_LIBRARY_PATH

Michael Paquier writes: > On Thu, Nov 5, 2015 at 12:17 PM, Peter Eisentraut wrote: >> That might be worth a try. I ended up disabling system integrity >> protection, which also fixed a few other strange behaviors (mysterious >> regression test

Re: [HACKERS] OS X El Capitan and DYLD_LIBRARY_PATH

On Thu, Nov 5, 2015 at 1:16 PM, Tom Lane wrote: > Michael Paquier writes: >> On Thu, Nov 5, 2015 at 12:17 PM, Peter Eisentraut wrote: >>> That might be worth a try. I ended up disabling system integrity >>> protection, which also

Re: [HACKERS] NOTIFY in Background Worker

On Sat, Aug 29, 2015 at 12:55 PM, Thomas Munro wrote: > On Sat, Aug 29, 2015 at 9:03 AM, Thomas Munro > wrote: >> >> On Fri, Aug 28, 2015 at 10:30 PM, jacques klein >> wrote: >>> >>> Hello, >>> >>> I

Re: [HACKERS] Parallel Seq Scan

On Tue, Nov 3, 2015 at 9:41 PM, Amit Kapila wrote: > On Fri, Oct 23, 2015 at 4:41 PM, Amit Kapila > wrote: >> >> On Fri, Oct 23, 2015 at 10:33 AM, Robert Haas >> wrote: > > Please find the rebased partial seq scan patch

[HACKERS] Note about comparation PL/SQL packages and our schema/extensions

Hi I had talk about possibility to implement PL/SQL packages in Postgres. The package concept is coming from ADA language and it is partially foreign/redundant element in SQL world. Oracle needs it for modularization, because schema plays different role there than in Postgres. My opinion about

Re: [HACKERS] [patch] Proposal for \rotate in psql

2015-11-05 7:39 GMT+01:00 Craig Ringer : > On 5 November 2015 at 05:22, Pavel Stehule > wrote: > > > If I understand to text on wiki, the name is used for tool, that can do > > little bit more things, but it is often used for this technique (so it

Re: [HACKERS] Request: pg_cancel_backend variant that handles 'idle in transaction' sessions

2015-11-04 20:35 GMT+01:00 Merlin Moncure : > On Wed, Nov 4, 2015 at 11:26 AM, Pavel Stehule > wrote: > > 2015-11-04 18:18 GMT+01:00 Merlin Moncure : > >> > >> On Wed, Nov 4, 2015 at 11:15 AM, Pavel Stehule

Re: [HACKERS] Request: pg_cancel_backend variant that handles 'idle in transaction' sessions

On Wed, Nov 4, 2015 at 11:26 AM, Pavel Stehule wrote: > 2015-11-04 18:18 GMT+01:00 Merlin Moncure : >> >> On Wed, Nov 4, 2015 at 11:15 AM, Pavel Stehule >> wrote: >> > >> > >> > 2015-11-04 18:11 GMT+01:00 Tom Lane

Re: [HACKERS] FORCE ROW LEVEL SECURITY

On Wed, Nov 4, 2015 at 1:48 PM, Stephen Frost wrote: > * Robert Haas (robertmh...@gmail.com) wrote: >> FORCE ROW LEVEL SECURITY doesn't behave as I would expect. >> >> rhaas=# create policy hideit on foo1 using (a < 3); >> CREATE POLICY >> rhaas=# explain select * from foo1;

Re: [HACKERS] FORCE ROW LEVEL SECURITY

Robert, * Robert Haas (robertmh...@gmail.com) wrote: > On Wed, Nov 4, 2015 at 1:48 PM, Stephen Frost wrote: > > * Robert Haas (robertmh...@gmail.com) wrote: > >> FORCE ROW LEVEL SECURITY doesn't behave as I would expect. > >> > >> rhaas=# create policy hideit on foo1 using (a

Re: [HACKERS] RFC/WIP: adding new configuration options to TOAST

On Wed, 4 Nov 2015 13:07:09 +0800 Craig Ringer wrote: > On 4 November 2015 at 10:58, Bill Moran wrote: > > On Tue, 3 Nov 2015 18:34:39 -0800 > > Jeff Janes wrote: > > > >> On Tue, Nov 3, 2015 at 5:21 PM, Craig Ringer

Re: [HACKERS] Valgrind and shared_buffers (Was: Restore-reliability mode)

Peter Geoghegan wrote: > On Mon, Jul 27, 2015 at 7:12 AM, Alvaro Herrera > wrote: > > I only tried a few tests, for lack of time, and it didn't produce any. > > (To verify that the whole thing was working properly, I reduced the > > range of memory made available during

Re: [HACKERS] Request: pg_cancel_backend variant that handles 'idle in transaction' sessions

On Wed, Nov 4, 2015 at 8:42 AM, Pavel Stehule wrote: >> > Okay, I think one more point to consider is that it would be preferable >> > to >> > have such an option for backend sessions and not for other processes >> > like WalSender. >> >> All right...I see the usage.. I

Re: [HACKERS] extend pgbench expressions with functions

Fabien COELHO wrote: > For instance for "random_gaussian(int, int, double)", it may be called with > any combination of 3 int/double arguments, each one must be tested and > possibly converted to the target type before calling the actual function. > For overloaded operators or functions

Re: [HACKERS] CustomScan support on readfuncs.c

> > On Tue, Sep 29, 2015 at 6:19 PM, Kouhei Kaigai wrote: > > >> On Mon, Sep 28, 2015 at 8:31 PM, Kouhei Kaigai > > >> wrote: > > >> >> Instead of doing this: > > >> >> > > >> >> +/* Dump library and symbol name instead of raw pointer */ > > >> >>

Re: [HACKERS] Bitmap index scans use of filters on available columns

Simon Riggs writes: > On 4 November 2015 at 15:54, Tom Lane wrote: > We generate this plan > Index Scan using f_x_y_idx on f (cost=0.42..26075.71 rows=209 width=37) >Index Cond: (x = 5) >Filter: (y ~~ '%abc%'::text) > So it should be possible

Re: [HACKERS] Request: pg_cancel_backend variant that handles 'idle in transaction' sessions

On Tue, Nov 3, 2015 at 10:33 PM, Amit Kapila wrote: > On Tue, Nov 3, 2015 at 7:56 PM, Pavel Stehule > wrote: >> >> >> >> 2015-11-03 3:42 GMT+01:00 Amit Kapila : >>> >>> On Mon, Nov 2, 2015 at 10:45 PM, Pavel Stehule

Re: [HACKERS] Request: pg_cancel_backend variant that handles 'idle in transaction' sessions

> Okay, I think one more point to consider is that it would be preferable to > > have such an option for backend sessions and not for other processes > > like WalSender. > > All right...I see the usage.. I withdraw my objection to 'session' > prefix then now that I understand the case. So, do

Re: [HACKERS] RFC/WIP: adding new configuration options to TOAST

On 4 November 2015 at 20:48, Bill Moran wrote: > On a related note, since I've been digging in this area of code I feel > comfortable commenting that pluggable compression isn't terribly difficult > to implement. The most significant work will probably be in actually >

Re: [HACKERS] Request: pg_cancel_backend variant that handles 'idle in transaction' sessions

On Wed, Nov 4, 2015 at 8:06 PM, Merlin Moncure wrote: > > On Tue, Nov 3, 2015 at 10:33 PM, Amit Kapila wrote: > It is 100% true. But the users can do strange things. If we solve idle > transactions and not idle session, then they are able to

Re: [HACKERS] Request: pg_cancel_backend variant that handles 'idle in transaction' sessions

2015-11-04 15:50 GMT+01:00 Merlin Moncure : > On Wed, Nov 4, 2015 at 8:42 AM, Pavel Stehule > wrote: > >> > Okay, I think one more point to consider is that it would be > preferable > >> > to > >> > have such an option for backend sessions and not for

Re: [HACKERS] Bitmap index scans use of filters on available columns

Nicolas Barbier writes: > 2015-11-04 Antonin Houska : >> (see expand_indexqual_opclause()), I'm not sure any kind of expansion is >> possible for '%abc%' which would result in a b-tree searchable condition. > I think the question is not about using

Re: [HACKERS] Bitmap index scans use of filters on available columns

On 4 November 2015 at 15:54, Tom Lane wrote: > Nicolas Barbier writes: > > 2015-11-04 Antonin Houska : > >> (see expand_indexqual_opclause()), I'm not sure any kind of expansion is > >> possible for '%abc%' which would result in a

Re: [HACKERS] [patch] Proposal for \rotate in psql

Hi I am looking on this last patch. I talked about the name of this command with more people, and the name "rotate" is unhappy. The correct name for this visualization technique is "crosstab" (see google "crosstab"). The conflict with our extension is unhappy, but using "rotate" is more worst -

[HACKERS] Summary of Vienna sharding summit, new TODO item

[BCC to pgsql-cluster-hack...@postgresql.org] I have summarized the Vienna cluster summit meeting from last week by adding italicized answers to the agenda questions, even though we didn't follow the agenda ;-) : https://wiki.postgresql.org/wiki/PG-EU_2015_Cluster_Summit I would like to

Re: [HACKERS] Bitmap index scans use of filters on available columns

On 4 November 2015 at 16:14, Tom Lane wrote: > Simon Riggs writes: > > On 4 November 2015 at 15:54, Tom Lane wrote: > > We generate this plan > > Index Scan using f_x_y_idx on f (cost=0.42..26075.71 rows=209 width=37) > >

Re: [HACKERS] Bitmap index scans use of filters on available columns

Simon Riggs writes: > On 4 November 2015 at 16:14, Tom Lane wrote: >> You're missing my point: that is possible in an indexscan, but *not* in a >> bitmap indexscan, because the index AM APIs are totally different in the >> two cases. In a bitmap scan,

Re: [HACKERS] Request: pg_cancel_backend variant that handles 'idle in transaction' sessions

2015-11-04 17:02 GMT+01:00 Merlin Moncure : > On Wed, Nov 4, 2015 at 8:54 AM, Pavel Stehule > wrote: > > 2015-11-04 15:50 GMT+01:00 Merlin Moncure : > >> > >> On Wed, Nov 4, 2015 at 8:42 AM, Pavel Stehule

Re: [HACKERS] Request: pg_cancel_backend variant that handles 'idle in transaction' sessions

On Wed, Nov 4, 2015 at 10:02 AM, Merlin Moncure wrote: > On Wed, Nov 4, 2015 at 8:54 AM, Pavel Stehule wrote: >> 2015-11-04 15:50 GMT+01:00 Merlin Moncure : >>> >>> On Wed, Nov 4, 2015 at 8:42 AM, Pavel Stehule

Re: [HACKERS] extend pgbench expressions with functions

Hello Alvaro, For instance for "random_gaussian(int, int, double)", it may be called with any combination of 3 int/double arguments, each one must be tested and possibly converted to the target type before calling the actual function. For overloaded operators or functions (arithmetics, abs...)

Re: [HACKERS] Request: pg_cancel_backend variant that handles 'idle in transaction' sessions

On Wed, Nov 4, 2015 at 8:54 AM, Pavel Stehule wrote: > 2015-11-04 15:50 GMT+01:00 Merlin Moncure : >> >> On Wed, Nov 4, 2015 at 8:42 AM, Pavel Stehule >> wrote: >> >> > Okay, I think one more point to consider is that it would

Re: [HACKERS] [patch] Proposal for \rotate in psql

On 11/04/2015 04:09 AM, Pavel Stehule wrote: > I am looking on this last patch. I talked about the name of this command > with more people, and the name "rotate" is unhappy. The correct name for > this visualization technique is "crosstab" (see google "crosstab"). The > conflict with our extension

Re: [HACKERS] Request: pg_cancel_backend variant that handles 'idle in transaction' sessions

2015-11-04 18:18 GMT+01:00 Merlin Moncure : > On Wed, Nov 4, 2015 at 11:15 AM, Pavel Stehule > wrote: > > > > > > 2015-11-04 18:11 GMT+01:00 Tom Lane : > >> > >> Merlin Moncure writes: > >> >> Yes, and that is

Re: [HACKERS] Request: pg_cancel_backend variant that handles 'idle in transaction' sessions

2015-11-04 18:11 GMT+01:00 Tom Lane : > Merlin Moncure writes: > >> Yes, and that is what I meant. I have two problems with > >> transaction_idle_timeout (as opposed to transaction_timeout): > >> > >> A) It's more complex. Unsophisticated administrators

Re: [HACKERS] Request: pg_cancel_backend variant that handles 'idle in transaction' sessions

On Wed, Nov 4, 2015 at 11:15 AM, Pavel Stehule wrote: > > > 2015-11-04 18:11 GMT+01:00 Tom Lane : >> >> Merlin Moncure writes: >> >> Yes, and that is what I meant. I have two problems with >> >> transaction_idle_timeout (as

Re: [HACKERS] Bitmap index scans use of filters on available columns

On 4 November 2015 at 16:59, Tom Lane wrote: > Simon Riggs writes: > > On 4 November 2015 at 16:14, Tom Lane wrote: > >> You're missing my point: that is possible in an indexscan, but *not* in > a > >> bitmap indexscan, because the

Re: [HACKERS] patch for geqo tweaks

Nathan Wagner writes: > I have two patches to make the geqo initialization and mutation > slightly better. > The first adjusts the mutation swaps to avoid having to re-pick > ties. The second changes the initialization and shuffling algorithm > for the gene array to use

Re: [HACKERS] Request: pg_cancel_backend variant that handles 'idle in transaction' sessions

Merlin Moncure writes: >> Yes, and that is what I meant. I have two problems with >> transaction_idle_timeout (as opposed to transaction_timeout): >> >> A) It's more complex. Unsophisticated administrators may not >> understand or set it properly >> >> B) There is no way

Re: [HACKERS] fortnight interval support

On Tue, Nov 3, 2015 at 6:40 PM, Michael Paquier wrote: > On Wed, Nov 4, 2015 at 2:31 AM, Robert Haas wrote: >> On Tue, Nov 3, 2015 at 8:31 AM, Alvaro Herrera >> wrote: >>> (WRT the reference to Jane Austen and

Re: [HACKERS] extend pgbench expressions with functions

Hello Kyotaro-san, [...] I understood the situation and agreed for current shape of the code. I no longer object the calling-alternatively code. But I'd like see the abbreviated discussion in the comment on the function. Indeed, this design choice deserves much better explanations. --

Re: [HACKERS] proposal: PL/Pythonu - function ereport

Hi 2015-11-04 7:06 GMT+01:00 Catalin Iacob : > Sorry, you're right, I didn't notice the x = plpy.SPIError() test. > > I did notice that you included the kw != NULL, I was explaining why it > really is needed even though it *seems* the code also works without > it. > It

Re: [HACKERS] extend pgbench expressions with functions

Hello Robert, 1. I think there should really be two patches here, the first adding functions, and the second adding doubles. Those seem like separate changes. And offhand, the double stuff looks a lot less useful that the function call syntax. I first submitted the infrastructure part, but

Re: [HACKERS] Bitmap index scans use of filters on available columns

While prefix expression y like 'abc%' can be converted to y >= 'abc' (see expand_indexqual_opclause()), I'm not sure any kind of expansion is possible for '%abc%' which would result in a b-tree searchable condition. Jeff Janes wrote: > Is there a fundamental reason the

[HACKERS] Some bugs in psql_complete of psql

Hello, I found that a typo(?) in tab-complete.c. > /* ALTER TABLE,INDEX,MATERIALIZED VIEW xxx ALL IN TABLESPACE xxx OWNED BY */ > else if (pg_strcasecmp(prev6_wd, "ALL") == 0 && >pg_strcasecmp(prev5_wd, "IN") == 0 && >pg_strcasecmp(prev4_wd, "TABLESPACE") == 0 && >

Re: [HACKERS] Foreign join pushdown vs EvalPlanQual

On 2015/11/03 22:15, Kouhei Kaigai wrote: A challenge is that junk wholerow references on behalf of ROW_MARK_COPY are injected by preprocess_targetlist(). It is earlier than the main path consideration by query_planner(), thus, it is not predictable how remote query shall be executed at this

Re: [HACKERS] Foreign join pushdown vs EvalPlanQual

> On 2015/10/28 6:04, Robert Haas wrote: > > On Tue, Oct 20, 2015 at 12:39 PM, Etsuro Fujita > > wrote: > >> Sorry, my explanation was not correct. (Needed to take in caffeine.) What > >> I'm concerned about is the following: > >> > >> SELECT * FROM localtab JOIN

Re: [HACKERS] Foreign join pushdown vs EvalPlanQual

> -Original Message- > From: Etsuro Fujita [mailto:fujita.ets...@lab.ntt.co.jp] > Sent: Wednesday, November 04, 2015 5:11 PM > To: Kaigai Kouhei(海外 浩平); Robert Haas > Cc: Tom Lane; Kyotaro HORIGUCHI; pgsql-hackers@postgresql.org; Shigeru Hanada > Subject: Re: [HACKERS] Foreign join

Re: [HACKERS] Bitmap index scans use of filters on available columns

On Wed, Nov 4, 2015 at 7:14 AM, Tom Lane wrote: > Simon Riggs writes: >> On 4 November 2015 at 15:54, Tom Lane wrote: >> We generate this plan >> Index Scan using f_x_y_idx on f (cost=0.42..26075.71 rows=209 width=37) >>Index

Re: [HACKERS] FORCE ROW LEVEL SECURITY

Robert, * Robert Haas (robertmh...@gmail.com) wrote: > FORCE ROW LEVEL SECURITY doesn't behave as I would expect. > > rhaas=# create policy hideit on foo1 using (a < 3); > CREATE POLICY > rhaas=# explain select * from foo1; >QUERY PLAN >

Re: [HACKERS] Bitmap index scans use of filters on available columns

On Wed, Nov 4, 2015 at 10:59 AM, Tom Lane wrote: > Simon Riggs writes: >> On 4 November 2015 at 16:14, Tom Lane wrote: >>> You're missing my point: that is possible in an indexscan, but *not* in a >>> bitmap indexscan, because the

Re: [HACKERS] patch for geqo tweaks

Tom Lane wrote: > Having said that, though, I believe that it's also probably a > *different* initial shuffle, which may well mean that GEQO gives > different plans in some cases. That doesn't bother me as long as > we only make the change in HEAD, but does anyone want to complain? Uh, do we

[HACKERS] FORCE ROW LEVEL SECURITY

FORCE ROW LEVEL SECURITY doesn't behave as I would expect. rhaas=# create policy hideit on foo1 using (a < 3); CREATE POLICY rhaas=# explain select * from foo1; QUERY PLAN - Seq Scan on foo1 (cost=0.00..22.70

Re: [HACKERS] FORCE ROW LEVEL SECURITY

* Robert Haas (robertmh...@gmail.com) wrote: > FORCE ROW LEVEL SECURITY doesn't behave as I would expect. > > rhaas=# create policy hideit on foo1 using (a < 3); > CREATE POLICY > rhaas=# explain select * from foo1; >QUERY PLAN >

Re: [HACKERS] Foreign join pushdown vs EvalPlanQual

On 2015/11/04 17:10, Kouhei Kaigai wrote: On 2015/10/28 6:04, Robert Haas wrote: On Tue, Oct 20, 2015 at 12:39 PM, Etsuro Fujita wrote: Sorry, my explanation was not correct. (Needed to take in caffeine.) What I'm concerned about is the following: SELECT * FROM

Re: [HACKERS] Foreign join pushdown vs EvalPlanQual

On 2015/11/04 17:28, Kouhei Kaigai wrote: I think we need to consider a general solution that can be applied not only to the case where the component tables in a foreign join all use ROW_MARK_COPY but to the case where those tables use different rowmark types such as ROW_MARK_COPY and

Re: [HACKERS] Re: BUG #13685: Archiving while idle every archive_timeout with wal_level hot_standby

On 2015-11-04 16:01:28 +0900, Michael Paquier wrote: > On Wed, Nov 4, 2015 at 8:39 AM, Andres Freund wrote: > > On November 4, 2015 12:37:02 AM GMT+01:00, Michael Paquier wrote: > >>On a completely idle system, I don't think we should log any standby > >>records. This is what

Re: [HACKERS] Bitmap index scans use of filters on available columns

2015-11-04 Antonin Houska : > While prefix expression > > y like 'abc%' > > can be converted to > > y >= 'abc' > > (see expand_indexqual_opclause()), I'm not sure any kind of expansion is > possible for '%abc%' which would result in a b-tree searchable condition. I think the