Re: [HACKERS] psql :: support for \ev viewname and \sv viewname

Just a merge after pgindent run (807b9e0dff663c5da875af7907a5106c0ff90673). psql-ev-sv-support-v3.diff Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] extend pgbench expressions with functions

v7: rebase after pgindent run for 9.6. -- Fabien.diff --git a/doc/src/sgml/ref/pgbench.sgml b/doc/src/sgml/ref/pgbench.sgml index a808546..d09b2bf 100644 --- a/doc/src/sgml/ref/pgbench.sgml +++ b/doc/src/sgml/ref/pgbench.sgml @@ -762,7 +762,7 @@ pgbench options dbname references to vari

Re: [HACKERS] Run pgindent now?

Bruce Momjian writes: > On Sun, May 24, 2015 at 04:16:07AM +0200, Andres Freund wrote: >> - if (IsA(node, Aggref) || IsA(node, GroupingFunc)) >> + if (IsA(node, Aggref) ||IsA(node, GroupingFunc)) >> >> There's a bunch of changes like this. Looks rather odd to me? I don't >> recall seing much

Re: [HACKERS] Re: [COMMITTERS] pgsql: Map basebackup tablespaces using a tablespace_map file

On Sat, May 23, 2015 at 9:28 PM, Andrew Dunstan wrote: > > > On 05/23/2015 01:29 AM, Amit Kapila wrote: >> > Find the patch which gets rid of rmtree usage. I have made it as >> > a separate function because the same code is used from >> > create_tablespace_directories() as well. I thought of ext

Re: [HACKERS] Run pgindent now?

On Sun, May 24, 2015 at 04:16:07AM +0200, Andres Freund wrote: > On 2015-05-23 21:36:50 -0400, Bruce Momjian wrote: > > pgindent run on HEAD and committed. > > - if (IsA(node, Aggref) || IsA(node, GroupingFunc)) > + if (IsA(node, Aggref) ||IsA(node, GroupingFunc)) > > There's a bunch of chang

Re: [HACKERS] Run pgindent now?

On 2015-05-23 21:36:50 -0400, Bruce Momjian wrote: > pgindent run on HEAD and committed. - if (IsA(node, Aggref) || IsA(node, GroupingFunc)) + if (IsA(node, Aggref) ||IsA(node, GroupingFunc)) There's a bunch of changes like this. Looks rather odd to me? I don't recall seing much code looking

Re: [HACKERS] Run pgindent now?

On Sat, May 23, 2015 at 12:32:34PM -0400, Tom Lane wrote: > Bruce Momjian writes: > > Are we ready for a pgindent run? Back branches? > > I think we could do it in HEAD, but it doesn't seem like we have consensus > about whether to touch the back branches. Suggest just HEAD for now and > we can

Re: [HACKERS] fsync-pgdata-on-recovery tries to write to more files than previously

On 2015-05-23 16:33:29 -0400, Tom Lane wrote: > Christoph Berg writes: > > the new fsync-pgdata-on-recovery code tries to open all files using > > O_RDWR. At least on 9.1, this can make recovery fail: > > Hm. I wonder whether it would be all right to just skip files for which > we get EPERM on o

Re: [HACKERS] RFC: Non-user-resettable SET SESSION AUTHORISATION

On Tue, May 19, 2015 at 04:49:26PM -0400, Robert Haas wrote: > On Tue, May 19, 2015 at 3:00 PM, Simon Riggs wrote: > > As long as the cookie is randomly generated for each use, then I don't see a > > practical problem with that approach. > > If the client sets the cookie via an SQL command, that

Re: [HACKERS] jsonb_set: update or upsert default?

On 05/23/2015 04:03 PM, Petr Jelinek wrote: On 23/05/15 17:59, David E. Wheeler wrote: On May 22, 2015, at 7:22 PM, Andrew Dunstan wrote: The proposed flag for jsonb_set (the renamed jsonb_replace) in the patch I recently published is set to false, meaning that the default behaviour is to r

Re: [HACKERS] fsync-pgdata-on-recovery tries to write to more files than previously

