Re: [HACKERS] 9.4 release notes

On Sun, May 4, 2014 at 5:46 AM, Bruce Momjian wrote: > Feedback expected and welcomed. One item currently reads "Improve valgrind error reporting". I suggest this be changed to "Add support for Valgrind memcheck memory error detector". It was possible to use the tool before, but the lack of coop

[HACKERS] Memory deallocation after calling cast function

Hi I have problem with memory deallocation. look at the following queries 1- create table test01(a) as select generate_series(1,1)::int8 ; 2- create table test02(a) as select generate_series(1,1) ; In execution of first query, memory usage increase rapidly until the transaction

Re: [HACKERS] pg_stat directory and pg_stat_statements

On Mon, Jun 2, 2014 at 4:07 PM, Andres Freund wrote: > On 2014-06-02 22:59:55 +0900, Fujii Masao wrote: > > On Thu, May 29, 2014 at 3:02 PM, Peter Geoghegan wrote: > > > On Wed, May 28, 2014 at 10:49 PM, Fujii Masao > wrote: > > >> You're concerned about the scenario using pg_upgrade? I'm not s

Re: [HACKERS] [BUGS] BUG #9652: inet types don't support min/max

Hi, On 2014-06-03 12:43:28 +1000, Haribabu Kommi wrote: > *** a/src/test/regress/expected/create_function_3.out > --- b/src/test/regress/expected/create_function_3.out > *** > *** 153,389 RESET SESSION AUTHORIZATION; > SELECT proname, prorettype::regtype, proargtypes::regtype[]

Re: [HACKERS] Proposing pg_hibernate

On Thu, May 29, 2014 at 12:12 AM, Amit Kapila wrote: >> IMHO, all of these caveats, would affect a very small fraction of >> use-cases and are eclipsed by the benefits this extension provides in >> normal cases. > > I agree with you that there are only few corner cases where evicting > shared buff

Re: [HACKERS] Proposing pg_hibernate

On Tue, Jun 3, 2014 at 7:57 AM, Robert Haas wrote: > On Thu, May 29, 2014 at 12:12 AM, Amit Kapila wrote: >>> IMHO, all of these caveats, would affect a very small fraction of >>> use-cases and are eclipsed by the benefits this extension provides in >>> normal cases. >> >> I agree with you that t

Re: [HACKERS] Re-create dependent views on ALTER TABLE ALTER COLUMN ... TYPE?

On Mon, Jun 2, 2014 at 10:00 PM, Tom Lane wrote: >> I can see two answers. Answer #1 is >> that the column type of bar.a changes from int to bigint and the view >> definition is still SELECT a FROM foo. In that case, showing the user >> the SQL does not help them see and approve semantic changes

[HACKERS] idle_in_transaction_timeout

This patch implements a timeout for broken clients that idle in transaction. This is a TODO item. When the timeout occurs, the backend commits suicide with a FATAL ereport. I thought about just aborting the transaction to free the locks but decided that the client is clearly broken so might as w

Re: [HACKERS] idle_in_transaction_timeout

At 2014-06-03 15:06:11 +0200, vik.fear...@dalibo.com wrote: > > This patch implements a timeout for broken clients that idle in > transaction. I think this is a nice feature, but I suggest that (at the very least) the GUC should be named "idle_transaction_timeout". > + > + Termina

Re: [HACKERS] Proposal for CSN based snapshots

On Fri, May 30, 2014 at 2:38 PM, Heikki Linnakangas wrote: > (forgot to answer this question) > > On 05/30/2014 06:27 PM, Andres Freund wrote: >> >> On 2014-05-30 17:59:23 +0300, Heikki Linnakangas wrote: >>> >>> * I expanded pg_clog to 64-bits per XID, but people suggested keeping >>> pg_clog as

Re: [HACKERS] Re-create dependent views on ALTER TABLE ALTER COLUMN ... TYPE?

On Tuesday, June 3, 2014, Robert Haas [via PostgreSQL] < ml-node+s1045698n5805857...@n5.nabble.com> wrote: > On Mon, Jun 2, 2014 at 10:00 PM, Tom Lane <[hidden email] > > wrote: > > >> I can see two answers. Answer #1 is > >> that the column t

Re: [HACKERS] idle_in_transaction_timeout

