Re: [HACKERS] security labels on databases are bad for dump & restore

On Tue, Jul 28, 2015 at 03:36:13PM -0400, Robert Haas wrote: > On Tue, Jul 28, 2015 at 3:33 PM, Andres Freund wrote: > > Hm? Let me try again: If the admin does a ALTER DATABASE ... SET guc = > > ... *before* restoring a backup and the backup does contain a setting > > for the same guc, but with

Re: [HACKERS] more RLS oversights

On 07/03/2015 10:03 AM, Noah Misch wrote: > (7) Using an aggregate function in a policy predicate elicits an inapposite > error message due to use of EXPR_KIND_WHERE for parse analysis. Need a new > ParseExprKind. Test case: Patch attached. Comments? Joe diff --git a/src/backend/commands/poli

Re: [HACKERS] Remaining 'needs review' patchs in July commitfest

2015-07-28 21:51 GMT+02:00 Heikki Linnakangas : > 21 patches remain in Needs Review state, in the July commitfest. Some of > them have a reviewer signed up. I have highlighted some of them below that > worry me the most. What are we going to do about these? For each of them, > I'd like the authors

[HACKERS] call for contributor recommendations

Hackers, I am updating the list of PostgreSQL contributors. Please help me with this by nominating the following, and sending me *off-list* email: * people who did several really good reviews for 9.4/9.5 * people who did useful testing for 9.4/9.5 * people who did other really helpful things for

Re: [HACKERS] Autonomous Transaction is back

On 28 July 2015 15:31, Craig Ringer Wrote: >> 2.It should be allowed to deadlock with master transaction. >We >> need to work-out a solution to avoid deadlock. > >The deadlock case in autonomous tx's is a bit different. > >Assuming you don't intend to allow interleaving, where you can

Re: [HACKERS] WIP: Make timestamptz_out less slow.

On 2015-07-29 09:37:26 +1200, David Rowley wrote: > On 29 July 2015 at 03:25, Andres Freund wrote: > > > On 2015-07-29 03:10:41 +1200, David Rowley wrote: > > > Have you thought about what to do when HAVE_INT64_TIMESTAMP is not > > defined? > > > > I don't think it's actually important. The only

[HACKERS] Typo in comment in ATPrepChangePersistence

Hi, Attached fixes a typo: - * no permanent tables cannot reference unlogged ones. + * permanent tables cannot reference unlogged ones. Thanks, Amit diff --git a/src/backend/commands/tablecmds.c b/src/backend/commands/tablecmds.c index 1c7eded..b459b1e 100644 --- a/src/backend/commands/t

Re: [HACKERS] [DESIGN] ParallelAppend

On 2015-07-29 AM 11:02, Kouhei Kaigai wrote: >> >> ... >> synchronous Append path vs. parallel asynchronous Append with Funnel >> (below/above?) it. I guess the asynchronous version would always be >> cheaper. So, even if we end up with non-parallel sub-plans do we still add >> a Funnel to make App

Re: [HACKERS] A little RLS oversight?

