Re: [HACKERS] 10.0

On Mon, Jun 20, 2016 at 4:08 PM, Robert Haas wrote: > On Mon, Jun 20, 2016 at 4:53 PM, Joshua D. Drake > wrote: >> Or we could adopt the very reasonable and practical policy of: >> >> The current versioning scheme isn't broke, so we aren't going to

Re: [HACKERS] 10.0

On Fri, Jun 17, 2016 at 1:01 AM, Craig Ringer wrote: > On 17 June 2016 at 08:34, Greg Stark wrote: >> >> So we would release 10.0.0 and 10.0.1 and the next major release would be >> 11.0.0. >> >> This would have two benefits: >> >> 1) It emphasises that

Re: [HACKERS] 10.0

On Wed, Jun 15, 2016 at 8:59 AM, David G. Johnston <david.g.johns...@gmail.com> wrote: > On Wed, Jun 15, 2016 at 9:38 AM, Merlin Moncure <mmonc...@gmail.com> wrote: >> >> On Tue, Jun 14, 2016 at 5:48 PM, David G. Johnston >> <david.g.johns...@gmail.com> wrot

Re: [HACKERS] 10.0

On Tue, Jun 14, 2016 at 5:48 PM, David G. Johnston <david.g.johns...@gmail.com> wrote: > On Tue, Jun 14, 2016 at 5:58 PM, Merlin Moncure <mmonc...@gmail.com> wrote: >> >> On Tue, Jun 14, 2016 at 4:13 PM, Jim Nasby <jim.na...@bluetreble.com> >> wrote:

Re: [HACKERS] 10.0

On Tue, Jun 14, 2016 at 4:13 PM, Jim Nasby wrote: > On 6/14/16 3:56 PM, Tom Lane wrote: >> >> Jim Nasby writes: >>> >>> On 6/14/16 3:01 PM, Robert Haas wrote: This seems kind of silly, because anybody who is writing code that

Re: [HACKERS] 10.0

On Tue, May 17, 2016 at 12:45 AM, Craig Ringer wrote: > On 14 May 2016 at 02:49, Tom Lane wrote: >> >> * This year's major release will be 9.6.0, with minor updates 9.6.1, >> 9.6.2, etc. It's too late to do otherwise for this release cycle. >> >> *

Re: [HACKERS] Relax requirement for INTO with SELECT in pl/pgsql

On Sat, Jun 4, 2016 at 10:45 PM, David G. Johnston <david.g.johns...@gmail.com> wrote: > On Tuesday, March 22, 2016, Merlin Moncure <mmonc...@gmail.com> wrote: >> >> >> Anyways, here's the patch with documentation adjustments as promised. >> I ended up keepi

Re: [HACKERS] Changed SRF in targetlist handling

On Wed, May 25, 2016 at 3:55 PM, Tom Lane wrote: > Andres Freund writes: >> On 2016-05-25 15:20:03 -0400, Tom Lane wrote: >>> We could certainly make a variant behavior in nodeFunctionscan.c that >>> emulates that, if we feel that being exactly

Re: [HACKERS] Allow COPY to use parameters

On Fri, May 27, 2016 at 11:36 AM, Corey Huinker wrote: >> >> For the following pretend that "STRING" has the same behavior as the >> "format(...)" function. >> >> EXECUTE STRING('COPY %I TO %L', 'testtable', 'testfile.txt'); > > +1 -1 Why use syntax to do this? If we

Re: [HACKERS] Inheritance

On Tue, May 24, 2016 at 9:47 PM, Craig Ringer wrote: > On 24 May 2016 at 22:45, Konstantin Knizhnik > wrote: >> >> There is one aspect of inheritance support which was not mentioned: >> polymorphic queries. >> Actually polymorphism is the

Re: [HACKERS] Allow COPY to use parameters

On Tue, May 24, 2016 at 3:42 PM, David Fetter wrote: > On Tue, May 24, 2016 at 02:16:40PM -0400, Tom Lane wrote: >> David Fetter writes: >> > Per discussion on IRC and some test code, COPY can't take parameters >> > in a PREPARE, which feature would make it

Re: [HACKERS] Changed SRF in targetlist handling

On Mon, May 23, 2016 at 2:13 PM, David Fetter <da...@fetter.org> wrote: > On Mon, May 23, 2016 at 01:28:11PM -0500, Merlin Moncure wrote: >> On Mon, May 23, 2016 at 12:10 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> > Andres Freund <and...@anarazel.de> writes: &