On 06/03/2014 03:30 PM, Abhijit Menon-Sen wrote: > At 2014-06-03 15:06:11 +0200, vik.fear...@dalibo.com wrote: >> This patch implements a timeout for broken clients that idle in >> transaction. > I think this is a nice feature, but I suggest that (at the very least) > the GUC should be named "idle_

Re: [HACKERS] Re-create dependent views on ALTER TABLE ALTER COLUMN ... TYPE?

Robert Haas writes: > On Mon, Jun 2, 2014 at 10:00 PM, Tom Lane wrote: >> Or something else; I don't claim to be a good UI designer. But in the >> end, this is 90% a UI problem, and that means that raw SQL is seriously >> poorly suited to solve it directly. > I guess I don't agree that is 90% a

[HACKERS] pg_basebackup failed to back up large file

Hi, I got the bug report of pg_basebackup off-list that it causes an error when there is large file (e.g., 4GB) in the database cluster. It's easy to reproduce this problem. $ dd if=/dev/zero of=$PGDATA/test bs=1G count=4 $ pg_basebackup -D hoge -c fast pg_basebackup: invalid tar block header siz

Re: [HACKERS] [BUGS] BUG #9652: inet types don't support min/max

Andres Freund writes: > I didn't reall look at the patch, but it very much looks to me like that > query result could use the \a\t treatment that rules.sql and > sanity_check.sql got. It's hard to see the actual difference > before/after the patch. > I'll patch that now, to reduce the likelihood o

Re: [HACKERS] [BUGS] BUG #9652: inet types don't support min/max

On 2014-06-03 10:24:46 -0400, Tom Lane wrote: > Andres Freund writes: > > I didn't reall look at the patch, but it very much looks to me like that > > query result could use the \a\t treatment that rules.sql and > > sanity_check.sql got. It's hard to see the actual difference > > before/after the

Re: [HACKERS] pg_basebackup failed to back up large file

Hi On 2014-06-03 23:19:37 +0900, Fujii Masao wrote: > I got the bug report of pg_basebackup off-list that it causes an error > when there is large file (e.g., 4GB) in the database cluster. It's easy > to reproduce this problem. > > The cause of this problem is that pg_basebackup uses an integer t

Re: [HACKERS] [BUGS] BUG #9652: inet types don't support min/max

Andres Freund writes: > On 2014-06-03 10:24:46 -0400, Tom Lane wrote: >> Personally, I would wonder why the regression tests contain such a query >> in the first place. It seems like nothing but a major maintenance PITA. > I haven't added it, but it seems appropriate in that specific case. The >

[HACKERS] strtoll/strtoull emulation

Hi, I recently had the need to use strtoull() in postgres code. Only to discover that that's not available on some platforms. IIRC windows/msvc was one of them. Now 9d7ded0f4277f5c0063eca8e871a34e2355a8371 added another user - guarded by HAVE_STRTOULL. That commit will make things worse on windows

Re: [HACKERS] pg_basebackup failed to back up large file

Andres Freund writes: > On 2014-06-03 23:19:37 +0900, Fujii Masao wrote: >> -if (sscanf(copybuf + 124, "%11o", ¤t_len_left) != >> 1) >> +if (sscanf(copybuf + 124, "%11lo", ¤t_len_left) >> != 1) > That's probably not going to work on 32bit platforms or win

Re: [HACKERS] Proposal for CSN based snapshots

On Tue, Jun 3, 2014 at 2:55 PM, Robert Haas wrote: > That doesn't address Bruce's concern about CLOG disk consumption. Well we would only need the xid->lsn mapping for transactions since globalxmin. Anything older we would just need the committed bit. So we could maintain two structures, one like

Re: [HACKERS] pg_basebackup failed to back up large file

On Tue, Jun 3, 2014 at 4:40 PM, Tom Lane wrote: > Andres Freund writes: > > On 2014-06-03 23:19:37 +0900, Fujii Masao wrote: > >> -if (sscanf(copybuf + 124, "%11o", > ¤t_len_left) != 1) > >> +if (sscanf(copybuf + 124, "%11lo", > ¤t_len_left) != 1) > > > Th

Re: [HACKERS] [BUGS] BUG #9652: inet types don't support min/max

On 2014-06-03 10:37:53 -0400, Tom Lane wrote: > Andres Freund writes: > > On 2014-06-03 10:24:46 -0400, Tom Lane wrote: > >> Personally, I would wonder why the regression tests contain such a query > >> in the first place. It seems like nothing but a major maintenance PITA. > > > I haven't added