On Mon, Jul 27, 2015 at 4:58 PM, Stephen Frost wrote: >> I would expect that if the current user has permission to bypass RLS, >> and they have set row_security to OFF, then it should be off for all >> tables that they have access to, regardless of how they access those >> tables (directly or thro

Re: [HACKERS] [DESIGN] ParallelAppend

> On 2015-07-28 PM 09:58, Kouhei Kaigai wrote: > >> > >> From my understanding of parallel seqscan patch, each worker's > >> PartialSeqScan asks for a block to scan using a shared parallel heap scan > >> descriptor that effectively keeps track of division of work among > >> PartialSeqScans in terms

Re: [HACKERS] [PATCH] Reload SSL certificates on SIGHUP

On Wed, Jul 29, 2015 at 10:24 AM, Tom Lane wrote: > Peter Eisentraut writes: >> I don't have a problem with rebuilding the SSL context on every reload >> cycle. We already do a lot of extra reloading every time, so a bit more >> shouldn't hurt. But I'm not so sure whether we should do that in t

Re: [HACKERS] [DESIGN] ParallelAppend

KaiGai-san, On 2015-07-28 PM 09:58, Kouhei Kaigai wrote: >> >> From my understanding of parallel seqscan patch, each worker's >> PartialSeqScan asks for a block to scan using a shared parallel heap scan >> descriptor that effectively keeps track of division of work among >> PartialSeqScans in ter

Re: [HACKERS] [PATCH] Reload SSL certificates on SIGHUP

On 07/23/2015 07:19 AM, Michael Paquier wrote: On Wed, Jul 22, 2015 at 9:52 AM, Andreas Karlsson wrote: On 07/02/2015 06:13 PM, Peter Eisentraut wrote: I think this would be a useful feature, and the implementation looks sound. But I don't like how the reload is organized. Reinitializing

Re: [HACKERS] more RLS oversights

On 07/03/2015 10:03 AM, Noah Misch wrote: > (6) AlterPolicy() calls InvokeObjectPostAlterHook(PolicyRelationId, ...), but > CreatePolicy() and DropPolicy() lack their respective hook invocations. Patch attached. Actually AlterPolicy() was also missing its hook -- the existing InvokeObjectPostAlter

Re: [HACKERS] Buildfarm TAP testing is useless as currently implemented

On 07/28/2015 08:58 PM, Tom Lane wrote: Andrew Dunstan writes: On 07/27/2015 10:06 AM, Tom Lane wrote: I think we should disable TAP testing in the buildfarm until there is some credible form of error reporting for it. The situation should now be substantially improved. Hm, I was just think

Re: [HACKERS] [PATCH] Reload SSL certificates on SIGHUP

Peter Eisentraut writes: > I don't have a problem with rebuilding the SSL context on every reload > cycle. We already do a lot of extra reloading every time, so a bit more > shouldn't hurt. But I'm not so sure whether we should do that in the > SIGHUP handler. I don't know how we got into the s

Re: [HACKERS] Planner debug views

Qingqing Zhou writes: > There are still something bothering me: EXPLAIN is a mixed output with > original text, rows for RelOptInfo, rows for Paths and possible others > added later. So we have to use 't as text' to receive each line. To do the > insertion, we have to further decompose each text l

Re: [HACKERS] Buildfarm TAP testing is useless as currently implemented

Andrew Dunstan writes: >> On 07/27/2015 10:06 AM, Tom Lane wrote: >>> I think we should disable TAP testing in the buildfarm until there is >>> some credible form of error reporting for it. > The situation should now be substantially improved. Hm, I was just thinking we weren't there yet, becaus

Re: [HACKERS] Buildfarm TAP testing is useless as currently implemented

On 07/27/2015 12:15 PM, Andrew Dunstan wrote: On 07/27/2015 10:06 AM, Tom Lane wrote: I challenge anybody to figure out what happened here: http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=hornet&dt=2015-07-27%2010%3A25%3A17 or here: http://buildfarm.postgresql.org/cgi-bin/show_log.pl

Re: [HACKERS] [PATCH] Reload SSL certificates on SIGHUP

On 7/21/15 8:52 PM, Andreas Karlsson wrote: > It is not enough to just add a hook to the GUCs since I would guess most > users would expect the certificate to be reloaded if just the file has > been replaced and no GUC was changed. To support this we would need to > also check the mtimes of the SSL

Re: [HACKERS] Planner debug views

On Tue, Jul 28, 2015 at 2:43 PM, Tom Lane wrote: > > You can do something like that in plpgsql, for example > > declare t text; > > for t in EXPLAIN SELECT ... > loop >insert into whatever values(t); > end loop; > I see - this is cool. There are still something bothering

Re: [HACKERS] pg_basebackup and replication slots

On 7/22/15 12:43 AM, Michael Paquier wrote: > OK, thanks for the updated versions. Those ones look good to me. Committed, thanks. > Now, do we plan to do something about the creation of a slot. I > imagine that it would be useful if we could have --create-slot to > create a slot when beginning a

Re: [HACKERS] TODO: replica information functions

On 28-07-2015 15:35, Josh Berkus wrote: pg_standby_is_streaming() returns true if the standby is configured for streaming and is currently connected with the master. returns false if the connection to the master is broken, of if there is no primary_conninfo +1.

Re: [HACKERS] more RLS oversights

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/28/2015 11:50 AM, Stephen Frost wrote: > * Joe Conway (joe.con...@crunchydata.com) wrote: >> On 07/03/2015 10:03 AM, Noah Misch wrote: >>> (4) When DefineQueryRewrite() is about to convert a table to a >>> view, it checks the table for features u

Re: [HACKERS] Remaining 'needs review' patchs in July commitfest

Michael Paquier writes: > On Wed, Jul 29, 2015 at 5:22 AM, Heikki Linnakangas wrote: >> On 07/28/2015 11:01 PM, Alvaro Herrera wrote: >>> Do we want to have this in src/test/modules or src/bin/pg_dump/t? >> Are we testing pg_dump here, or are we testing extensions? If the >> former, src/bin/pg_d

Re: [HACKERS] Failing assertions in indxpath.c, placeholder.c and brin_minmax.c

Alvaro Herrera writes: > Tom Lane wrote: >> Bottom line is that somebody failed to consider the possibility of a >> null comparison value reaching the BRIN index lookup machinery. >> The code stanza that's failing supposes that only IS NULL or IS NOT NULL >> tests could have SK_ISNULL set, but tha

Re: [HACKERS] more RLS oversights

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/27/2015 05:34 PM, Joe Conway wrote: > On 07/27/2015 01:13 PM, Alvaro Herrera wrote: >> Hmm, these are not ACL objects, so conceptually it seems cleaner >> to use a different symbol for this. I think the catalog state >> and the error messages wo

Re: [HACKERS] Remaining 'needs review' patchs in July commitfest

On Wed, Jul 29, 2015 at 5:22 AM, Heikki Linnakangas wrote: > On 07/28/2015 11:01 PM, Alvaro Herrera wrote: Improving test coverage of extensions with pg_dump >>> >>> >>> Do we want to have this in src/test/modules or src/bin/pg_dump/t? >> >> >> Are we testing pg_dump here, or are we testing ex

Re: [HACKERS] Re: Removing SSL renegotiation (Was: Should we back-patch SSL renegotiation fixes?)

On Wed, Jul 29, 2015 at 2:00 AM, Andres Freund wrote: > On 2015-07-28 18:59:02 +0200, Andres Freund wrote: >> Attached are: >> >> a) a slightly evolved version of Michael's patch disabling renegotiation >>by default that I'm planning to apply to 9.4 - 9.0 >> >> b) a patch removing renegotiatio