Re: [HACKERS] Changed SRF in targetlist handling

On Mon, May 23, 2016 at 12:10 PM, Tom Lane wrote: > Andres Freund writes: >> discussing executor performance with a number of people at pgcon, >> several hackers - me included - complained about the additional >> complexity, both code and runtime, required

Re: [HACKERS] Inheritance

On Mon, May 23, 2016 at 10:21 AM, Jim Nasby wrote: > On 5/22/16 1:37 AM, Jan Johansson wrote: >> >> - Allow single (behavior) inheritance (model here is quite a few modern >> languages, such as C#, D, ...) >> - Allow multiple declarative inheritance (interface like,

Re: [HACKERS] 10.0

On Fri, May 13, 2016 at 1:49 PM, Tom Lane wrote: > Alvaro Herrera writes: >> Josh berkus wrote: >>> Anyway, can we come up with a consensus of some minimum changes it will >>> take to make the next version 10.0? > >> I think the next version should

Re: [HACKERS] Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0

On Fri, May 13, 2016 at 2:05 PM, Robert Haas wrote: > Now, where this gets tricky is when it comes down to whether the > end-product of that effort is something the community wants. We all > need to be careful not to make our corporate priorities into community >

Re: [HACKERS] NOT EXIST for PREPARE

On Fri, Mar 25, 2016 at 8:36 AM, Merlin Moncure <mmonc...@gmail.com> wrote: > On Wed, Mar 23, 2016 at 3:10 PM, Stephen Frost <sfr...@snowman.net> wrote: >> Just a thought. I do still like the general idea of INE support for >> PREPARE, but perhaps there's a better optio

Re: [HACKERS] modifying WaitEventSets (was: Performance degradation in commit ac1d794)

On Wed, May 4, 2016 at 2:31 PM, Tom Lane wrote: > Andres Freund writes: >> Given that poll() has been introduced in SRV3 - which IIRC was below our >> usual baseline - and windows is not an issue for latch, I think it'd >> be ok to rely on it. > > I think

Re: [HACKERS] Processes and caches in postgresql

On Mon, May 2, 2016 at 7:36 AM, Robert Haas wrote: > On Wed, Apr 27, 2016 at 7:07 AM, Anastasia Lubennikova > wrote: >> Hi, hackers. >> There's a couple of questions about processes. >> >> I found EXEC_BACKEND flag, while reading the code. >>

Re: [HACKERS] Add jsonb_compact(...) for whitespace-free jsonb to text

On Fri, Apr 29, 2016 at 4:06 PM, Andrew Dunstan wrote: > One other point: I think we really need most of these pieces - if we are > going to squash the whitespace we need functions to do that cleanly for json > and to pretty-print json. I don't think it should be squashed

Re: [HACKERS] Add jsonb_compact(...) for whitespace-free jsonb to text

On Fri, Apr 29, 2016 at 12:31 PM, Alvaro Herrera wrote: > Thanks Alex for finding the previous thread. > > Andrew Dunstan wrote: >> >> On 04/28/2016 04:29 PM, Alvaro Herrera wrote: > >> >Actually we did have someone come up with a patch to "normalize" how >> >JSON stuff

Re: [HACKERS] Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0

On Fri, Apr 29, 2016 at 11:02 AM, Simon Riggs wrote: > On 12 April 2016 at 20:25, Josh berkus wrote: > >> >> Here's the features I can imagine being worth major backwards >> compatibility breaks: >> >> 1. Fully pluggable storage with a clean API. >> >>

Re: [HACKERS] Add jsonb_compact(...) for whitespace-free jsonb to text

On Wed, Apr 27, 2016 at 4:05 PM, Stephen Frost <sfr...@snowman.net> wrote: > * Merlin Moncure (mmonc...@gmail.com) wrote: >> On Tue, Apr 26, 2016 at 11:49 AM, Stephen Frost <sfr...@snowman.net> wrote: >> > As I mentioned to Sehrope on IRC, at least for my 2c, if you w

Re: [HACKERS] Add jsonb_compact(...) for whitespace-free jsonb to text

On Tue, Apr 26, 2016 at 11:49 AM, Stephen Frost wrote: > * Ryan Pedela (rped...@datalanche.com) wrote: >> On Sun, Apr 24, 2016 at 4:02 PM, Sehrope Sarkuni wrote: >> > The default text representation of jsonb adds whitespace in between >> > key/value pairs

Re: [HACKERS] Add jsonb_compact(...) for whitespace-free jsonb to text

On Sun, Apr 24, 2016 at 8:16 PM, Andrew Dunstan wrote: > Note that the json type, unlike jsonb, preserves exactly the white space and > key order of its input. In fact, the input is exactly what it stores. That is true, but the json serialization functions (to_json etc)

Re: [HACKERS] Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0

On Mon, Apr 11, 2016 at 11:39 AM, Justin Clift wrote: > Moving over a conversation from the pgsql-advocacy mailing list. In it > Simon (CC'd) raised the issue of potentially creating a > backwards-compatibility > breaking release at some point in the future, to deal with

Re: [HACKERS] Relax requirement for INTO with SELECT in pl/pgsql

On Sun, Apr 10, 2016 at 3:13 AM, Pavel Stehule <pavel.steh...@gmail.com> wrote: > > Hi > > 2016-03-21 22:13 GMT+01:00 Pavel Stehule <pavel.steh...@gmail.com>: >> >> Hi >> >> 2016-03-21 21:24 GMT+01:00 Merlin Moncure <mmonc...@gmail.com

Re: [HACKERS] Why the "UPDATE tab SET tab.col" is invalid?

On Thu, Apr 7, 2016 at 4:39 AM, postgres_sure wrote: > Hi, > > I found "Do not include the table's name in the specification of a target > column > — for example, UPDATE tab SET tab.col = 1 is invalid." in > the documentation. > > Some people usually like

Re: [HACKERS] So, can we stop supporting Windows native now?

On Wed, Mar 30, 2016 at 6:49 PM, Josh berkus wrote: > http://www.zdnet.com/article/microsoft-and-canonical-partner-to-bring-ubuntu-to-windows-10/ > > ... could be good news for us ... This is nothing new. Windows has had a unix subsystem (Interix AKA Windows Services for

Re: [HACKERS] NOT EXIST for PREPARE

On Wed, Mar 23, 2016 at 3:10 PM, Stephen Frost <sfr...@snowman.net> wrote: > Merlin, > > * Merlin Moncure (mmonc...@gmail.com) wrote: >> No one is arguing that that you should send it any every time (at >> least -- I hope not). > > I'm not sure I follow how you can

Re: [HACKERS] NOT EXIST for PREPARE

On Thu, Mar 24, 2016 at 2:52 PM, Andreas Karlsson <andr...@proxel.se> wrote: > On 03/23/2016 09:10 PM, Stephen Frost wrote: >> >> * Merlin Moncure (mmonc...@gmail.com) wrote: >>> >>> No one is arguing that that you should send it any every time (at >>&g

Re: [HACKERS] PostgreSQL 9.6 behavior change with set returning (funct).*

On Wed, Mar 23, 2016 at 3:18 PM, Stephen Frost wrote: > I have to side with what I believe is Tom's position on this one. I do > like the notion of throwing an error in cases where someone sent us > something that we're pretty sure is wrong, but I don't agree that we > should

Re: [HACKERS] NOT EXIST for PREPARE

On Wed, Mar 23, 2016 at 2:17 PM, Vladimir Sitnikov wrote: > Merlin>proposed would allow use of server side prepared statements with JDBC. > > It would not. If we discuss end-to-end scenarios in detail, we would end up > with > "send full query on each execution" ->

Re: [HACKERS] PostgreSQL 9.6 behavior change with set returning (funct).*

On Wed, Mar 23, 2016 at 12:37 PM, Tom Lane wrote: > which is both SQL-standard semantics and much more efficient than > SRF-in-tlist. We've more or less deprecated SRF-in-tlist since we > introduced LATERAL in 9.3. How much are we willing to do to stay > bug-compatible with

Re: [HACKERS] NOT EXIST for PREPARE

On Wed, Mar 23, 2016 at 1:15 PM, Vladimir Sitnikov wrote: > Merlin>No one is arguing that that you should send it any every time (at > least -- I hope not). > > Well, what is your suggestion exactly? > > pgjdbc is NOT using "prepare ..." sql command. > I'm inclined to

Re: [HACKERS] NOT EXIST for PREPARE

On Wed, Mar 23, 2016 at 12:46 PM, Vladimir Sitnikov <sitnikov.vladi...@gmail.com> wrote: > 2016-03-23 16:21 GMT+03:00 Merlin Moncure <mmonc...@gmail.com>: > Merlin> A typical pattern is for the application to > Merlin> prepare them all upon startup, but currently each P

Re: [HACKERS] NOT EXIST for PREPARE

On Wed, Mar 23, 2016 at 8:21 AM, Merlin Moncure <mmonc...@gmail.com> wrote: > I'm not understanding the objection at all. You have N client > sessions connecting to the database that all utilize the same named > prepared statement. A typical pattern is for the application to >

Re: [HACKERS] Relax requirement for INTO with SELECT in pl/pgsql

On Wed, Mar 23, 2016 at 10:57 AM, Jim Nasby <jim.na...@bluetreble.com> wrote: > On 3/22/16 8:37 AM, Merlin Moncure wrote: >>> >>> I afraid of useless and forgotten call of functions. But the risk is same >>> >like PERFORM - so this is valid from one

Re: [HACKERS] NOT EXIST for PREPARE

On Wed, Mar 23, 2016 at 7:27 AM, Craig Ringer wrote: > With PREPARE IF NOT EXISTS the client is also paying parse and network > overhead for every time you send that statement. Much better not to send it > repeatedly in the first place. How did you determine that? The

[HACKERS] NOT EXIST for PREPARE

On Tue, Mar 22, 2016 at 9:53 AM, Andres Freund <and...@anarazel.de <javascript:;>> wrote: > On 2016-03-22 09:37:15 -0500, Merlin Moncure wrote: >> On Tue, Mar 22, 2016 at 8:01 AM, Andres Freund <and...@anarazel.de <javascript:;>> wrote: >> > Hi, >>

Re: [HACKERS] NOT EXIST for PREPARE

On Tue, Mar 22, 2016 at 8:01 AM, Andres Freund wrote: > Hi, > On 2016-03-22 12:41:43 +0300, Yury Zhuravlev wrote: >> Do I understand correctly the only way know availability PREPARE it will >> appeal to pg_prepared_statements? >> I think this is not a good practice. In some

Re: [HACKERS] Relax requirement for INTO with SELECT in pl/pgsql

On Tue, Mar 22, 2016 at 12:20 AM, Pavel Stehule wrote: > > 2016-03-22 6:06 GMT+01:00 Tom Lane : >> >> Pavel Stehule writes: >> > I can live with SELECT fx(x). It is little bit dangerous, but this risk >> > can >> > be easy

Re: [HACKERS] Relax requirement for INTO with SELECT in pl/pgsql

On Mon, Mar 21, 2016 at 5:49 PM, Tom Lane wrote: > So, I'm -1 on not having any keyword at all. I have no objection > to Merlin's proposal though. I agree that PERFORM is starting to > look a bit silly, since it doesn't play with WITH for instance. All right -- I'll submit

Re: [HACKERS] Relax requirement for INTO with SELECT in pl/pgsql

On Mon, Mar 21, 2016 at 4:13 PM, Pavel Stehule <pavel.steh...@gmail.com> wrote: > Hi > > 2016-03-21 21:24 GMT+01:00 Merlin Moncure <mmonc...@gmail.com>: >> >> Patch is trivial (see below), discussion is not :-). >> >> I see no useful reason to re

[HACKERS] Relax requirement for INTO with SELECT in pl/pgsql

Patch is trivial (see below), discussion is not :-). I see no useful reason to require INTO when returning data with SELECT. However, requiring queries to indicate not needing data via PERFORM causes some annoyances: *) converting routines back and forth between pl/pgsql and pl/sql requires