Re: [HACKERS] strtoll/strtoull emulation

Andres Freund writes: > I recently had the need to use strtoull() in postgres code. Only to > discover that that's not available on some platforms. IIRC windows/msvc > was one of them. Now 9d7ded0f4277f5c0063eca8e871a34e2355a8371 added > another user - guarded by HAVE_STRTOULL. That commit will ma

Re: [HACKERS] Proposing pg_hibernate

On Tue, Jun 3, 2014 at 8:13 AM, Gurjeet Singh wrote: > On Tue, Jun 3, 2014 at 7:57 AM, Robert Haas wrote: >> On Thu, May 29, 2014 at 12:12 AM, Amit Kapila >> wrote: IMHO, all of these caveats, would affect a very small fraction of use-cases and are eclipsed by the benefits this extens

Re: [HACKERS] pg_basebackup failed to back up large file

Magnus Hagander writes: > On Tue, Jun 3, 2014 at 4:40 PM, Tom Lane wrote: >> There's a far bigger problem there, which is if we're afraid that >> current_len_left might exceed 4GB then what is it exactly that guarantees >> it'll fit in an 11-digit field? > Well, we will only write 11 digits in t

Re: [HACKERS] strtoll/strtoull emulation

On 2014-06-03 10:55:17 -0400, Tom Lane wrote: > Andres Freund writes: > > I recently had the need to use strtoull() in postgres code. Only to > > discover that that's not available on some platforms. IIRC windows/msvc > > was one of them. Now 9d7ded0f4277f5c0063eca8e871a34e2355a8371 added > > anot

Re: [HACKERS] pg_basebackup failed to back up large file

On 2014-06-03 11:04:58 -0400, Tom Lane wrote: > Magnus Hagander writes: > > On Tue, Jun 3, 2014 at 4:40 PM, Tom Lane wrote: > >> There's a far bigger problem there, which is if we're afraid that > >> current_len_left might exceed 4GB then what is it exactly that guarantees > >> it'll fit in an 11

Re: [HACKERS] strtoll/strtoull emulation

Andres Freund writes: > On 2014-06-03 10:55:17 -0400, Tom Lane wrote: >> Ugh. Surely Windows has got *some* equivalent, perhaps named differently? > Apparently they've added strtoull()/stroll() to msvc 2013... And there's > _strtoui64() which seems to have already existed a while back. > But it

Re: [HACKERS] pg_basebackup failed to back up large file

On Tue, Jun 3, 2014 at 5:12 PM, Andres Freund wrote: > On 2014-06-03 11:04:58 -0400, Tom Lane wrote: > > Magnus Hagander writes: > > > On Tue, Jun 3, 2014 at 4:40 PM, Tom Lane wrote: > > >> There's a far bigger problem there, which is if we're afraid that > > >> current_len_left might exceed 4G

Re: [HACKERS] strtoll/strtoull emulation

On 2014-06-03 11:28:22 -0400, Tom Lane wrote: > Andres Freund writes: > > On 2014-06-03 10:55:17 -0400, Tom Lane wrote: > >> Ugh. Surely Windows has got *some* equivalent, perhaps named differently? > > > Apparently they've added strtoull()/stroll() to msvc 2013... And there's > > _strtoui64() w

Re: [HACKERS] pg_basebackup failed to back up large file

Andres Freund writes: > On 2014-06-03 11:04:58 -0400, Tom Lane wrote: >> My point is that having backups crash on an overflow doesn't really seem >> acceptable. IMO we need to reconsider the basebackup protocol and make >> sure we don't *need* to put values over 4GB into this field. Where's the

Re: [HACKERS] pg_basebackup failed to back up large file

On Tue, Jun 3, 2014 at 5:42 PM, Tom Lane wrote: > Andres Freund writes: > > On 2014-06-03 11:04:58 -0400, Tom Lane wrote: > >> My point is that having backups crash on an overflow doesn't really seem > >> acceptable. IMO we need to reconsider the basebackup protocol and make > >> sure we don't

Re: [HACKERS] pg_basebackup failed to back up large file

On 2014-06-03 11:42:49 -0400, Tom Lane wrote: > Andres Freund writes: > > On 2014-06-03 11:04:58 -0400, Tom Lane wrote: > >> My point is that having backups crash on an overflow doesn't really seem > >> acceptable. IMO we need to reconsider the basebackup protocol and make > >> sure we don't *nee

Re: [HACKERS] pg_basebackup failed to back up large file