Re: [HACKERS] Remaining 'needs review' patchs in July commitfest

Hi, On 07/28/2015 09:51 PM, Heikki Linnakangas wrote: multivariate statistics This has been a long discussion. Are we getting close to a committable state? Certainly not - the discussion may seem long, but it only deals with some aspects of the patch so far. There was very little discussi

Re: [HACKERS] Buildfarm failure from overly noisy warning message

Kevin Grittner writes: > Tom Lane wrote: >> Kevin Grittner writes: >>> I think a LOG entry when an autovacuum process is actually canceled >>> has value just in case it is happening on a particular table so >>> frequently that the table starts to bloat. I see no reason to log >>> anything if th

Re: [HACKERS] Planner debug views

Qingqing Zhou writes: > Not sure if I got it: so EXPLAIN will return tuples to libpq client. But > how do we store these returned tuples (RelOptInfo, Path etc) so we can > throw queries against them later? > Something like this: > INSERT INTO my_space SELECT (EXPLAIN SELECT ...); -- won't get par

Re: [HACKERS] WIP: Make timestamptz_out less slow.

On 29 July 2015 at 03:25, Andres Freund wrote: > On 2015-07-29 03:10:41 +1200, David Rowley wrote: > > Have you thought about what to do when HAVE_INT64_TIMESTAMP is not > defined? > > I don't think it's actually important. The only difference vs float > timestamps is that in the latter case we s

Re: [HACKERS] Planner debug views

On Tue, Jul 28, 2015 at 12:08 PM, Alvaro Herrera wrote: > I would have a tuplestore, and the planner code would push tuples to it. > After the planning is done, EXPLAIN can read and return tuples from the > store to the user. > Not sure if I got it: so EXPLAIN will return tuples to libpq client.

Re: [HACKERS] Remaining 'needs review' patchs in July commitfest

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/28/2015 01:22 PM, Heikki Linnakangas wrote: dblink: add polymorphic result functions >>> >>> Seems pretty ugly to me to add a dummy argument to functions, >>> just so that you can specify the result type. The problem it's >>> trying to solv

Re: [HACKERS] Remaining 'needs review' patchs in July commitfest

Andres Freund writes: > On 2015-07-28 22:51:55 +0300, Heikki Linnakangas wrote: >>> checkpoint continuous flushing >> This does a big memory allocation at checkpoint, which Tom vehemently >> objects to. > Uh. Didn't he just object to failing in that case? Right. If it can fall back to "stupid"

Re: [HACKERS] Remaining 'needs review' patchs in July commitfest

On 07/28/2015 11:30 PM, Simon Riggs wrote: I've added my name as committer to a few things, but won't be able to work on them until at least next week when I've finished 9.5 stuff. Happy to step back if anyone else wants to claim those. Thanks, every little helps! - Heikki -- Sent via pgsql

Re: [HACKERS] Remaining 'needs review' patchs in July commitfest

On 28 July 2015 at 20:51, Heikki Linnakangas wrote: > > multivariate statistics >> > > This has been a long discussion. Are we getting close to a committable > state? > This is important, but big. > COPY RAW >> > > No consensus on whether to add this to the server's COPY command, or as a > n

Re: [HACKERS] A little RLS oversight?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/28/2015 11:17 AM, Joe Conway wrote: > I'm going to commit the attached in the next few hours unless > someone has serious objections. We can always revisit the specific > behavior of those messages separately if we change our minds... Pushed to