Re: [HACKERS] Remove or weaken hints about "effective resolution of sleep delays is 10 ms"?

On Wed, Feb 10, 2016 at 4:15 PM, Andres Freund wrote: > Hi, > > Several places in our docs have blurbs like >> Note that on many systems, the effective resolution of sleep delays is >> 10 milliseconds; setting wal_writer_delay to a value that >> is not a multiple of 10 might

Re: [HACKERS] proposal: make NOTIFY list de-duplication optional

On Mon, Feb 8, 2016 at 2:33 PM, Filip Rembiałkowski wrote: > Here is my next try, after suggestions from -perf and -hackers list: > > * no GUC > > * small addition to NOTIFY grammar: NOTIFY ALL/DISTINCT > > * corresponding, 3-argument version of

Re: [HACKERS] Move PinBuffer and UnpinBuffer to atomics

On Fri, Jan 29, 2016 at 3:17 PM, Alexander Korotkov wrote: > Hi, Dilip! > > On Tue, Jan 19, 2016 at 6:00 PM, Dilip Kumar wrote: >> >> >> On Tue, Jan 19, 2016 at 5:44 PM, Michael Paquier >> wrote: >>> >>> > Test3: >>> >

Re: [HACKERS] jsonb - jsonb operators

On Mon, Jan 18, 2016 at 10:50 AM, Tom Lane wrote: > Dmitry Dolgov <9erthali...@gmail.com> writes: >>> if there's any future intention to add a delete operator that removes >> element/pair matches? > >> I think the operator (jsonb - jsonb) is logical because we have a shallow