On 2014-06-03 17:57:52 +0200, Magnus Hagander wrote: > On Tue, Jun 3, 2014 at 5:42 PM, Tom Lane wrote: > > What we had better do, IMO, is fix things so that we don't have a filesize > > limit in the basebackup format. After a bit of googling, I found out that > > recent POSIX specs for tar format

Re: [HACKERS] pg_basebackup failed to back up large file

On Jun 3, 2014 6:17 PM, "Andres Freund" wrote: > > On 2014-06-03 17:57:52 +0200, Magnus Hagander wrote: > > On Tue, Jun 3, 2014 at 5:42 PM, Tom Lane wrote: > > > What we had better do, IMO, is fix things so that we don't have a filesize > > > limit in the basebackup format. After a bit of googli

Re: [HACKERS] pg_basebackup failed to back up large file

On 2014-06-03 18:23:07 +0200, Magnus Hagander wrote: > On Jun 3, 2014 6:17 PM, "Andres Freund" wrote: > > PG's tar.c already uses the ustar format and the referenced extension is > > an extension to ustar as far as I understand it. So at least tarballs > > with files < 8GB would still continue to

Re: [HACKERS] pg_basebackup failed to back up large file

Magnus Hagander writes: > Yeah, that is a clear advantage of that method. Didn't read up on pax > format backwards compatibility, does it have some trick to achieve > something similar? I didn't read the fine print but it sounded like the extended header would look like a separate file entry to a

Re: [HACKERS] SP-GiST bug.

Teodor Sigaev writes: >> The point I'm making is that the scenario your test case exposes is not >> an infinite loop of picksplits, but an infinite loop of choose calls. > Thank you, now I see what I missed before. After some brainstorming, it's > possible to use '\0' only as end of string marke

[HACKERS] Hide 'Execution time' in EXPLAIN (COSTS OFF)

Hi, In 9.4. COSTS OFF for EXPLAIN prevents 'Planning time' to be printed. Should we perhaps do the same for 'Execution time'? That'd make it possible to use EXPLAIN (ANALYZE, COSTS OFF, TIMING OFF) in regression tests. Currently the output for that is: postgres=# EXPLAIN (ANALYZE, TIMING OFF, COS

Re: [HACKERS] idle_in_transaction_timeout

Vik Fearing wrote > On 06/03/2014 03:30 PM, Abhijit Menon-Sen wrote: >> At 2014-06-03 15:06:11 +0200, > vik.fearing@ > wrote: >>> This patch implements a timeout for broken clients that idle in >>> transaction. >> I think this is a nice feature, but I suggest that (at the very least) >> the GUC

Re: [HACKERS] Hide 'Execution time' in EXPLAIN (COSTS OFF)

Andres Freund writes: > In 9.4. COSTS OFF for EXPLAIN prevents 'Planning time' to be > printed. Should we perhaps do the same for 'Execution time'? That'd make > it possible to use EXPLAIN (ANALYZE, COSTS OFF, TIMING OFF) in > regression tests. > Currently the output for that is: > postgres=# EXP

Re: [HACKERS] Hide 'Execution time' in EXPLAIN (COSTS OFF)

On 2014-06-03 15:08:15 -0400, Tom Lane wrote: > Andres Freund writes: > > In 9.4. COSTS OFF for EXPLAIN prevents 'Planning time' to be > > printed. Should we perhaps do the same for 'Execution time'? That'd make > > it possible to use EXPLAIN (ANALYZE, COSTS OFF, TIMING OFF) in > > regression test

Re: [HACKERS] Hide 'Execution time' in EXPLAIN (COSTS OFF)

On Tue, Jun 3, 2014 at 3:08 PM, Tom Lane wrote: > Andres Freund writes: >> In 9.4. COSTS OFF for EXPLAIN prevents 'Planning time' to be >> printed. Should we perhaps do the same for 'Execution time'? That'd make >> it possible to use EXPLAIN (ANALYZE, COSTS OFF, TIMING OFF) in >> regression tests

Re: [HACKERS] [BUGS] BUG #9652: inet types don't support min/max

On Tue, Jun 3, 2014 at 10:48 AM, Andres Freund wrote: > On 2014-06-03 10:37:53 -0400, Tom Lane wrote: > > Andres Freund writes: > > > On 2014-06-03 10:24:46 -0400, Tom Lane wrote: > > >> Personally, I would wonder why the regression tests contain such a > query > > >> in the first place. It see