Re: [HACKERS] Remaining 'needs review' patchs in July commitfest

On 07/28/2015 11:01 PM, Alvaro Herrera wrote: Heikki Linnakangas wrote: pgbench - allow backslash-continuations in custom scripts Everyone wants the feature, using multi-line SELECTs in pgbench scripts, but we don't seem to be reaching a consensus on how it should work. I think we'll need to i

Re: [HACKERS] Re: Removing SSL renegotiation (Was: Should we back-patch SSL renegotiation fixes?)

Andres Freund wrote: > On 2015-07-28 18:59:02 +0200, Andres Freund wrote: > > Unless somebody protests soon I'm going to push something like that > > after having dinner. > > Done. Yay! -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA

Re: [HACKERS] Re: Removing SSL renegotiation (Was: Should we back-patch SSL renegotiation fixes?)

On 2015-07-28 18:59:02 +0200, Andres Freund wrote: > Unless somebody protests soon I'm going to push something like that > after having dinner. Done. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pg

Re: [HACKERS] Planner debug views

Alvaro Herrera writes: > Qingqing Zhou wrote: >> The file name is not random, it is fixed so we can create foreign table >> once and use it afterwards - I actually want to push them into >> system_views.sql. > Got that. That seems fragile and not very convenient; I don't think > forcing retries

Re: [HACKERS] Remaining 'needs review' patchs in July commitfest

Heikki Linnakangas wrote: > 21 patches remain in Needs Review state, in the July commitfest. Some of > them have a reviewer signed up. I have highlighted some of them below that > worry me the most. What are we going to do about these? For each of them, > I'd like the authors to have some idea on w

Re: [HACKERS] Remaining 'needs review' patchs in July commitfest

On 2015-07-28 22:51:55 +0300, Heikki Linnakangas wrote: > >checkpoint continuous flushing > > This does a big memory allocation at checkpoint, which Tom vehemently > objects to. Uh. Didn't he just object to failing in that case? IIRC he even indicated tentative assent, a year or so back, with my

Re: [HACKERS] Remaining 'needs review' patchs in July commitfest

On 07/28/2015 12:51 PM, Heikki Linnakangas wrote: > Everyone wants the feature, using multi-line SELECTs in pgbench scripts, > but we don't seem to be reaching a consensus on how it should work. I > think we'll need to integrate the lexer, but it would be nice to still > support multi-statements as

[HACKERS] Remaining 'needs review' patchs in July commitfest

21 patches remain in Needs Review state, in the July commitfest. Some of them have a reviewer signed up. I have highlighted some of them below that worry me the most. What are we going to do about these? For each of them, I'd like the authors to have some idea on what they need to do to get the

Re: [HACKERS] security labels on databases are bad for dump & restore

On Tue, Jul 28, 2015 at 3:33 PM, Andres Freund wrote: > On 2015-07-28 15:27:51 -0400, Robert Haas wrote: >> On Tue, Jul 28, 2015 at 3:16 PM, Andres Freund wrote: >> > On 2015-07-28 15:14:11 -0400, Robert Haas wrote: >> >> On Tue, Jul 28, 2015 at 3:10 PM, Andres Freund wrote: >> >> > DBA creates

Re: [HACKERS] security labels on databases are bad for dump & restore