Re: [HACKERS] jsonb - jsonb operators

On Fri, Jan 15, 2016 at 7:43 AM, Glyn Astill wrote: > Hi all, > > I was just looking through the new jsonb operators in the 9.5 release, and > was wondering if there's any future intention to add a delete operator that > removes element/pair matches? I.e. some sort of

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

On Fri, Jan 8, 2016 at 7:12 AM, Greg Stark wrote: > This really sounds like you're looking for leverage to fix one problem > by finding other problems that you hope to solve with the same hammer. > That's a recipe for a tool that solves neither problem well and gets > ignored by

Re: [HACKERS] fix for readline terminal size problems when window is resized with open pager

On Wed, Dec 16, 2015 at 2:12 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Merlin Moncure <mmonc...@gmail.com> writes: >> On Wed, Dec 16, 2015 at 1:29 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> So I now think that print.c shouldn't be involved at all, and th

Re: [HACKERS] fix for readline terminal size problems when window is resized with open pager

On Wed, Dec 16, 2015 at 1:29 PM, Tom Lane wrote: > I did some more experimentation and concluded that actually, this problem > has nothing whatsoever to do with pager invocations. What seems to really > be happening is that libreadline activates its SIGWINCH handler only

Re: [HACKERS] fix for readline terminal size problems when window is resized with open pager