Re: [HACKERS] Hide 'Execution time' in EXPLAIN (COSTS OFF)

Robert Haas writes: > On Tue, Jun 3, 2014 at 3:08 PM, Tom Lane wrote: >> It seems a little weird to call it a "cost" ... but maybe that >> ship has sailed given how we're treating the planning-time item. > Maybe we could make it be controlled by TIMING. Seems like it fits > well-enough there.

Re: [HACKERS] Hide 'Execution time' in EXPLAIN (COSTS OFF)

On June 3, 2014 9:40:27 PM CEST, Robert Haas wrote: >On Tue, Jun 3, 2014 at 3:08 PM, Tom Lane wrote: >> Andres Freund writes: >>> In 9.4. COSTS OFF for EXPLAIN prevents 'Planning time' to be >>> printed. Should we perhaps do the same for 'Execution time'? That'd >make >>> it possible to use EXPL

Re: [HACKERS] Memory deallocation after calling cast function

Soroosh Sardari writes: > I have problem with memory deallocation. look at the following queries > 1- create table test01(a) as select generate_series(1,1)::int8 ; Do it as, eg, create table test01(a) as select g::int8 from generate_series(1,1) g; SRFs in the SELECT targetlist

Re: [HACKERS] Hide 'Execution time' in EXPLAIN (COSTS OFF)

Andres Freund wrote: > On June 3, 2014 9:40:27 PM CEST, Robert Haas wrote: > >Maybe we could make it be controlled by TIMING. Seems like it fits > >well-enough there. > > Don't think that fits well - TIMING imo is about reducing the timing > overhead. But the server side total time is still int

Re: [HACKERS] Hide 'Execution time' in EXPLAIN (COSTS OFF)

On Tue, Jun 3, 2014 at 4:02 PM, Alvaro Herrera wrote: > Andres Freund wrote: >> On June 3, 2014 9:40:27 PM CEST, Robert Haas wrote: > >> >Maybe we could make it be controlled by TIMING. Seems like it fits >> >well-enough there. >> >> Don't think that fits well - TIMING imo is about reducing the

Re: [HACKERS] Hide 'Execution time' in EXPLAIN (COSTS OFF)

Robert Haas writes: > On Tue, Jun 3, 2014 at 4:02 PM, Alvaro Herrera > wrote: >> Pah. So what we need is a new mode, REGRESSTEST ON or something. > Well, we could invent that. But I personally think piggybacking on > COSTS makes more sense. I've been eagerly waiting for 8.4 to die so I could

Re: [HACKERS] Re-create dependent views on ALTER TABLE ALTER COLUMN ... TYPE?

On Tue, Jun 3, 2014 at 10:14 AM, Tom Lane wrote: >> If we had such a mechanism, >> then perhaps someone could build a UI providing the sort of user >> feedback you're suggesting to help them use it more safely. But isn't >> the core server support the first thing? > > I'm guessing you did not rea

Re: [HACKERS] avoiding tuple copying in btree index builds

On Sun, Jun 1, 2014 at 3:26 AM, Amit Kapila wrote: > On Tue, May 6, 2014 at 12:04 AM, Robert Haas wrote: >> On Mon, May 5, 2014 at 2:13 PM, Andres Freund >> wrote: >> > On 2014-05-05 13:52:39 -0400, Robert Haas wrote: >> >> Today, I discovered that when building a btree index, the btree code >>

Re: [HACKERS] json casts

On 5/28/14, 6:48 PM, Andrew Dunstan wrote: > > On 05/27/2014 07:25 PM, Andrew Dunstan wrote: >> >> On 05/27/2014 07:17 PM, Tom Lane wrote: >>> Stephen Frost writes: * Andrew Dunstan (and...@dunslane.net) wrote: > Given that this would be a hard coded behaviour change, is it too > lat

Re: [HACKERS] Re-create dependent views on ALTER TABLE ALTER COLUMN ... TYPE?

Robert Haas writes: > On Tue, Jun 3, 2014 at 10:14 AM, Tom Lane wrote: >> I'm guessing you did not read >> http://www.postgresql.org/message-id/18723.1401734...@sss.pgh.pa.us > Argh, sorry, I saw that go by and it went past my eyes but obviously I > didn't really absorb it. I guess we could do

Re: [HACKERS] json casts

