[HACKERS] Set of patch to address several Coverity issues

Hi all, As there have been complaints that it was hard to follow all the small patches I have sent to fix the issues related to Coverity, here they are gathered with patches for each one of them: 1) Missing return value checks in jsonfuncs.c, fixed by 0001 (send here previously => cab7npqqcj3hu9p7

Re: [HACKERS] RFC: replace pg_stat_activity.waiting with something more descriptive

On Tue, Jun 30, 2015 at 10:30 PM, Amit Kapila wrote: > On Fri, Jun 26, 2015 at 6:26 PM, Robert Haas wrote: >> >> On Thu, Jun 25, 2015 at 11:57 PM, Amit Kapila >> wrote: >> >> >> 3. Add new view 'pg_stat_wait_event' with following info: >> >> >> pid - process id of this backend >> >> >> waiting

Re: [HACKERS] Memory Accounting v11

On 7 July 2015 at 18:59, Jeff Davis wrote: > On Tue, 2015-07-07 at 16:49 +1200, David Rowley wrote: > > I might be mistaken here, but can't you just set context->mem_allocted > > = 0; after that loop? > > Or maybe it would be an improvement to only do the decrement > > if MEMORY_CONTEXT_CHECKING

Re: [HACKERS] New functions

On Mon, Mar 23, 2015 at 12:46 PM, Michael Paquier wrote: > On Mon, Mar 23, 2015 at 1:48 AM, Воронин Дмитрий > wrote: >> >>> Please, attach new version of my patch to commitfest page. >> >> Michael, I found a way to attach patch. sorry to trouble. > > Cool. Thanks. I am seeing your patch entry he

Re: [HACKERS] Dependency between bgw_notify_pid and bgw_flags

In CleanupBackgroundWorker(), we seem to differentiate between a background worker with shared memory access and a backend. 2914 /* 2915 * Additionally, for shared-memory-connected workers, just like a 2916 * backend, any exit status other than 0 or 1 is considered a cras

Re: [HACKERS] [PATCH] Add missing \ddp psql command

On Tue, Jul 7, 2015 at 2:11 AM, David Christensen wrote: > Quickie patch for spotted missing psql \ddp tab-completion. Thanks for the report and patch! I found that tab-completion was not supported in not only \ddp but also other psql meta commands like \dE, \dm, \dO, \dy, \s and \setenv. Attach

Re: [HACKERS] [BUGS] BUG #13126: table constraint loses its comment

On 2015-07-04 13:45, Michael Paquier wrote: On Fri, Jul 3, 2015 at 11:59 PM, Petr Jelinek wrote: Well for indexes you don't really need to add the new AT command, as IndexStmt has char *idxcomment which it will automatically uses as comment if not NULL. While I am not huge fan of the idxcomment

Re: [HACKERS] Transactions involving multiple postgres foreign servers

On 02/17/2015 11:26 AM, Ashutosh Bapat wrote: Hi All, Here are the steps and infrastructure for achieving atomic commits across multiple foreign servers. I have tried to address most of the concerns raised in this mail thread before. Let me know, if I have left something. Attached is a WIP patch

Re: [HACKERS] Memory Accounting v11

On 2015-07-07 16:49:58 +1200, David Rowley wrote: > I've been looking at this patch and trying to reproduce the reported > slowdown by using Tomas' function to try to exercise palloc() with minimal > overhead of other code: > > https://github.com/tvondra/palloc_bench That's not necessarily meanin

Re: [HACKERS] Freeze avoidance of very large table.

On Fri, Jul 3, 2015 at 1:55 PM, Sawada Masahiko wrote: > > On Fri, Jul 3, 2015 at 1:23 AM, Simon Riggs wrote: > > On 2 July 2015 at 16:30, Sawada Masahiko wrote: > > > >> > >> Also, the flags of each heap page header might be set PD_ALL_FROZEN, > >> as well as all-visible > > > > > > Is it possi

Re: [HACKERS] Foreign join pushdown vs EvalPlanQual

On 2015/07/06 9:42, Kouhei Kaigai wrote: Also, I don't want to stick on the assumption that relations involved in remote join are all managed by same foreign-server no longer. The following two ideas introduce possible enhancement of remote join feature that involved local relations; replicated t

Re: [HACKERS] RFC: replace pg_stat_activity.waiting with something more descriptive

Hello, At Tue, 7 Jul 2015 16:27:38 +0900, Fujii Masao wrote in > Each backend reports its event when trying to take a lock. But > the reported event is never reset until next event is reported. > Is this OK? This means that the wait_event column keeps showing > the *last* event while a backend

Re: [HACKERS] RFC: replace pg_stat_activity.waiting with something more descriptive

Please forgive me to resend this message for some too-sad misspellings. # "Waiting for heavy weight locks" is somewhat confusing to spell.. === Hello, At Tue, 7 Jul 2015 16:27:38 +0900, Fujii Masao wrote in > Each backend reports its event when trying to take a lock. But > the reported event

Re: [HACKERS] Providing catalog view to pg_hba.conf file - Patch submission

On 05/16/2015 06:00 AM, Haribabu Kommi wrote: >Regarding "next version"- are you referring to 9.6 and therefore we >should go ahead and bounce this to the next CF, or were you planning to >post a "next version" of the patch today? Yes, for 9.6 version. No new patch emerged that could be review

Re: [HACKERS] anole: assorted stability problems

On 2015-06-30 11:35:56 +0200, Andres Freund wrote: > On 2015-06-29 22:58:05 -0400, Tom Lane wrote: > > So personally, I would be inclined to put back the volatile qualifier, > > independently of any fooling around with _Asm_double_magic_xyzzy > > calls. > > I'm not sure. I think the reliance on an

Re: [HACKERS] Repeated pg_upgrade buildfarm failures on binturon

On 2015-07-06 20:00:43 -0400, Tom Lane wrote: > Andres Freund writes: > > Binturon has repeatedly failed with errors like: > > ERROR: could not open file "base/16400/32052": No such file or directory > > I agree that binturong seems to have something odd going on; but there are > a lot of other

Re: [HACKERS] 9.6 First Commitfest Begins

The first week of the July commitfest has passed. A lot of progress has been made, but there's still a lot to do. There are still 53 patches in Needs Review state. Please pick a patch, and review it. Any patch. Don't be afraid of reviewing a patch that someone else has signed up for. If you

Re: [HACKERS] Comfortably check BackendPID with psql

On 2015-07-05 14:11:38 +0200, Julien Rouhaud wrote: > Tiny for me too, but I sometimes had the need. > > I can't really see any good reason not to add a %p escape to psql's > PROMPT, so I'm attaching a simple patch to implement it. Unless someone > objects, I'll add it to the next commitfest. Pus

Re: [HACKERS] Freeze avoidance of very large table.

On Thu, Jul 2, 2015 at 9:00 PM, Sawada Masahiko wrote: > > > Thank you for bug report, and comments. > > Fixed version is attached, and source code comment is also updated. > Please review it. > I am looking into this patch and would like to share my findings with you: 1. @@ -2131,8 +2133,9 @@ h

Re: [HACKERS] replication slot restart_lsn initialization

On 2015-06-10 13:13:41 -0700, Gurjeet Singh wrote: > /* > + * Grab and save an LSN value to prevent WAL recycling past that point. > + */ > +void > +ReplicationSlotRegisterRestartLSN() > +{ > + ReplicationSlot *slot = MyReplicationSlot; > + > + Assert(slot != NULL); > + Assert(slot->da

Re: [HACKERS] Freeze avoidance of very large table.

On 6 July 2015 at 17:28, Simon Riggs wrote: I think we need something for pg_upgrade to rewrite existing VMs. Otherwise > a large read only database would suddenly require a massive revacuum after > upgrade, which seems bad. That can wait for now until we all agree this > patch is sound. > Since

Re: [HACKERS] patch : Allow toast tables to be moved to a different tablespace

On 2015-07-03 18:03:58 -0400, Tom Lane wrote: > I have just looked through this thread, and TBH I think we should reject > this patch altogether --- not RWF, but "no we don't want this". The > use-case remains hypothetical: no performance numbers showing a real-world > benefit have been exhibited

Re: [HACKERS] bugfix: incomplete implementation of errhidecontext

On 2015-07-03 06:20:14 +0200, Pavel Stehule wrote: > I would to use it for controlling (enabling, disabling) CONTEXT in RAISE > statement in plpgsql. I am thinking so one option for this purpose is > enough, and I would not to add other option to specify LOG, CLIENT. I don't think a plpgsql functi

Re: [HACKERS] Tab completion for CREATE SEQUENCE

On 2015-06-19 06:41:19 +, Brendan Jurd wrote: > I'm marking this "Waiting on Author". Once the problems have been > corrected, it should be ready for a committer. Vik, are you going to update the patch? -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes t

Re: [HACKERS] bugfix: incomplete implementation of errhidecontext

2015-07-07 14:13 GMT+02:00 Andres Freund : > On 2015-07-03 06:20:14 +0200, Pavel Stehule wrote: > > I would to use it for controlling (enabling, disabling) CONTEXT in RAISE > > statement in plpgsql. I am thinking so one option for this purpose is > > enough, and I would not to add other option to

Re: [HACKERS] FPW compression leaks information

On Thu, Apr 16, 2015 at 4:26 PM, Michael Paquier wrote: > On Wed, Apr 15, 2015 at 9:42 PM, Michael Paquier > wrote: >> On Wed, Apr 15, 2015 at 9:20 PM, Michael Paquier >> wrote: >>> On Wed, Apr 15, 2015 at 2:22 PM, Fujii Masao wrote: On Wed, Apr 15, 2015 at 11:55 AM, Michael Paquier wrote:

Re: [HACKERS] FPW compression leaks information

On Sat, May 30, 2015 at 4:58 PM, Michael Paquier wrote: > On Thu, Apr 16, 2015 at 4:26 PM, Michael Paquier > wrote: >> On Wed, Apr 15, 2015 at 9:42 PM, Michael Paquier >> wrote: >>> On Wed, Apr 15, 2015 at 9:20 PM, Michael Paquier >>> wrote: On Wed, Apr 15, 2015 at 2:22 PM, Fujii Masao wro

Re: [HACKERS] Comfortably check BackendPID with psql

Le 07/07/2015 13:41, Andres Freund a écrit : > On 2015-07-05 14:11:38 +0200, Julien Rouhaud wrote: >> Tiny for me too, but I sometimes had the need. >> >> I can't really see any good reason not to add a %p escape to psql's >> PROMPT, so I'm attaching a simple patch to implement it. Unless someone >

Re: [HACKERS] pg_receivexlog --create-slot-if-not-exists

On 2015-06-19 17:21:25 +0200, Cédric Villemain wrote: > > To make slot usage in pg_receivexlog easier, should we add > > --create-slot-if-not-exists? That'd mean you could run the same command > > the first and later invocation. > > +1 (with a shorter name please, if you can find one... ) How abo

Re: [HACKERS] PL/pgSQL, RAISE and error context

On 01/26/2015 05:14 PM, Tom Lane wrote: Pavel Stehule writes: 2015-01-26 14:02 GMT+01:00 Marko Tiikkaja : I am thinking, so solution /* if we are doing RAISE, don't report its location */ if (estate->err_text == raise_skip_msg) return; is too simple, and this part shou

Re: [HACKERS] FPW compression leaks information

* Fujii Masao (masao.fu...@gmail.com) wrote: > On Thu, Apr 16, 2015 at 4:26 PM, Michael Paquier > wrote: > > On Wed, Apr 15, 2015 at 9:42 PM, Michael Paquier > > wrote: > >> On Wed, Apr 15, 2015 at 9:20 PM, Michael Paquier > >> wrote: > >>> On Wed, Apr 15, 2015 at 2:22 PM, Fujii Masao wrote: > >

Re: [HACKERS] FPW compression leaks information

On 07/07/2015 04:15 PM, Stephen Frost wrote: * Fujii Masao (masao.fu...@gmail.com) wrote: On Thu, Apr 16, 2015 at 4:26 PM, Michael Paquier wrote: + the compression ratio of a full page image gives a hint of what is + the existing data of this page. Tables that contain sensitiv

Re: [HACKERS] Repeated pg_upgrade buildfarm failures on binturon

07.07.2015, 14:21, Andres Freund kirjoitti: > On 2015-07-06 20:00:43 -0400, Tom Lane wrote: >> Andres Freund writes: >>> Binturon has repeatedly failed with errors like: >>> ERROR: could not open file "base/16400/32052": No such file or directory >> >> I agree that binturong seems to have somethi

Re: [HACKERS] 9.5 alpha: some small comments on BRIN and btree_gin

> -Original Message- > From: Josh Berkus [mailto:j...@agliodbs.com] > Sent: Dienstag, 7. Juli 2015 02:04 > > On 07/06/2015 12:20 AM, Marc Mamin wrote: > >There seems to be no "fence" against useless BRIN indexes that > would allow a fallback on a table scan. > >But the time overh

Re: [HACKERS] FPW compression leaks information

* Heikki Linnakangas (hlinn...@iki.fi) wrote: > On 07/07/2015 04:15 PM, Stephen Frost wrote: > >* Fujii Masao (masao.fu...@gmail.com) wrote: > >>On Thu, Apr 16, 2015 at 4:26 PM, Michael Paquier > >> wrote: > >>>+ the compression ratio of a full page image gives a hint of what > >>>is > >>>

Re: [HACKERS] pg_trgm version 1.2

On Tue, Jun 30, 2015 at 11:28 PM, Jeff Janes wrote: > On Tue, Jun 30, 2015 at 2:46 AM, Alexander Korotkov < > a.korot...@postgrespro.ru> wrote: > >> On Sun, Jun 28, 2015 at 1:17 AM, Jeff Janes wrote: >> >>> This patch implements version 1.2 of contrib module pg_trgm. >>> >>> This supports the tr

Re: [HACKERS] creating extension including dependencies

On Mon, Jun 15, 2015 at 7:50 AM, Petr Jelinek wrote: > Hi, > > I am getting tired installing manually required extensions manually. I was > wondering if we might want to add option to CREATE SEQUENCE that would allow > automatic creation of the extensions required by the extension that is being >

Re: [HACKERS] auto_explain sample rate

On 05/07/2015 18:22, Julien Rouhaud wrote: > On 03/06/2015 15:00, Craig Ringer wrote: >> >> >> On 3 June 2015 at 20:04, Andres Freund > > wrote: >> >> On 2015-06-03 18:54:24 +0800, Craig Ringer wrote: >> > OK, here we go. >> >> Hm. Wouldn't random sampling be

Re: [HACKERS] creating extension including dependencies

On 2015-07-07 22:36:29 +0900, Fujii Masao wrote: > On Mon, Jun 15, 2015 at 7:50 AM, Petr Jelinek wrote: > > Hi, > > > > I am getting tired installing manually required extensions manually. I was > > wondering if we might want to add option to CREATE SEQUENCE that would allow > > automatic creation

Re: [HACKERS] [PATCH] Add missing \ddp psql command

> On Jul 7, 2015, at 3:53 AM, Fujii Masao wrote: > > On Tue, Jul 7, 2015 at 2:11 AM, David Christensen wrote: >> Quickie patch for spotted missing psql \ddp tab-completion. > > Thanks for the report and patch! > > I found that tab-completion was not supported in not only \ddp > but also other

Re: [HACKERS] Fix broken Install.bat when target directory contains a space

On 07/07/2015 02:56 AM, Tom Lane wrote: Michael Paquier writes: On Tue, Jul 7, 2015 at 4:19 AM, Heikki Linnakangas wrote: Ok, committed that way. Shoudn't this patch be backpatched? In the backbranches install.bat does not work correctly with paths containing spaces. I was about to ask t

Re: [HACKERS] replication slot restart_lsn initialization

On Tue, Jul 7, 2015 at 4:59 AM, Andres Freund wrote: > On 2015-06-10 13:13:41 -0700, Gurjeet Singh wrote: > > + /* > > + * Log an xid snapshot for logical replication. > It's not needed for > > + * physical slots as it is done in BGWri

Re: [HACKERS] replication slot restart_lsn initialization

On 2015-07-07 06:41:55 -0700, Gurjeet Singh wrote: > There seems to be a misplaced not operator ! in that if statement, as > well. That sucks :( The MacOS gcc binary is actually clang, and its output > is too noisy [1], which is probably why I might have missed warning if any. Which version of cl

Re: [HACKERS] PL/pgSQL, RAISE and error context

On Tue, Jul 7, 2015 at 8:13 AM, Heikki Linnakangas wrote: > On 01/26/2015 05:14 PM, Tom Lane wrote: >> >> Pavel Stehule writes: >>> >>> 2015-01-26 14:02 GMT+01:00 Marko Tiikkaja : >>> I am thinking, so solution >> >> >>> /* if we are doing RAISE, don't report its location */ >>> if (es

Re: [HACKERS] Redundant error messages in policy.c

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/06/2015 02:26 PM, Stephen Frost wrote: > Daniele, > > * Daniele Varrazzo (daniele.varra...@gmail.com) wrote: >> There are 5 different strings (one has a whitespace error), they >> could be 2. Patch attached. > > Fair point. I did try to addre

Re: [HACKERS] Performance improvement for joins where outer side is unique

Hi! On Sat, Mar 28, 2015 at 10:35 AM, David Rowley wrote: > On 25 March 2015 at 01:11, Kyotaro HORIGUCHI < > horiguchi.kyot...@lab.ntt.co.jp> wrote: > >> Hi, thanks for the new patch. >> >> I made an additional shrink from your last one. Do you have a >> look on the attached? >> >> > Thanks, for

Re: [HACKERS] FPW compression leaks information

On Tue, Jul 7, 2015 at 10:31 PM, Stephen Frost wrote: > * Heikki Linnakangas (hlinn...@iki.fi) wrote: >> On 07/07/2015 04:15 PM, Stephen Frost wrote: >> >* Fujii Masao (masao.fu...@gmail.com) wrote: >> >>On Thu, Apr 16, 2015 at 4:26 PM, Michael Paquier >> >> wrote: >> >>>+ the compression

Re: [HACKERS] PL/pgSQL, RAISE and error context

2015-07-07 15:56 GMT+02:00 Merlin Moncure : > On Tue, Jul 7, 2015 at 8:13 AM, Heikki Linnakangas > wrote: > > On 01/26/2015 05:14 PM, Tom Lane wrote: > >> > >> Pavel Stehule writes: > >>> > >>> 2015-01-26 14:02 GMT+01:00 Marko Tiikkaja : > >>> I am thinking, so solution > >> > >> > >>> /*

Re: [HACKERS] Spurious full-stop in message

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/06/2015 03:01 PM, Stephen Frost wrote: > * Daniele Varrazzo (daniele.varra...@gmail.com) wrote: >> postgresql/src/backend$ grep "must be superuser to change >> bypassrls attribute" commands/user.c | sed 's/ \+//' >> errmsg("must be superus

Re: [HACKERS] [PATCH] Add missing \ddp psql command

On Tue, Jul 7, 2015 at 10:44 PM, David Christensen wrote: > >> On Jul 7, 2015, at 3:53 AM, Fujii Masao wrote: >> >> On Tue, Jul 7, 2015 at 2:11 AM, David Christensen wrote: >>> Quickie patch for spotted missing psql \ddp tab-completion. >> >> Thanks for the report and patch! >> >> I found that t

Re: [HACKERS] Comfortably check BackendPID with psql

Andres Freund writes: > Pushed the patch. I only made a minor belt-and-suspenders type of > change, namely to check whether PQbackendPID() returns 0 and not print > that and replaced PID by pid in the docs and comments. I would s/pid/process ID/ in the docs. "PID" is not a particularly user-frie

Re: [HACKERS] Freeze avoidance of very large table.

> So I don't understand why you have two separate calls to visibilitymap_clear() > Surely the logic should be to clear both bits at the same time? Yes, you're right. all-frozen bit should be cleared at the same time as clearing all-visible bit. > 1. Both bits unset ~(VISIBILITYMAP_ALL_VISIBLE |

Re: [HACKERS] Comfortably check BackendPID with psql

On 2015-07-07 10:17:39 -0400, Tom Lane wrote: > I would s/pid/process ID/ in the docs. "PID" is not a particularly > user-friendly term, and it's even less so if you fail to upper-case it. We have both pid and PID in a bunch of places in the docs, and pid in the ones that seem more likely to be n

Re: [HACKERS] FPW compression leaks information

* Fujii Masao (masao.fu...@gmail.com) wrote: > On Tue, Jul 7, 2015 at 10:31 PM, Stephen Frost wrote: > > I'm not following. If we don't want the information to be available to > > everyone then we need to limit it, and right now the only way to do that > > is to restrict it to superuser because w

Re: [HACKERS] [PATCH] Add missing \ddp psql command

On Tue, Jul 7, 2015 at 11:08 PM, Fujii Masao wrote: > On Tue, Jul 7, 2015 at 10:44 PM, David Christensen wrote: >> >>> On Jul 7, 2015, at 3:53 AM, Fujii Masao wrote: >>> >>> On Tue, Jul 7, 2015 at 2:11 AM, David Christensen >>> wrote: Quickie patch for spotted missing psql \ddp tab-comple

Re: [HACKERS] PL/pgSQL, RAISE and error context

On 07/07/2015 04:56 PM, Merlin Moncure wrote: On Tue, Jul 7, 2015 at 8:13 AM, Heikki Linnakangas wrote: On 01/26/2015 05:14 PM, Tom Lane wrote: Pavel Stehule writes: 2015-01-26 14:02 GMT+01:00 Marko Tiikkaja : I am thinking, so solution /* if we are doing RAISE, don't report its

Re: [HACKERS] FPW compression leaks information

On 07/07/2015 04:31 PM, Stephen Frost wrote: * Heikki Linnakangas (hlinn...@iki.fi) wrote: On 07/07/2015 04:15 PM, Stephen Frost wrote: * Fujii Masao (masao.fu...@gmail.com) wrote: On Thu, Apr 16, 2015 at 4:26 PM, Michael Paquier wrote: + the compression ratio of a full page image gi

Re: [HACKERS] Repeated pg_upgrade buildfarm failures on binturon

Oskari Saarenmaa writes: > 07.07.2015, 14:21, Andres Freund kirjoitti: >> Those seem to indicate something going seriously wrong to me. > Binturong and Dingo run on the same host with a hourly cronjob to > trigger the builds. These failures are caused by concurrent test runs > on different branc

[HACKERS] [PATCH] correct the initdb.log path for pg_regress

When encountering an initdb failure in pg_regress, we were displaying the incorrect path to the log file; this commit fixes all 3 places this could occur. 0001-Output-the-correct-path-for-initdb.log-in-pg_regress.patch Description: Binary data -- David Christensen PostgreSQL Team Manager End

Re: [HACKERS] Repeated pg_upgrade buildfarm failures on binturon

I wrote: > Given the last sentence in the POSIX 2008 text, I think unconditionally > munging PWD as you're proposing is a bit risky. What I suggest is that > we add code to set PWD only if it's not set, which is most easily done > in test.sh itself, along the lines of > # Very old shells ma

Re: [HACKERS] Freeze avoidance of very large table.

On 7 July 2015 at 15:18, Sawada Masahiko wrote: > > I would also like to see the visibilitymap_test function exposed in SQL, > > so we can write code to examine the map contents for particular ctids. > > By doing that we can then write a formal test that shows the evolution > of tuples from inse

Re: [HACKERS] New functions

On Mon, Mar 23, 2015 at 12:46 PM, Michael Paquier wrote: > On Mon, Mar 23, 2015 at 1:48 AM, Воронин Дмитрий > wrote: >> >>> Please, attach new version of my patch to commitfest page. >> >> Michael, I found a way to attach patch. sorry to trouble. > > Cool. Thanks. I am seeing your patch entry he

[HACKERS] Missing latex-longtable value

I have discovered that psql \pset format does not display "latex-longtable" as a valid value, e.g.: test=> \pset format kjasdf \pset: allowed formats are unaligned, aligned, wrapped, html, asciidoc, latex, troff-ms With the attached patch, the latex-longtable value is properly di

Re: [HACKERS] FPW compression leaks information

* Heikki Linnakangas (hlinn...@iki.fi) wrote: > On 07/07/2015 04:31 PM, Stephen Frost wrote: > >The alternative is to have monitoring tools which are running as > >superuser, which, in my view at least, is far worse. > > Or don't enable fpw_compression for tables where the information > leak is a

Re: [HACKERS] Freeze avoidance of very large table.

On 2015-07-07 16:25:13 +0100, Simon Riggs wrote: > I don't think pg_freespacemap is the right place. I agree that pg_freespacemap sounds like an odd location. > I'd prefer to add that as a single function into core, so we can write > formal tests. With the advent of src/test/modules it's not rea

Re: [HACKERS] Missing latex-longtable value

Bruce Momjian writes: > I have discovered that psql \pset format does not display > "latex-longtable" as a valid value, e.g.: > test=> \pset format kjasdf > \pset: allowed formats are unaligned, aligned, wrapped, html, asciidoc, > latex, troff-ms > With the attached patch, the latex

Re: [HACKERS] Set of patch to address several Coverity issues

On 2015-07-07 16:17:47 +0900, Michael Paquier wrote: > 2) Potential pointer dereference in plperl.c, fixed by 0002 (sent > previously here => > CAB7nPqRBCWAXTLw0yBR=bk94cryxu8twvxgyyoxautw08ok...@mail.gmail.com). > This is related to a change done by transforms. In short, > plperl_call_perl_func@pl

Re: [HACKERS] Information of pg_stat_ssl visible to all users

On 7/2/15 3:29 PM, Magnus Hagander wrote: > On Thu, Jul 2, 2015 at 5:40 PM, Peter Eisentraut > wrote: > > On 6/10/15 2:17 AM, Magnus Hagander wrote: > > AIUI that one was just about the DN field, and not about the rest. If I > > understand you correctly, you ar

Re: [HACKERS] Information of pg_stat_ssl visible to all users

On Tue, Jul 7, 2015 at 6:03 PM, Peter Eisentraut wrote: > On 7/2/15 3:29 PM, Magnus Hagander wrote: > > On Thu, Jul 2, 2015 at 5:40 PM, Peter Eisentraut > > wrote: > > > > On 6/10/15 2:17 AM, Magnus Hagander wrote: > > > AIUI that one was just about the DN field,

Re: [HACKERS] Information of pg_stat_ssl visible to all users

On 2015-07-07 12:03:36 -0400, Peter Eisentraut wrote: > I think the DN is analogous to the remote user name, which we don't > expose for any of the other authentication methods. Huh? Datum pg_stat_get_activity(PG_FUNCTION_ARGS) { /* Values available to all callers */

Re: [HACKERS] PL/pgSQL, RAISE and error context

On Tue, Jul 7, 2015 at 9:04 AM, Pavel Stehule wrote: >> It doesn't have to if the behavior is guarded with a GUC. I just >> don't understand what all the fuss is about. The default behavior of >> logging that is well established by other languages (for example java) >> that manage error stack fo

Re: [HACKERS] Improving test coverage of extensions with pg_dump

On 03/07/2015 02:34 PM, Michael Paquier wrote: On Tue, Mar 3, 2015 at 2:40 PM, Michael Paquier wrote: Those patches are really simple, but then perhaps there are better or simpler ways than what is attached, so feel free to comment if you have any ideas. Attached are new patches somewhat base

Re: [HACKERS] FPW compression leaks information

On Wed, Jul 8, 2015 at 12:34 AM, Stephen Frost wrote: > * Heikki Linnakangas (hlinn...@iki.fi) wrote: >> On 07/07/2015 04:31 PM, Stephen Frost wrote: >> >The alternative is to have monitoring tools which are running as >> >superuser, which, in my view at least, is far worse. >> >> Or don't enable

Re: [HACKERS] replication slot restart_lsn initialization

On Tue, Jul 7, 2015 at 6:49 AM, Andres Freund wrote: > On 2015-07-07 06:41:55 -0700, Gurjeet Singh wrote: > > There seems to be a misplaced not operator ! in that if statement, as > > well. That sucks :( The MacOS gcc binary is actually clang, and its > output > > is too noisy [1], which is prob

Re: [HACKERS] Missing latex-longtable value

On Tue, Jul 7, 2015 at 11:48:13AM -0400, Tom Lane wrote: > Bruce Momjian writes: > > I have discovered that psql \pset format does not display > > "latex-longtable" as a valid value, e.g.: > > > test=> \pset format kjasdf > > \pset: allowed formats are unaligned, aligned, wrapped, html,

Re: [HACKERS] replication slot restart_lsn initialization

On 2015-07-07 09:42:54 -0700, Gurjeet Singh wrote: > On a side note, I see that the pg_create_*_replication_slot() functions do > not behave transactionally; that is, rolling back a transaction does not > undo the slot creation. It can't, because otherwise you couldn't run them on a standby. > Sh

Re: [HACKERS] 9.5 alpha: some small comments on BRIN and btree_gin

On 07/07/2015 06:28 AM, Marc Mamin wrote: > Sure, but on the other hand, they are so small and quick to build > that they seem to be a good alternative when other index types are too > costly, > even if theses indexes can't deal well with all data ranges passed as query > condition. > > Hence

Re: [HACKERS] Repeated pg_upgrade buildfarm failures on binturon

Oskari Saarenmaa writes: > I've restricted builds to one at a time on that host to work around this > issue for now. Also attached a patch to explicitly set PWD=$(CURDIR) in > the Makefile to make sure test.sh runs with the right directory. I've pushed a patch for this issue. Please revert your

Re: [HACKERS] Information of pg_stat_ssl visible to all users

Andres Freund writes: > On 2015-07-07 12:03:36 -0400, Peter Eisentraut wrote: >> I think the DN is analogous to the remote user name, which we don't >> expose for any of the other authentication methods. > Huh? Peter's exactly right: there is no other case where you can tell what some other conn

Re: [HACKERS] [PATCH] correct the initdb.log path for pg_regress

On Wed, Jul 8, 2015 at 12:23 AM, David Christensen wrote: > When encountering an initdb failure in pg_regress, we were displaying the > incorrect path to the log file; this commit fixes all 3 places this could > occur. Pushed. Thanks! Regards, -- Fujii Masao -- Sent via pgsql-hackers mail

Re: [HACKERS] Missing latex-longtable value

Bruce Momjian writes: > On Tue, Jul 7, 2015 at 11:48:13AM -0400, Tom Lane wrote: >> It's a bug. Back-patch as needed. > Doesn't that cause translation string differences that are worse than > the original bug, e.g.: > psql_error("\\pset: allowed formats are unaligned, aligned, wrapped, >

Re: [HACKERS] creating extension including dependencies

On Jul 7, 2015, at 6:41 AM, Andres Freund wrote: > At the minimum I'd like to see that CREATE EXTENSION foo; would install > install extension 'bar' if foo dependended on 'bar' if CASCADE is > specified. Right now we always error out saying that the dependency on > 'bar' is not fullfilled - not p

Re: [HACKERS] FPW compression leaks information

On Tue, Jul 7, 2015 at 12:34 PM, Stephen Frost wrote: > * Heikki Linnakangas (hlinn...@iki.fi) wrote: >> On 07/07/2015 04:31 PM, Stephen Frost wrote: >> >The alternative is to have monitoring tools which are running as >> >superuser, which, in my view at least, is far worse. >> >> Or don't enable

Re: [HACKERS] FPW compression leaks information

* Claudio Freire (klaussfre...@gmail.com) wrote: > On Tue, Jul 7, 2015 at 12:34 PM, Stephen Frost wrote: > > * Heikki Linnakangas (hlinn...@iki.fi) wrote: > >> On 07/07/2015 04:31 PM, Stephen Frost wrote: > >> >The alternative is to have monitoring tools which are running as > >> >superuser, which

Re: [HACKERS] FPW compression leaks information

On Tue, Jul 7, 2015 at 2:24 PM, Stephen Frost wrote: > * Claudio Freire (klaussfre...@gmail.com) wrote: >> On Tue, Jul 7, 2015 at 12:34 PM, Stephen Frost wrote: >> > * Heikki Linnakangas (hlinn...@iki.fi) wrote: >> >> On 07/07/2015 04:31 PM, Stephen Frost wrote: >> >> >The alternative is to have

Re: [HACKERS] FPW compression leaks information

* Fujii Masao (masao.fu...@gmail.com) wrote: > On Wed, Jul 8, 2015 at 12:34 AM, Stephen Frost wrote: > > I'd rather we hide it now, to allow FPW compression to be enabled for > > everyone, except those few environments where it ends up making things > > worse, and then provide the monitoring role

Re: [HACKERS] FPW compression leaks information

On 07/07/2015 07:31 PM, Fujii Masao wrote: Or another crazy idea is to append "random length" dummy data into compressed FPW. Which would make it really hard for an attacker to guess the information from WAL location. It makes the signal more noisy, but you can still mount the same attack if y

Re: [HACKERS] FPW compression leaks information

On Tue, Jul 7, 2015 at 2:29 PM, Stephen Frost wrote: >> Or another crazy idea is to append "random length" dummy data into >> compressed FPW. Which would make it really hard for an attacker to >> guess the information from WAL location. Even if this option is enabled, >> you can still have the per

Re: [HACKERS] Freeze avoidance of very large table.

On Wed, Jul 8, 2015 at 12:37 AM, Andres Freund wrote: > On 2015-07-07 16:25:13 +0100, Simon Riggs wrote: >> I don't think pg_freespacemap is the right place. > > I agree that pg_freespacemap sounds like an odd location. > >> I'd prefer to add that as a single function into core, so we can write >>

Re: [HACKERS] Repeated pg_upgrade buildfarm failures on binturon

07.07.2015, 19:50, Tom Lane kirjoitti: > Oskari Saarenmaa writes: >> I've restricted builds to one at a time on that host to work around this >> issue for now. Also attached a patch to explicitly set PWD=$(CURDIR) in >> the Makefile to make sure test.sh runs with the right directory. > > I've pu

Re: [HACKERS] More logging for autovacuum

On Sat, Jul 4, 2015 at 2:30 PM, Amit Kapila wrote: > On Thu, Jul 2, 2015 at 4:41 AM, Gurjeet Singh wrote: >> >> On Fri, Aug 17, 2007 at 3:14 PM, Alvaro Herrera >> wrote: >>> >>> Gregory Stark wrote: >>> > >>> > I'm having trouble following what's going on with autovacuum and I'm >>> > finding >>

Re: [HACKERS] Information of pg_stat_ssl visible to all users

On 07/07/2015 09:06 AM, Magnus Hagander wrote: > > To make it accessible to monitoring systems that don't run as superuser > (which should be most monitoring systems, but we have other cases making > that hard as has already been mentioned upthread). > > I'm having a hard time trying to figure o

Re: [HACKERS] More logging for autovacuum

On Sat, Jul 4, 2015 at 2:30 PM, Amit Kapila wrote: > On Thu, Jul 2, 2015 at 4:41 AM, Gurjeet Singh wrote: >> >> On Fri, Aug 17, 2007 at 3:14 PM, Alvaro Herrera >> wrote: >>> >>> Gregory Stark wrote: >>> > >>> > I'm having trouble following what's going on with autovacuum and I'm >>> > finding >>

Re: [HACKERS] Information of pg_stat_ssl visible to all users

* Josh Berkus (j...@agliodbs.com) wrote: > On 07/07/2015 09:06 AM, Magnus Hagander wrote: > > > > To make it accessible to monitoring systems that don't run as superuser > > (which should be most monitoring systems, but we have other cases making > > that hard as has already been mentioned upthrea

Re: [HACKERS] Information of pg_stat_ssl visible to all users

On 07/07/2015 11:29 AM, Stephen Frost wrote: > * Josh Berkus (j...@agliodbs.com) wrote: >> On 07/07/2015 09:06 AM, Magnus Hagander wrote: >>> >>> To make it accessible to monitoring systems that don't run as superuser >>> (which should be most monitoring systems, but we have other cases making >>>

Re: [HACKERS] Missing latex-longtable value

On Tue, Jul 7, 2015 at 01:05:09PM -0400, Tom Lane wrote: > Bruce Momjian writes: > > On Tue, Jul 7, 2015 at 11:48:13AM -0400, Tom Lane wrote: > >> It's a bug. Back-patch as needed. > > > Doesn't that cause translation string differences that are worse than > > the original bug, e.g.: > >

Re: [HACKERS] multivariate statistics / patch v7

Hi, On 07/07/2015 08:05 AM, Kyotaro HORIGUCHI wrote: Hi, Tomas. I'll kick the gas pedal. Thank you, it looks clearer. I have some comment for the brief look at this. This patchset is relatively large so I will comment on "per-notice" basis.. which means I'll send comment before examining the e

[HACKERS] Re: [HACKERS] GSoC 2015 proposal: Improve the performance of “ALTER TABLE .. SET LOGGED / UNLOGGED” statement

On Fri, Jul 3, 2015 at 9:29 AM, Ashutosh Bapat < ashutosh.ba...@enterprisedb.com> wrote: > > > On Fri, Jul 3, 2015 at 4:48 PM, Fabrízio de Royes Mello < fabriziome...@gmail.com> wrote: >> >> >> On Thu, Apr 2, 2015 at 3:24 PM, Robert Haas wrote: >> > >> > On Wed, Mar 25, 2015 at 9:46 PM, Fabrízio d

Re: [HACKERS] PL/pgSQL, RAISE and error context

2015-07-07 18:15 GMT+02:00 Merlin Moncure : > On Tue, Jul 7, 2015 at 9:04 AM, Pavel Stehule > wrote: > >> It doesn't have to if the behavior is guarded with a GUC. I just > >> don't understand what all the fuss is about. The default behavior of > >> logging that is well established by other lan

Re: [HACKERS] Improving log capture of TAP tests with IPC::Run

On 06/25/2015 07:14 AM, Michael Paquier wrote: After looking at the issues with the TAP test suite that hamster faced a couple of days ago, which is what has been discussed on this thread: http://www.postgresql.org/message-id/13002.1434307...@sss.pgh.pa.us I have developed a patch to improve log

  1   2   >