On Wed, Dec 16, 2015 at 12:06 PM, Andres Freund wrote: > On 2015-12-16 13:02:25 -0500, Tom Lane wrote: >> I think the most reasonable way to handle this is to put the >> call into a new function exported from input.c, where it can be >> made conditional on useReadline. > >

Re: [HACKERS] fix for readline terminal size problems when window is resized with open pager

On Mon, Dec 14, 2015 at 2:50 PM, Tom Lane wrote: > Alvaro Herrera writes: >> Tom Lane wrote: >>> Quick followup: rl_resize_terminal() exists in GNU readline at least as >>> far back as 4.0 (released Feb 1999). However, it doesn't seem to be there

Re: [HACKERS] [sqlsmith] Failed to generate plan on lateral subqueries

On Thu, Dec 10, 2015 at 4:55 AM, Andreas Seltenreich <seltenre...@gmx.de> wrote: > Tom Lane writes: > >> Merlin Moncure <mmonc...@gmail.com> writes: >>> Aside from the functional issues, could your changes result in >>> performance regressions? &g

Re: [HACKERS] [sqlsmith] Failed to generate plan on lateral subqueries

On Wed, Dec 9, 2015 at 4:18 PM, Tom Lane wrote: > David Fetter writes: >> On Tue, Dec 08, 2015 at 12:13:41PM -0500, Tom Lane wrote: >>> Hm. At least in the first of these cases, the problem is that the >>> code I committed yesterday doesn't account for

[HACKERS] fix for readline terminal size problems when window is resized with open pager