On 2015-07-28 15:27:51 -0400, Robert Haas wrote: > On Tue, Jul 28, 2015 at 3:16 PM, Andres Freund wrote: > > On 2015-07-28 15:14:11 -0400, Robert Haas wrote: > >> On Tue, Jul 28, 2015 at 3:10 PM, Andres Freund wrote: > >> > DBA creates a database and sets some properties (security labels, gucs, >

Re: [HACKERS] TODO: replica information functions

> On 28 Jul 2015, at 21:35, Josh Berkus wrote: > > Hackers, > > Since merging recovery.conf with postgresql.conf is apparently off the > table indefinitely, we could really use some additional information > functions which work on the replica. Here's my list of what I need for > failover autom

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

On 07/27/2015 01:20 PM, Ildus Kurbangaliev wrote: Hello. In the attached patch I've made a refactoring for tranches. The prefix for them was extended, and I've did a split of LWLockAssign to two functions (one with tranche and second for user defined LWLocks). This needs some work in order to

Re: [HACKERS] security labels on databases are bad for dump & restore

On Tue, Jul 28, 2015 at 3:16 PM, Andres Freund wrote: > On 2015-07-28 15:14:11 -0400, Robert Haas wrote: >> On Tue, Jul 28, 2015 at 3:10 PM, Andres Freund wrote: >> > DBA creates a database and sets some properties (security labels, gucs, >> > acls) on it. Then goes on to restore a backup. Unfort

Re: [HACKERS] security labels on databases are bad for dump & restore

Josh Berkus wrote: > On 07/28/2015 11:58 AM, Robert Haas wrote: > > I'd be strongly in favour of teaching GRANT, SECURITY LABEL, COMMENT > >> ON DATABASE, etc to recognise CURRENT_DATABASE as a keyword. Then > >> dumping them in pg_dump --create, and in pg_dump -Fc . > >> > >> In practice I see zer

Re: [HACKERS] security labels on databases are bad for dump & restore

* Andres Freund (and...@anarazel.de) wrote: > On 2015-07-28 15:14:11 -0400, Robert Haas wrote: > > On Tue, Jul 28, 2015 at 3:10 PM, Andres Freund wrote: > > > DBA creates a database and sets some properties (security labels, gucs, > > > acls) on it. Then goes on to restore a backup. Unfortunately

Re: [HACKERS] security labels on databases are bad for dump & restore

On 07/28/2015 11:58 AM, Robert Haas wrote: > I'd be strongly in favour of teaching GRANT, SECURITY LABEL, COMMENT >> ON DATABASE, etc to recognise CURRENT_DATABASE as a keyword. Then >> dumping them in pg_dump --create, and in pg_dump -Fc . >> >> In practice I see zero real use of pg_dumpall withou

Re: [HACKERS] security labels on databases are bad for dump & restore

On 2015-07-28 15:14:11 -0400, Robert Haas wrote: > On Tue, Jul 28, 2015 at 3:10 PM, Andres Freund wrote: > > DBA creates a database and sets some properties (security labels, gucs, > > acls) on it. Then goes on to restore a backup. Unfortunately that backup > > might, or might not, overwrite the p

Re: [HACKERS] security labels on databases are bad for dump & restore

On Tue, Jul 28, 2015 at 3:10 PM, Andres Freund wrote: > On 2015-07-28 15:05:01 -0400, Robert Haas wrote: >> On Tue, Jul 28, 2015 at 3:03 PM, Andres Freund wrote: >> > On 2015-07-28 14:58:26 -0400, Robert Haas wrote: >> >> Yes, I think we should make restoring the database's properties the >> >> j

Re: [HACKERS] security labels on databases are bad for dump & restore

On 2015-07-28 15:05:01 -0400, Robert Haas wrote: > On Tue, Jul 28, 2015 at 3:03 PM, Andres Freund wrote: > > On 2015-07-28 14:58:26 -0400, Robert Haas wrote: > >> Yes, I think we should make restoring the database's properties the > >> job of pg_dump and remove it completely from pg_dumpall, unles

Re: [HACKERS] Planner debug views

Qingqing Zhou wrote: > On Mon, Jul 27, 2015 at 8:20 PM, Alvaro Herrera > wrote: > > > > I think this is a pretty neat idea, but I'm not sure this user interface > > is a good one. Why not have a new option for EXPLAIN, so you would call > > "EXPLAIN (planner_stuff=on)" and it returns this as a re

Re: [HACKERS] security labels on databases are bad for dump & restore

On Tue, Jul 28, 2015 at 3:03 PM, Andres Freund wrote: > On 2015-07-28 14:58:26 -0400, Robert Haas wrote: >> Yes, I think we should make restoring the database's properties the >> job of pg_dump and remove it completely from pg_dumpall, unless we can >> find a case where that's really going to brea

Re: [HACKERS] security labels on databases are bad for dump & restore

On 2015-07-28 14:58:26 -0400, Robert Haas wrote: > Yes, I think we should make restoring the database's properties the > job of pg_dump and remove it completely from pg_dumpall, unless we can > find a case where that's really going to break things. CREATE DATABASE blarg; SECURITY LABEL ON blarg IS

Re: [HACKERS] security labels on databases are bad for dump & restore

* Robert Haas (robertmh...@gmail.com) wrote: > On Sun, Jul 26, 2015 at 11:43 PM, Craig Ringer wrote: > > On 20 July 2015 at 01:18, Noah Misch wrote: > >> On Wed, Jul 15, 2015 at 11:08:53AM +0200, Andres Freund wrote: > >>> On 2015-07-15 12:04:40 +0300, Alvaro Herrera wrote: > >>> > Andres Freund

Re: [HACKERS] security labels on databases are bad for dump & restore

On Sun, Jul 26, 2015 at 11:43 PM, Craig Ringer wrote: > On 20 July 2015 at 01:18, Noah Misch wrote: >> On Wed, Jul 15, 2015 at 11:08:53AM +0200, Andres Freund wrote: >>> On 2015-07-15 12:04:40 +0300, Alvaro Herrera wrote: >>> > Andres Freund wrote: >>> > > One thing worth mentioning is that argua

Re: [HACKERS] group locking: incomplete patch, just for discussion

On Wed, Nov 5, 2014 at 9:26 PM, Robert Haas wrote: > On Sun, Nov 2, 2014 at 7:31 AM, Simon Riggs wrote: >> The procgloballist stuff should be the subject of a separate patch >> which I agree with. > > Yes, I think that's probably a net improvement in robustness quite > apart from what we decide t

Re: [HACKERS] Sequence Access Method WIP

On 2015-07-28 20:11, Heikki Linnakangas wrote: Petr, is this enough feedback on this patch for this commitfest, or are there some other issues you want to discuss before I mark this as returned? You can mark it as returned, I didn't have much time to actually do much useful work on this in t

Re: [HACKERS] more RLS oversights

* Joe Conway (joe.con...@crunchydata.com) wrote: > On 07/03/2015 10:03 AM, Noah Misch wrote: > > (4) When DefineQueryRewrite() is about to convert a table to a view, it > > checks > > the table for features unavailable to views. For example, it rejects tables > > having triggers. It omits to rej

Re: [HACKERS] Failing assertions in indxpath.c, placeholder.c and brin_minmax.c

Tom Lane wrote: > Bottom line is that somebody failed to consider the possibility of a > null comparison value reaching the BRIN index lookup machinery. > The code stanza that's failing supposes that only IS NULL or IS NOT NULL > tests could have SK_ISNULL set, but that's just wrong. I think the

Re: [HACKERS] TODO: replica information functions

On 2015-07-28 11:35:52 -0700, Josh Berkus wrote: > Since merging recovery.conf with postgresql.conf is apparently off the > table indefinitely Off the table as in "somebody needs to actually work on it instead of just talking about it". -- Sent via pgsql-hackers mailing list (pgsql-hackers@pos

[HACKERS] TODO: replica information functions

Hackers, Since merging recovery.conf with postgresql.conf is apparently off the table indefinitely, we could really use some additional information functions which work on the replica. Here's my list of what I need for failover automation: pg_standby_is_streaming() returns true if the st

Re: [HACKERS] A little RLS oversight?

* Dean Rasheed (dean.a.rash...@gmail.com) wrote: > On 28 July 2015 at 03:19, Joe Conway wrote: > > On 07/27/2015 03:05 PM, Stephen Frost wrote: > >> AFK at the moment, but my thinking was that we should avoid having > >> the error message change based on what a GUC is set to. I agree > >> that the

Re: [HACKERS] Planner debug views

On Mon, Jul 27, 2015 at 8:20 PM, Alvaro Herrera wrote: > > I think this is a pretty neat idea, but I'm not sure this user interface > is a good one. Why not have a new option for EXPLAIN, so you would call > "EXPLAIN (planner_stuff=on)" and it returns this as a resultset? Thank you for the feedb

Re: [HACKERS] Shouldn't we document "don't use a mountpoint as $PGDATA"?

On 07/28/2015 02:01 PM, Tom Lane wrote: I had a discussion with some folks at Red Hat about this: https://bugzilla.redhat.com/show_bug.cgi?id=1247477 I had the idea that we had documented somewhere that the data directory should not be a filesystem mount point, but I sure can't find it now. Any

Re: [HACKERS] A little RLS oversight?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/28/2015 12:32 AM, Dean Rasheed wrote: >> On 07/27/2015 03:05 PM, Stephen Frost wrote: >>> AFK at the moment, but my thinking was that we should avoid >>> having the error message change based on what a GUC is set to. >>> I agree that there should

Re: [HACKERS] Shouldn't we document "don't use a mountpoint as $PGDATA"?

On 07/28/2015 11:01 AM, Tom Lane wrote: > I had a discussion with some folks at Red Hat about this: > https://bugzilla.redhat.com/show_bug.cgi?id=1247477 > > I had the idea that we had documented somewhere that the data directory > should not be a filesystem mount point, but I sure can't find it n

Re: [HACKERS] Sequence Access Method WIP

So, we have this patch in the commitfest again. Let's see where we are, and try to find a consensus on what needs to be done before this can be committed. On 06/17/2015 06:51 PM, Petr Jelinek wrote: On 2015-06-15 11:32, Vik Fearing wrote: I've been looking at these patches a bit and here are

[HACKERS] Shouldn't we document "don't use a mountpoint as $PGDATA"?

I had a discussion with some folks at Red Hat about this: https://bugzilla.redhat.com/show_bug.cgi?id=1247477 I had the idea that we had documented somewhere that the data directory should not be a filesystem mount point, but I sure can't find it now. Any objections to adding some text about this

Re: [HACKERS] Sharing aggregate states between different aggregate functions

Heikki Linnakangas writes: > On 07/28/2015 07:18 PM, Tom Lane wrote: >> Heikki Linnakangas writes: >>> BTW, we're also not checking if the transition or final functions are >>> volatile. But that was the same before this patch too. >> Up to now it hasn't mattered. > Yes, it has. We combine iden

Re: [HACKERS] Sharing aggregate states between different aggregate functions

On 07/28/2015 07:18 PM, Tom Lane wrote: Heikki Linnakangas writes: On 07/28/2015 04:14 AM, David Rowley wrote: Yeah, a volatile input function seems highly unlikely, but who knows. We have a project policy against volatile I/O functions. One reason why is that it would break the assumption t

Re: [HACKERS] Re: Removing SSL renegotiation (Was: Should we back-patch SSL renegotiation fixes?)

On 2015-07-28 18:59:02 +0200, Andres Freund wrote: > Attached are: > > a) a slightly evolved version of Michael's patch disabling renegotiation >by default that I'm planning to apply to 9.4 - 9.0 > > b) a patch removing renegotiation entirely from master and 9.5 > > Unless somebody protests