Re: Tom Lane 2015-05-23 <2284.1432413...@sss.pgh.pa.us> > Christoph Berg writes: > > the new fsync-pgdata-on-recovery code tries to open all files using > > O_RDWR. At least on 9.1, this can make recovery fail: > > Hm. I wonder whether it would be all right to just skip files for which > we get

Re: [HACKERS] Disabling trust/ident authentication configure option

Josh Berkus writes: > So from my perspective anything which requires going off standard > PostgreSQL packages, and encourages users to go off standard PostgreSQL > packages, is a actually a fairly high cost even if the code is > non-invasive. Agreed. > I would be more open to a GUC which limited

Re: [HACKERS] fsync-pgdata-on-recovery tries to write to more files than previously

Christoph Berg writes: > the new fsync-pgdata-on-recovery code tries to open all files using > O_RDWR. At least on 9.1, this can make recovery fail: Hm. I wonder whether it would be all right to just skip files for which we get EPERM on open(). The argument being that if we can't write to the f

Re: [HACKERS] [COMMITTERS] pgsql: Allow GiST distance function to return merely a lower-bound.

I wrote: > Heikki Linnakangas writes: >> Allow GiST distance function to return merely a lower-bound. > I wondered how come this patch did not touch nodeIndexonlyscan.c. > After some investigation, it seems the only reason that this patch even > appears to work is that none of the built-in or co

[HACKERS] Re: fsync-pgdata-on-recovery tries to write to more files than previously

Re: To PostgreSQL Hackers 2015-05-23 <20150523172627.ga24...@msg.df7cb.de> > Hi, > > the new fsync-pgdata-on-recovery code tries to open all files using > O_RDWR. At least on 9.1, this can make recovery fail: > > * launch postgres, hit ^\ (or otherwise shut down uncleanly) > * touch foo; chmod 44

Re: [HACKERS] xid wrap / optimize frozen tables?

On Sat, May 23, 2015 at 6:46 AM, Nils Goroll wrote: > Hi, > > as many before, I ran into the issue of a postgresql database (8.4.1) > - committing many transactions > - to huge volume tables (3-figure GB in size) > - running the xid wrap vacuum (to freeze tuples) > > where the additional read IO

Re: [HACKERS] Compiler warning about overflow in xlog.c

Petr Jelinek writes: > my compiler complains about overflow in xlog.c. Yeah, Peter E. reported this yesterday. Since Heikki didn't do anything about that yet, I pushed your fix. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To

Re: [HACKERS] jsonb_set: update or upsert default?

On 23/05/15 17:59, David E. Wheeler wrote: On May 22, 2015, at 7:22 PM, Andrew Dunstan wrote: The proposed flag for jsonb_set (the renamed jsonb_replace) in the patch I recently published is set to false, meaning that the default behaviour is to require all elements of the path including the

[HACKERS] Compiler warning about overflow in xlog.c

Hi, my compiler complains about overflow in xlog.c. There is variable defined as char partialfname[MAXFNAMELEN]; but is used as snprintf(partialfname, MAXPGPATH, "%s.partial", origfname); There is no practical issue as the actual filename length is never over MAXFNAMELEN even with the .parti

Re: [HACKERS] [COMMITTERS] pgsql: Allow GiST distance function to return merely a lower-bound.

Heikki Linnakangas writes: > Allow GiST distance function to return merely a lower-bound. I wondered how come this patch did not touch nodeIndexonlyscan.c. After some investigation, it seems the only reason that this patch even appears to work is that none of the built-in or contrib opclasses su

Re: [HACKERS] Asynchronous DRAM Self-Refresh

On 22/05/15 22:30, Josh Berkus wrote: > At CoreOS Fest, Intel presented about a technology which they used to > improve write times for the nonrelational data store Etcd. It's called > Asynchronous DRAM Self-Refresh, or ADR. This is supposedly a feature of > all of their chips since E5 which allo

Re: [HACKERS] Asynchronous DRAM Self-Refresh

On 22/05/15 22:30, Josh Berkus wrote: > At CoreOS Fest, Intel presented about a technology which they used to > improve write times for the nonrelational data store Etcd. It's called > Asynchronous DRAM Self-Refresh, or ADR. This is supposedly a feature of > all of their chips since E5 which allo