Hello, The following patch deals with a long standing gripe of mine that the terminal frequently gets garbled so that when typing. I guess this problem is entirely dependent on pager settings and your interaction patterns with the window (in particular, if you tend to resize the window when the

Re: [HACKERS] fix for readline terminal size problems when window is resized with open pager

On Tue, Dec 8, 2015 at 2:33 PM, Merlin Moncure <mmonc...@gmail.com> wrote: > On Tue, Dec 8, 2015 at 2:02 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> I wrote: >>> Merlin Moncure <mmonc...@gmail.com> writes: >>>> The following patch deals with a lo

Re: [HACKERS] fix for readline terminal size problems when window is resized with open pager

On Tue, Dec 8, 2015 at 2:02 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > I wrote: >> Merlin Moncure <mmonc...@gmail.com> writes: >>> The following patch deals with a long standing gripe of mine that the >>> terminal frequently gets garbled so that

Re: [HACKERS] fix for readline terminal size problems when window is resized with open pager

On Tue, Dec 8, 2015 at 2:02 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > I wrote: >> Merlin Moncure <mmonc...@gmail.com> writes: >>> The following patch deals with a long standing gripe of mine that the >>> terminal frequently gets garbled so that

Re: [HACKERS] Some questions about the array.

On Tue, Dec 1, 2015 at 8:46 AM, YUriy Zhuravlev wrote: > On Tuesday 01 December 2015 08:38:21 you wrote: >> it (zero >> based indexing support) doesn't meet the standard of necessity for >> adding to the core API and as stated it's much to magical. > > We do not touch

Re: [HACKERS] Some questions about the array.

On Mon, Nov 30, 2015 at 3:05 PM, YUriy Zhuravlev wrote: > On Monday 30 November 2015 08:58:49 you wrote: >> +1 IMO this line of thinking is a dead end. Better handled via >> functions, not syntax > > Maybe then add array_pyslice(start, end) when start is 0 and with

Re: [HACKERS] Some questions about the array.

On Thu, Nov 26, 2015 at 6:08 AM, Teodor Sigaev wrote: > YUriy Zhuravlev wrote: >> >> On Friday 06 November 2015 12:55:44 you wrote: >>> >>> Omitted bounds are common in other languages and would be handy. I >>> don't think they'd cause any issues with multi-dimensional arrays or

Re: [HACKERS] Conversion error of floating point numbers in pl/pgsql

On Tue, Nov 17, 2015 at 9:00 PM, Robert Haas wrote: > On Mon, Nov 16, 2015 at 9:49 AM, Tom Lane wrote: >> Kyotaro HORIGUCHI writes: >>> Hello. I found that 9.5 has an undocumented difference from 9.4 >>> in type cast in

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

On Wed, Nov 4, 2015 at 4:15 PM, Stephen Frost wrote: > * 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.

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

On Thu, Nov 5, 2015 at 12:09 PM, Pavel Stehule <pavel.steh...@gmail.com> wrote: > > Dne 5.11.2015 19:02 napsal uživatel "Merlin Moncure" <mmonc...@gmail.com>: >> >> On Wed, Nov 4, 2015 at 4:15 PM, Stephen Frost <sfr...@snowman.net> wrote: >>

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

On Thu, Nov 5, 2015 at 12:31 PM, Joe Conway <m...@joeconway.com> wrote: > On 11/05/2015 10:09 AM, Pavel Stehule wrote: >> On 5.11.2015 19:02 Merlin Moncure wrote: >>> Thus, I think we have consensus that transaction_timeout is good -- it >>> would deprecate stateme

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

On Wed, Nov 4, 2015 at 2:09 PM, Pavel Stehule <pavel.steh...@gmail.com> wrote: > 2015-11-04 20:35 GMT+01:00 Merlin Moncure <mmonc...@gmail.com>: >> >> On Wed, Nov 4, 2015 at 11:26 AM, Pavel Stehule <pavel.steh...@gmail.com> >> > it doesn't help. How I ca

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

On Wed, Nov 4, 2015 at 11:26 AM, Pavel Stehule <pavel.steh...@gmail.com> wrote: > 2015-11-04 18:18 GMT+01:00 Merlin Moncure <mmonc...@gmail.com>: >> >> On Wed, Nov 4, 2015 at 11:15 AM, Pavel Stehule <pavel.steh...@gmail.com> >> wrote: >> >

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] 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

On Wed, Nov 4, 2015 at 10:02 AM, Merlin Moncure <mmonc...@gmail.com> wrote: > On Wed, Nov 4, 2015 at 8:54 AM, Pavel Stehule <pavel.steh...@gmail.com> wrote: >> 2015-11-04 15:50 GMT+01:00 Merlin Moncure <mmonc...@gmail.com>: >>> >>> On Wed, Nov

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

On Wed, Nov 4, 2015 at 8:54 AM, Pavel Stehule <pavel.steh...@gmail.com> wrote: > 2015-11-04 15:50 GMT+01:00 Merlin Moncure <mmonc...@gmail.com>: >> >> On Wed, Nov 4, 2015 at 8:42 AM, Pavel Stehule <pavel.steh...@gmail.com> >> wrote: >> >> > Oka

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