Re: [HACKERS] Re: Removing SSL renegotiation (Was: Should we back-patch SSL renegotiation fixes?)

Hi, Attached are: a) a slightly evolved version of Michael's patch disabling renegotiation by default that I'm planning to apply to 9.4 - 9.0 b) a patch removing renegotiation entirely from master and 9.5 Unless somebody protests soon I'm going to push something like that after having dinner

Re: [HACKERS] proposal: multiple psql option -c

On 07/28/2015 11:52 AM, Pavel Stehule wrote: 2015-07-28 15:16 GMT+02:00 Andrew Dunstan >: On 07/28/2015 12:08 AM, Pavel Stehule wrote: 2015-07-28 5:24 GMT+02:00 Pavel Stehule mailto:pavel.steh...@gmail.com>

Re: [HACKERS] Sharing aggregate states between different aggregate functions

Heikki Linnakangas writes: > On 07/28/2015 04:14 AM, David Rowley wrote: >> I'd not thought of an input function being volatile before, but I guess >> it's possible, which makes me a bit scared that we could be treading on >> ground we shouldn't be. I know it's more of an output function thing tha

Re: [HACKERS] more RLS oversights

On 07/03/2015 10:03 AM, Noah Misch wrote: > (4) When DefineQueryRewrite() is about to convert a table to a view, it checks > the table for features unavailable to views. For example, it rejects tables > having triggers. It omits to reject tables having relrowsecurity or a > pg_policy record. Tes