Re: [HACKERS] [GENERAL] psql weird behaviour with charset encodings

On Sat, May 08, 2010 at 09:24:45PM -0400, Tom Lane wrote: > hgonza...@gmail.com writes: > > http://sources.redhat.com/bugzilla/show_bug.cgi?id=649 > > > The last explains why they do not consider it a bug: > > > ISO C99 requires for %.*s to only write complete characters that fit below > > the

Re: [HACKERS] xid wrap / optimize frozen tables?

On 23/05/15 16:50, Tom Lane wrote: >> > as many before, I ran into the issue of a postgresql database (8.4.1) > *Please* tell us that was a typo. Yes it was, my sincere apologies. It's 9.4.1 Nils -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your sub

[HACKERS] fsync-pgdata-on-recovery tries to write to more files than previously

Hi, the new fsync-pgdata-on-recovery code tries to open all files using O_RDWR. At least on 9.1, this can make recovery fail: * launch postgres, hit ^\ (or otherwise shut down uncleanly) * touch foo; chmod 444 foo * launch postgres LOG: database system was interrupted; last known up at 2015-05-

Re: [HACKERS] Run pgindent now?

Bruce Momjian writes: > Are we ready for a pgindent run? Back branches? I think we could do it in HEAD, but it doesn't seem like we have consensus about whether to touch the back branches. Suggest just HEAD for now and we can continue to argue about the back branches. r

Re: [HACKERS] Run pgindent now?

On Fri, May 22, 2015 at 12:02:11PM -0400, Tom Lane wrote: > I guess in the > scenario you're describing, the most helpful thing would be if the > pgindent commit put the typedef list it had used into the tree, and then > we just use that (plus manual additions) when generating the I' commit. I hav

Re: [HACKERS] Re: [COMMITTERS] pgsql: Map basebackup tablespaces using a tablespace_map file

On 05/23/2015 01:29 AM, Amit Kapila wrote: On Fri, May 15, 2015 at 11:51 AM, Amit Kapila > wrote: > > On Thu, May 14, 2015 at 10:29 PM, Andrew Dunstan mailto:and...@dunslane.net>> wrote: > > > > > > On 05/14/2015 10:52 AM, Robert Haas wrote: > >> > >> On Thu, Ma

Re: [HACKERS] jsonb_set: update or upsert default?

On May 22, 2015, at 7:22 PM, Andrew Dunstan wrote: > The proposed flag for jsonb_set (the renamed jsonb_replace) in the patch I > recently published is set to false, meaning that the default behaviour is to > require all elements of the path including the last to be present. What that > does i

Re: [HACKERS] xid wrap / optimize frozen tables?

Nils Goroll writes: > as many before, I ran into the issue of a postgresql database (8.4.1) *Please* tell us that was a typo. If it wasn't, there were possibly-relevant fixes in 8.4.6, 8.4.9, and perhaps later; I got tired of scanning the release notes. 8.4.x is out of support entirely now, of

Re: [HACKERS] xid wrap / optimize frozen tables?

On Sat, May 23, 2015 at 03:46:33PM +0200, Nils Goroll wrote: > Hi, > > as many before, I ran into the issue of a postgresql database (8.4.1) Uh, did you mean 9.4.1 as 8.4.1 is end-of-lifed. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterpris

[HACKERS] xid wrap / optimize frozen tables?

Hi, as many before, I ran into the issue of a postgresql database (8.4.1) - committing many transactions - to huge volume tables (3-figure GB in size) - running the xid wrap vacuum (to freeze tuples) where the additional read IO load has negative impact to the extent of the system becoming unusab

Re: [HACKERS] Change pg_cancel_*() to ignore current backend

On Sat, May 23, 2015 at 7:43 AM, Tom Lane wrote: > Andres Freund writes: >> This whole discussion seems to be about making it easier to run SELECT >> pg_cancel_backend(pid) FROM pg_stat_activity;. But that shouldn't be >> made easier! If anything harder. > > Indeed. I find it hard to believe tha