On Wed, Nov 4, 2015 at 11:15 AM, Pavel Stehule <pavel.steh...@gmail.com> wrote: > > > 2015-11-04 18:11 GMT+01:00 Tom Lane <t...@sss.pgh.pa.us>: >> >> Merlin Moncure <mmonc...@gmail.com> writes: >> >> Yes, and that is what I meant. I ha

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

On Mon, Nov 2, 2015 at 1:23 PM, Jim Nasby wrote: > On 11/2/15 11:15 AM, Pavel Stehule wrote: >> >> I have not strong idea about how to solve it well - maybe introduce >> transaction_idle_timeout and session_idle_timeout? > > > Yes, please. This is a very common problem.

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

On Mon, Nov 2, 2015 at 8:42 PM, Amit Kapila wrote: > On Mon, Nov 2, 2015 at 10:45 PM, Pavel Stehule > 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

Re: [HACKERS] fortnight interval support

On Sun, Nov 1, 2015 at 2:20 PM, David Fetter wrote: > On Sun, Nov 01, 2015 at 01:06:39PM -0500, Tom Lane wrote: >> David Fetter writes: >> > On Tue, Oct 27, 2015 at 07:30:13PM +, Nathan Wagner wrote: >> >> On Wed, Oct 28, 2015 at 08:17:25AM +1300, Gavin

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

On Mon, Nov 2, 2015 at 1:28 AM, Pavel Stehule wrote: > > > 2015-11-02 5:23 GMT+01:00 Amit Kapila : >> >> On Sun, Nov 1, 2015 at 11:34 PM, Tom Lane wrote: >> > >> > Magnus Hagander writes: >> > > On Sat,

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

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 terminate the backend which is heavy handed and in some cases

Re: [HACKERS] fortnight interval support

On Tue, Oct 27, 2015 at 8:52 AM, Nathan Wagner wrote: > On Mon, Oct 26, 2015 at 01:58:52PM -0400, Robert Haas wrote: >> Aw, you're no fun. select '1 fortnight'::interval => '14 days' would be >> cool. > > Patch attached... > > :) This is very cool (you are 100% certain

Re: [HACKERS] No Issue Tracker - Say it Ain't So!]

On Mon, Oct 5, 2015 at 5:32 AM, Magnus Hagander wrote: > > > On Mon, Oct 5, 2015 at 12:42 AM, Nathan Wagner > wrote: >> >> I don't have the original message for this thread, so I arbitrarily picked >> a >> message to reply to. >> >> Since what has been

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

On Thu, Oct 1, 2015 at 10:18 AM, Tom Lane wrote: > Andres Freund writes: >> On 2015-10-01 11:07:12 -0400, Tom Lane wrote: >>> As one of the people who do most of the gruntwork for release notes, >>> I can tell you that that sort of fixed-format annotation

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

On Thu, Oct 1, 2015 at 12:09 PM, Josh Berkus wrote: > On 10/01/2015 07:55 AM, Tom Lane wrote: >> Playing devil's advocate ... would this really do much other than bloat >> the release notes? The entire assumption of this thread is that people >> don't, or don't want to, use

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

On Wed, Sep 30, 2015 at 12:43 PM, Josh Berkus <j...@agliodbs.com> wrote: > On 09/30/2015 07:44 AM, Merlin Moncure wrote: >> I'm not trolling in any way. I'm just challenging you to back up your >> blanket assertions with evidence. For example, you're assertion

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

On Wed, Sep 30, 2015 at 7:17 AM, Kam Lasater <c...@seekayel.com> wrote: > On Tue, Sep 29, 2015 at 6:39 PM, Josh Berkus <j...@agliodbs.com> wrote: >> On 09/29/2015 03:08 PM, Merlin Moncure wrote: >>> I've read this email about three times now and it's not clear at

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

On Wed, Sep 23, 2015 at 1:18 PM, Kam Lasater wrote: > Hello, > > Last night I heard that Postgres had no issue/bug tracker. At first I > thought the guy was trolling me. Seriously, how could this be. Certainly a > mature open source project that is the database for a measurable

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

On Tue, Sep 29, 2015 at 12:42 PM, Joshua D. Drake <j...@commandprompt.com> wrote: > On 09/29/2015 07:25 AM, Merlin Moncure wrote: >> >> On Wed, Sep 23, 2015 at 1:18 PM, Kam Lasater <c...@seekayel.com> wrote: >>> >>> Hello, >>> >>

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