Re: [HACKERS] LWLock deadlock and gdb advice

On Tue, Jul 28, 2015 at 7:06 AM, Andres Freund wrote: > Hi, > > On 2015-07-19 11:49:14 -0700, Jeff Janes wrote: > > After applying this patch to commit fdf28853ae6a397497b79f, it has > survived > > testing long enough to convince that this fixes the problem. > > What was the actual workload break

Re: [HACKERS] proposal: multiple psql option -c

2015-07-28 15:16 GMT+02:00 Andrew Dunstan : > > On 07/28/2015 12:08 AM, Pavel Stehule wrote: > >> >> >> 2015-07-28 5:24 GMT+02:00 Pavel Stehule > pavel.steh...@gmail.com>>: >> >> >> >> 2015-07-27 21:57 GMT+02:00 Andrew Dunstan > >: >> >> >> On 07/27/2015

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

On 07/28/2015 05:49 PM, Andrew Dunstan wrote: On 07/09/2015 06:29 AM, Heikki Linnakangas wrote: On 07/09/2015 04:50 AM, Michael Paquier wrote: Except that this patch looks good to me. Thanks for the black magic on stdout/stderr handling. Thanks, fixed the parenthesis and committed. The miss

Re: [HACKERS] Sharing aggregate states between different aggregate functions

On 07/28/2015 04:14 AM, David Rowley wrote: On 27 July 2015 at 20:11, Heikki Linnakangas wrote: On 07/27/2015 08:34 AM, David Rowley wrote: In this function I also wasn't quite sure if it was with comparing both non-NULL INITCOND's here. I believe my code comments may slightly contradict wha

Re: [HACKERS] WIP: Make timestamptz_out less slow.

On 2015-07-29 03:10:41 +1200, David Rowley wrote: > timestamp_out() = 2015-07-29 02:24:33.34 in 3.506000 > timestamp_out_old() = 2015-07-29 02:24:33.034 in 64.518000 > timestamp_out_af() = 2015-07-29 02:24:33.034 in 2.981000 > > timestamp_out_old is master's version, the timestamp_out_af() is yours

