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

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 pointer to the new end of string. > > Also if we're specify

[HACKERS] Typo in a comment in set_foreignscan_references

Attached fixes a minor typo: s/custom/foreign/g Thanks, Amit diff --git a/src/backend/optimizer/plan/setrefs.c b/src/backend/optimizer/plan/setrefs.c index ea185d4..ee8710d 100644 --- a/src/backend/optimizer/plan/setrefs.c +++ b/src/backend/optimizer/plan/setrefs.c @@ -1099,7 +1099,7 @@ set_forei

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 there between them? > > If other n

Re: [HACKERS] A little RLS oversight?

On 28 July 2015 at 03:19, Joe Conway wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > 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 shou

Re: [HACKERS] [DESIGN] ParallelAppend

On Tue, Jul 28, 2015 at 12:59 PM, David Rowley wrote: > > On 27 July 2015 at 21:09, Kyotaro HORIGUCHI < > horiguchi.kyot...@lab.ntt.co.jp> 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

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

> > >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 from pg_database" postgres | xargs -n > 1 -P 3

Re: [HACKERS] REVOKE [ADMIN OPTION FOR] ROLE

On 27.07.2015 22:09, Stephen Frost wrote: * Egor Rogov (e.ro...@postgrespro.ru) wrote: On Thu, Jul 23, 2015 at 8:30 AM, Egor Rogov wrote: So, the question: is it a documentation bug (as it seems to me), code bug, or I missed something? Your analysis looks right to me, but I don't know whether

[HACKERS] pg_rewind tap test unstable

Hi, for something between 10% and 20% of the devel builds for apt.postgresql.org (which happen every 6h if there's a git change, so it happens every few days), I'm seeing this: make[2]: Entering directory '/tmp/buildd/postgresql-9.6-9.6~~devel~20150728.0405/build/src/bin/pg_rewind' rm -rf /tmp/

Re: [HACKERS] Autonomous Transaction is back

On Tue, Jul 28, 2015 at 12:56 AM, Josh Berkus wrote: > Ah, ok. The goal of the project is that the writer of X() *cannot* > prevent Y() from writing its data (B1) and committing it. > > One of the primary use cases for ATX is audit triggers. If a function > writer could override ATX and preven

Re: [HACKERS] pg_rewind tap test unstable

On Tue, Jul 28, 2015 at 5:57 PM, Christoph Berg wrote: > for something between 10% and 20% of the devel builds for apt.postgresql.org > (which happen every 6h if there's a git change, so it happens every few days), > I'm seeing this: > Dubious, test returned 1 (wstat 256, 0x100) > Failed 1/8 subte

Re: [HACKERS] Autonomous Transaction is back

On 23 July 2015 at 13:31, Rajeev rastogi wrote: > 1.The autonomous transaction treated as a completely different > transaction from the master transaction. Personally I think that's a lot more useful than having the inner tx able to see the outer tx's uncommitted changes. > 2.

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 execution > > > >psql -At -c

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

On 17 July 2015 at 03:42, Pavel Stehule wrote: > Hi > > can we support multiple "-c" option? > > Why? Because some statements like VACUUM cannot be used together with any > other statements with single -c option. The current solution is using echo > and pipe op, but it is a complication in some co

Re: [HACKERS] [DESIGN] ParallelAppend

> On Tue, Jul 28, 2015 at 7:59 AM, Kouhei Kaigai wrote: > > > > > -Original Message- > > > From: pgsql-hackers-ow...@postgresql.org > > > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Kouhei Kaigai > > > Sent: Monday, July 27, 2015 11:07 PM > > > To: Amit Kapila > > > > > > > >

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

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

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

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

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

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

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

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

* 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

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

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

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

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

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

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

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

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

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

  1   2   >