On Fri, Sep 25, 2015 at 11:32 AM, Tom Lane wrote: > Simon Riggs writes: >> I have frequently been the agent of change in matters of process, but I see >> no useful change here, just lots of wasted time. But then why are we even >> talking about change?

Re: [HACKERS] Inaccurate results from numeric ln(), log(), exp() and pow()

On Wed, Sep 16, 2015 at 2:31 AM, Dean Rasheed wrote: > Hi, > > I recently noticed that numeric log() produces inaccurate results for > certain ranges of inputs. This isn't just small errors in the last 1 > or 2 digits, but sometimes quite large errors, with over half the

Re: [HACKERS] Inaccurate results from numeric ln(), log(), exp() and pow()

On Wed, Sep 16, 2015 at 10:14 AM, Dean Rasheed <dean.a.rash...@gmail.com> wrote: > On 16 September 2015 at 14:49, Merlin Moncure <mmonc...@gmail.com> wrote: >>> AFAICT, this kind of slowdown only happens in cases like this where a >>> very large number of digits

Re: [HACKERS] Move PinBuffer and UnpinBuffer to atomics

On Tue, Sep 15, 2015 at 9:56 AM, Andres Freund <and...@anarazel.de> wrote: > On 2015-09-15 08:07:57 -0500, Merlin Moncure wrote: >> Also, I'm curious about your introduction of __builtin_expect() >> macros. Did you measure any gain from them? > > I introduced

Re: [HACKERS] Move PinBuffer and UnpinBuffer to atomics

On Mon, Sep 14, 2015 at 9:06 PM, Andres Freund wrote: > On 2015-09-14 17:41:42 +0200, Andres Freund wrote: >> I pointed out how you can actually make this safely lock-free giving you >> the interesting code. > > And here's an actual implementation of that approach. It's

Re: [HACKERS] Autonomous Transaction is back

On Thu, Sep 10, 2015 at 8:39 PM, Noah Misch wrote: > On Wed, Sep 09, 2015 at 10:04:01AM -0400, Robert Haas wrote: >> On Sun, Sep 6, 2015 at 1:56 AM, Noah Misch wrote: >> > What design principle(s) have you been using to decide how autonomous >> >

Re: [HACKERS] Autonomous Transaction is back

On Wed, Sep 9, 2015 at 9:04 AM, Robert Haas wrote: > On Sun, Sep 6, 2015 at 1:56 AM, Noah Misch wrote: >> What design principle(s) have you been using to decide how autonomous >> transactions should behave? > > I have to admit to a complete lack of

Re: [HACKERS] Horizontal scalability/sharding

On Mon, Sep 7, 2015 at 1:33 PM, Ahsan Hadi wrote: > I > > On Monday, September 7, 2015, Ashutosh Bapat > wrote: >> >> >> >> On Sat, Sep 5, 2015 at 4:22 AM, Ozgun Erdogan wrote: >>> >>> Hey Robert, >>> Now

Re: [HACKERS] Autonomous Transaction is back

On Sun, Sep 6, 2015 at 12:56 AM, Noah Misch wrote: > My comments have flowed out of a principle that autonomous transactions shall > have precisely the same semantics as using another backend via dblink. That's what I thought, too. AT is syntax sugar for dblink approach.

Re: [HACKERS] Allow a per-tablespace effective_io_concurrency setting

On Fri, Sep 4, 2015 at 11:21 AM, Greg Stark <st...@mit.edu> wrote: > On Thu, Sep 3, 2015 at 2:13 PM, Merlin Moncure <mmonc...@gmail.com> wrote: >> I find this talk of platters and spindles to be somewhat >> baroque; for a 200$ part I have to work pretty hard to max ou

Re: [HACKERS] Allow a per-tablespace effective_io_concurrency setting

On Wed, Sep 2, 2015 at 5:38 PM, Andres Freund wrote: > If you additionally take into account hardware realities where you have > multiple platters, multiple spindles, command queueing etc, that's even > more true. A single rotation of a single platter with command queuing >

Re: [HACKERS] Horizontal scalability/sharding

On Tue, Sep 1, 2015 at 11:18 AM, Robert Haas wrote: > It would be a bad idea to cling blindly to the FDW infrastructure if > it's fundamentally inadequate to do what we want. On the other hand, > it would also be a bad idea to set about recreating it without a > really

<    1   2   3   4   5   6   7   8   9   10   >