Re: [HACKERS] WIP: Make timestamptz_out less slow.

On 28 July 2015 at 19:10, Andres Freund wrote: > On 2015-07-28 10:59:15 +1200, David Rowley wrote: > > It won't be quite as fast as what you've written, but I think it will be > > much neater and more likely to be used in other places if we invent a > > function like pg_ltoa() which returns a poi

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

On 07/09/2015 06:29 AM, Heikki Linnakangas wrote: On 07/09/2015 04:50 AM, Michael Paquier wrote: Except that this patch looks good to me. Thanks for the black magic on stdout/stderr handling. Thanks, fixed the parenthesis and committed. The missing --debug is a separate issue. What wa

Re: [HACKERS] pgbench stats per script & other stuff

v6 is just a rebase after a bug fix by Andres Freund. Also a small question: The patch currently displays pgbench scripts starting numbering at 0. Probably a little too geek... should start at 1? -- Fabien.diff --git a/doc/src/sgml/ref/pgbench.sgml b/doc/src/sgml/ref/pgbench.sgml index 2517a3

Re: [HACKERS] LWLock deadlock and gdb advice

Hi, On 2015-07-19 11:49:14 -0700, Jeff Janes wrote: > After applying this patch to commit fdf28853ae6a397497b79f, it has survived > testing long enough to convince that this fixes the problem. What was the actual workload breaking with the bug? I ran a small variety and I couldn't reproduce it ye

Re: [HACKERS] Planner debug views

Qingqing Zhou wrote: > Attached is a draft patch implementing the idea. To play with it, you > shall create the follow two foreign tables: > CREATE EXTENSION file_fdw; > CREATE SERVER pglog FOREIGN DATA WRAPPER file_fdw; > create foreign table pg_planner_rels(rel text, content text)server > pglog

Re: [HACKERS] [DESIGN] ParallelAppend

> On 27 July 2015 at 21:09, Kyotaro HORIGUCHI > wrote: > > > Hello, can I ask some questions? > > I suppose we can take this as the analog of ParalleSeqScan. I > can see not so distinction between Append(ParalleSeqScan) and > ParallelAppend(SeqScan). What difference is

Re: [HACKERS] MultiXact member wraparound protections are now enabled

On Sat, Jul 25, 2015 at 4:11 AM, Simon Riggs wrote: > On 22 July 2015 at 21:45, Robert Haas wrote: >> But it seemed to me that this could be rather confusing. I thought it >> would be better to be explicit about whether the protections are >> enabled in all cases. That way, (1) if you see the m

Re: [HACKERS] proposal: multiple psql option -c

On 07/28/2015 12:08 AM, Pavel Stehule wrote: 2015-07-28 5:24 GMT+02:00 Pavel Stehule >: 2015-07-27 21:57 GMT+02:00 Andrew Dunstan mailto:and...@dunslane.net>>: On 07/27/2015 02:53 PM, Pavel Stehule wrote: I am trying to run par

Re: [HACKERS] proposal: multiple psql option -c

On 07/28/2015 04:43 AM, Marc Mamin wrote: > > >2015-07-28 5:24 GMT+02:00 Pavel Stehule : > >2015-07-27 21:57 GMT+02:00 Andrew Dunstan : > >On 07/27/2015 02:53 PM, Pavel Stehule wrote: > >I am trying to run parallel execution > >psql -At -c "select datname fro

Re: [HACKERS] [DESIGN] ParallelAppend

> KaiGai-san, > > On 2015-07-27 PM 11:07, Kouhei Kaigai wrote: > > > > Append > >--> Funnel > > --> PartialSeqScan on rel1 (num_workers = 4) > >--> Funnel > > --> PartialSeqScan on rel2 (num_workers = 8) > >--> SeqScan on rel3 > > > > shall be rewritten to > > Funn

Re: [HACKERS] proposal: multiple psql option -c

> > >2015-07-28 10:43 GMT+02:00 Marc Mamin : > > >> >> >>2015-07-28 5:24 GMT+02:00 Pavel Stehule : >> >>2015-07-27 21:57 GMT+02:00 Andrew Dunstan : >> >>On 07/27/2015 02:53 PM, Pavel Stehule wrote: >> >>I am trying to run parallel executi

Re: [HACKERS] pg_dump -Fd and compression level

On 07/27/2015 03:52 AM, Marc Mamin wrote: As per attached patch. Comments? It seems that the first test on the compression in pg_backup_tar.c is now obsolete. It didn't make much sense anyway. 211 if (AH->compression < 0 || AH->compression > 9) 212 AH->compressi

  1   2   >