Peter Eisentraut writes: > This was solved back in the day for the xml type, which has essentially > the same requirement, by adding an ISO-8601-compatible output option to > EncodeDateTime(). See map_sql_value_to_xml_value() in xml.c. You ought > to be able to reuse that. Seems easier than rou

Re: [HACKERS] idle_in_transaction_timeout

Vik, > When the timeout occurs, the backend commits suicide with a FATAL > ereport. I thought about just aborting the transaction to free the > locks but decided that the client is clearly broken so might as well > free up the connection as well. Out of curiosity, how much harder would it have b

Re: [HACKERS] Could not finish anti-wraparound VACUUM when stop limit is reached

On Sun, May 25, 2014 at 8:40 AM, Heikki Linnakangas wrote: > While debugging the B-tree bug that Jeff Janes reported ( > http://www.postgresql.org/message-id/CAMkU=1y=VwF07Ay+Cpqk_ > 7fpihrctmssv9y99sbghitkxpb...@mail.gmail.com), a new issue came up: > > If you reach the xidStopLimit, and try to

Re: [HACKERS] idle_in_transaction_timeout

Josh Berkus writes: > Out of curiosity, how much harder would it have been just to abort the > transaction? I think breaking the connection is probably the right > behavior, but before folks start arguing it out, I wanted to know if > aborting the transaction is even a reasonable thing to do. FW

Re: [HACKERS] idle_in_transaction_timeout

Josh Berkus wrote: > Argument in favor of breaking the connection: most of the time, IITs are > caused by poor error-handling or garbage-collection code on the client > side, which has already abandoned the application session but hadn't let > go of the database handle. Since the application is n

Re: [HACKERS] json casts

On 06/03/2014 04:45 PM, Tom Lane wrote: Peter Eisentraut writes: This was solved back in the day for the xml type, which has essentially the same requirement, by adding an ISO-8601-compatible output option to EncodeDateTime(). See map_sql_value_to_xml_value() in xml.c. You ought to be able t

Re: [HACKERS] idle_in_transaction_timeout

On 06/03/2014 05:53 PM, Tom Lane wrote: Josh Berkus writes: Out of curiosity, how much harder would it have been just to abort the transaction? I think breaking the connection is probably the right behavior, but before folks start arguing it out, I wanted to know if aborting the transaction i

Re: [HACKERS] Could not finish anti-wraparound VACUUM when stop limit is reached

On Sun, May 25, 2014 at 8:53 AM, Andres Freund wrote: > On 2014-05-25 11:40:09 -0400, Heikki Linnakangas wrote: > > So, vac_truncate_clog() tries to get a new transaction ID, which fails > > because we've already reached the stop-limit. vac_truncate_clog() doesn't > > really need a new XID to be

Re: [HACKERS] idle_in_transaction_timeout

On 06/03/2014 02:53 PM, Tom Lane wrote: > Josh Berkus writes: >> Out of curiosity, how much harder would it have been just to abort the >> transaction? I think breaking the connection is probably the right >> behavior, but before folks start arguing it out, I wanted to know if >> aborting the tra

Re: [HACKERS] Allowing join removals for more join types

On Wed, May 28, 2014 at 08:39:32PM +1200, David Rowley wrote: > The attached patch allows join removals for both sub queries with left > joins and also semi joins where a foreign key can prove the existence of > the record. When a snapshot can see modifications that queued referential integrity tr

Re: [HACKERS] idle_in_transaction_timeout

On 06/04/2014 01:38 AM, Josh Berkus wrote: > On 06/03/2014 02:53 PM, Tom Lane wrote: >> Josh Berkus writes: >>> Out of curiosity, how much harder would it have been just to abort the >>> transaction? I think breaking the connection is probably the right >>> behavior, but before folks start arguin

Re: [HACKERS] idle_in_transaction_timeout

On Tue, Jun 3, 2014 at 7:40 PM, Josh Berkus [via PostgreSQL] < ml-node+s1045698n5805933...@n5.nabble.com> wrote: > On 06/03/2014 02:53 PM, Tom Lane wrote: > > > Josh Berkus <[hidden email] > > writes: > >> Out of curiosity, how much harder woul

Re: [HACKERS] Hide 'Execution time' in EXPLAIN (COSTS OFF)

On Tue, Jun 03, 2014 at 08:05:48PM +0200, Andres Freund wrote: > In 9.4. COSTS OFF for EXPLAIN prevents 'Planning time' to be > printed. Should we perhaps do the same for 'Execution time'? That'd make > it possible to use EXPLAIN (ANALYZE, COSTS OFF, TIMING OFF) in > regression tests. I have wante

Re: [HACKERS] [BUGS] BUG #9652: inet types don't support min/max

On Wed, Jun 4, 2014 at 5:46 AM, Keith Fiske wrote: > > Andres's changes on June 3rd to > https://github.com/postgres/postgres/commits/master/src/test/regress/expected/create_function_3.out > are causing patch v2 to fail for that regression test file. > > postgres $ patch -p1 -i ../inet_agg_v2.patc

Re: [HACKERS] idle_in_transaction_timeout

On 06/04/2014 02:01 AM, David G Johnston wrote: > ​Default to dropping the connection but give the usersadministrators > the capability to decide for themselves? Meh. > I still haven't heard an argument for why this wouldn't apply to > aborted idle-in-transactions. I get the focus in on releasin

Re: [HACKERS] idle_in_transaction_timeout

On Tue, Jun 3, 2014 at 5:53 PM, Tom Lane wrote: > Josh Berkus writes: >> Out of curiosity, how much harder would it have been just to abort the >> transaction? I think breaking the connection is probably the right >> behavior, but before folks start arguing it out, I wanted to know if >> abortin

[HACKERS] Perl coding error in msvc build system?

I'm not sure whether the following coding actually detects any errors: Solution.pm: open(P, "cl /? 2>&1 |") || die "cl command not found"; VSObjectFactory.pm: open(P, "nmake /? 2>&1 |") || croak "Unable to determine Visual Studio version: The nmake command wasn't found."

Re: [HACKERS] pg_stat directory and pg_stat_statements

On Tue, Jun 3, 2014 at 6:38 PM, Magnus Hagander wrote: > On Mon, Jun 2, 2014 at 4:07 PM, Andres Freund > wrote: >> >> On 2014-06-02 22:59:55 +0900, Fujii Masao wrote: >> > On Thu, May 29, 2014 at 3:02 PM, Peter Geoghegan wrote: >> > > On Wed, May 28, 2014 at 10:49 PM, Fujii Masao >> > > wrote:

Re: [HACKERS] idle_in_transaction_timeout

Robert Haas writes: > I thought the reason why this hasn't been implemented before now is > that sending an ErrorResponse to the client will result in a loss of > protocol sync. Hmm ... you are right that this isn't as simple as an ereport(ERROR), but I'm not sure it's impossible. We could for i

Re: [HACKERS] recovery testing for beta

On Mon, Jun 2, 2014 at 9:44 PM, Andres Freund wrote: > On 2014-06-02 09:03:25 -0700, Jeff Janes wrote: > > On Fri, May 30, 2014 at 8:09 PM, Amit Kapila > > > I think this is useful information and can be even included in core > > > code. > > I'd like to include something, but I think those are a

Re: [HACKERS] Proposing pg_hibernate

On Tue, Jun 3, 2014 at 5:43 PM, Gurjeet Singh wrote: > On Tue, Jun 3, 2014 at 7:57 AM, Robert Haas wrote: > > It seems like it would be best to try to do this at cluster startup > > time, rather than once recovery has reached consistency. Of course, > > that might mean doing it with a single pro

Re: [HACKERS] idle_in_transaction_timeout

On 2014-06-03 23:37:28 -0400, Tom Lane wrote: > Robert Haas writes: > > I thought the reason why this hasn't been implemented before now is > > that sending an ErrorResponse to the client will result in a loss of > > protocol sync. > > Hmm ... you are right that this isn't as simple as an ereport

Re: [HACKERS] Proposing pg_hibernate

On 2014-06-04 10:24:13 +0530, Amit Kapila wrote: > On Tue, Jun 3, 2014 at 5:43 PM, Gurjeet Singh wrote: > > On Tue, Jun 3, 2014 at 7:57 AM, Robert Haas wrote: > > > It seems like it would be best to try to do this at cluster startup > > > time, rather than once recovery has reached consistency.

[HACKERS] Need to backpatch 2985e16 to 9.3 and further (HS regression test out)

Hi, Following (commit 2985e16) has not been backpatched, I guess. ANALYZE hs1; -ERROR: cannot execute VACUUM during recovery +ERROR: cannot execute ANALYZE during recovery Attached is a patch for this. -- Amit hs-regress-expected-out-typo-fix-backpatch.patch Description: Binary data -- S