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

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

On Wed, Jul 8, 2015 at 1:27 AM, Fabrízio de Royes Mello < fabriziome...@gmail.com> wrote: > > 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: > >> > >>

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

On Tue, Jul 7, 2015 at 5:19 PM, Amit Kapila wrote: > > 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

Re: [HACKERS] More logging for autovacuum

On Tue, Jul 7, 2015 at 11:20 AM, Sawada Masahiko wrote: > On Sat, Jul 4, 2015 at 2:30 PM, Amit Kapila > wrote: > > On Thu, Jul 2, 2015 at 4:41 AM, Gurjeet Singh wrote: > >> log_min_messages acts as a single gate for everything headed for the > >> server logs; controls for per-background process

Re: [HACKERS] dblink: add polymorphic functions.

On Mon, Jul 6, 2015 at 11:52 PM, Joe Conway wrote: > That explains why the first example works while the second does not. > I'm not sure how hard it would be to fix that, but it appears that > that is where we should focus. Wouldn't it be fine if we drop some of the functions proposed without imp

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

On Tue, Jul 7, 2015 at 6:24 PM, Petr Jelinek wrote: > 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 u

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

On Wed, Jul 8, 2015 at 12:54 AM, Andres Freund wrote: > 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 ch

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

On Wed, Jul 8, 2015 at 1:32 AM, Heikki Linnakangas wrote: > Hmm. I think it'd be better to put the tables_fk extension into > src/test/modules, and the test case under src/test/tables_fk/t/. I'm > inclined to think of this as a test case for an extension that contains a > table, which includes tes

Re: [HACKERS] pg_dump quietly ignore missing tables - is it bug?

On Sat, May 23, 2015 at 1:41 AM, Pavel Stehule wrote: > > > 2015-05-22 18:34 GMT+02:00 Tom Lane : >> >> Oleksandr Shulgin writes: >> > I think this is a bit over-engineered (apart from the fact that >> > processSQLNamePattern is also used in two dozen of places in >> > psql/describe.c and all of

Re: [HACKERS] FPW compression leaks information

On Tue, Jul 7, 2015 at 11:34 PM, Stephen Frost wrote: > * 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

Re: [HACKERS] FPW compression leaks information

On Wed, Jul 8, 2015 at 2:40 AM, Heikki Linnakangas wrote: > 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

Re: [HACKERS] multivariate statistics / patch v7

Hello Horiguchi-san! On 07/07/2015 09:43 PM, Tomas Vondra wrote: -- histograms ALTER TABLE t ADD STATISTICS (histogram) on (a,b,c); ANALYZE t; EXPLAIN ANALYZE select * from t where a < 0.3 and b < 0.3 and c < 0.3; Seq Scan on t (cost=0.00..23870.00 rows=267033 width=24) (actual

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

On 8 July 2015 at 02:00, Alexander Korotkov wrote: > > Patch doesn't apply to current master. Could you, please, rebase it? > > Attached. Thanks. Regards David Rowley -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Supp

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

On Wed, Jul 8, 2015 at 3: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

Re: [HACKERS] Improving regression tests to check LOCK TABLE and table permissions

On Wed, Jul 8, 2015 at 6:39 AM, Joe Conway wrote: > Hash: SHA1 > Committed and pushed to master and 9.5 Thanks, Joe! -- Michael -- 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] Improving regression tests to check LOCK TABLE and table permissions

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/11/2015 07:52 PM, Michael Paquier wrote: > Hi all, > > As mentioned in this thread, it would be good to have regression > tests to test the interactions with permissions and LOCK TABLE: > http://www.postgresql.org/message-id/20150511195335.ge30

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

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

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

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

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

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

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

[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

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

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

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

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

  1   2   >