Re: [HACKERS] Writing new unit tests with PostgresNode

At 2016-02-22 07:45:37 +, e...@xs4all.nl wrote: > > I think what's needed is: > > use 5.008_008; That is meant to fail if the code is run on a version of Perl older than 5.8.8, not fail if the code uses language features not present in 5.8.8. It is little help for those trying to maintain

Re: [HACKERS] Writing new unit tests with PostgresNode

- All the core routines used should be compatible down to perl 5.8.8. Ugh. So not just Perl, ancient perl. I don't suppose Perl offers any kind of "compatible(5.8.8)" statement or anything? Do I have to compile a ten-year-old Perl and its dependencies to work on PostgreSQL tests?

Re: [HACKERS] Writing new unit tests with PostgresNode

On Mon, Feb 22, 2016 at 4:24 PM, Craig Ringer wrote: > On 22 February 2016 at 14:30, Michael Paquier > wrote: >> - All the core routines used should be compatible down to perl 5.8.8. > > Ugh. So not just Perl, ancient perl. > > I don't suppose

Re: [HACKERS] Writing new unit tests with PostgresNode

On 22 February 2016 at 14:30, Michael Paquier wrote: > +1. I will be happy to contribute into that. > Thanks. Hopefully what I wrote will be useful as a starting point. As I read through the modules I'll write some draft Perldoc too. > > The docs at

Re: [HACKERS] Add generate_series(date,date) and generate_series(date,date,integer)

On Mon, Feb 22, 2016 at 6:52 AM, Tom Lane wrote: > Oooh ... actually, that works today if you consider the SRF-in-targetlist > case: > > regression=# select generate_series(now(), 'infinity', '1 day') limit 10; > generate_series > --- >

Re: [HACKERS] about google summer of code 2016

On 02/21/16 23:10, Tom Lane wrote: > Another variable is that your answers might depend on what format you > assume the client is trying to convert from/to. (It's presumably not > text JSON, but then what is it?) This connects tangentially to a question I've been meaning to ask for a while,

Re: [HACKERS] Writing new unit tests with PostgresNode

On Mon, Feb 22, 2016 at 2:19 PM, Craig Ringer wrote: > I've been taking a look at the Perl test infrastructure ( src/test/perl ) > for writing multi-node tests, starting with PostgresNode.pm and I have a few > comments based on my first approach to the code "cold". > > I

Re: [HACKERS] proposal: make NOTIFY list de-duplication optional

On Sat, Feb 20, 2016 at 2:00 PM, Filip Rembiałkowski wrote: > I was stuck because both syntaxes have their ugliness. NOTIFY allows the > payload to be NULL: > NOTIFY chan01; > > How would this look like in "never" mode? > NOTIFY chan01, NULL, 'never'; -- seems very

Re: [HACKERS] postgres_fdw vs. force_parallel_mode on ppc

On Tue, Feb 16, 2016 at 12:12 PM, Noah Misch wrote: > On Mon, Feb 15, 2016 at 06:07:48PM -0500, Tom Lane wrote: >> Noah Misch writes: >> > I configured a copy of animal "mandrill" that way and launched a test run. >> > The postgres_fdw suite failed as

[HACKERS] Writing new unit tests with PostgresNode

Hi all I've been taking a look at the Perl test infrastructure ( src/test/perl ) for writing multi-node tests, starting with PostgresNode.pm and I have a few comments based on my first approach to the code "cold". I think a README in src/test/perl/ would be very helpful. It's currently not at

Re: [HACKERS] Handling changes to default type transformations in PLs

> 4) Create a mechanism for specifying default TRANSFORMs for a PL, and > essentially "solve" these issues by supplying a built-in transform. > > I think default transforms (4) are worth doing no matter what. Having to > manually remember to add potentially multiple TRANSFORMs is a PITA. But I'm >

Re: [HACKERS] Handling changes to default type transformations in PLs

> > 3) Add the concept of PL API versions. This would allow users to specify > > So that leaves #3, which doesn't seem all that unreasonable from here. > We don't have a problem with bundling a bunch of unrelated changes > into any one major PG revision. The scripting languages we're talking >

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

On Wed, Feb 3, 2016 at 8:59 AM, Robert Haas wrote: > > On Tue, Feb 2, 2016 at 10:27 PM, Amit Kapila wrote: > > So, let's leave adding any additional column, but Alexander has brought up > > a good point about storing the wait_type and actual

Re: [HACKERS] How are CREATE EXTENSION ... VERSION or ALTER EXTENSION ... UPDATE TO ... intended to work?

On 02/16/16 22:44, Tom Lane wrote: > Chapman Flack writes: >> been several releases of an extension, and the extensions directory >> is now populated with a bunch of files quux--1.0.sql, quux--1.1.sql, >> quux--1.0--1.1.sql, quux--1.1--1.0.sql, ..., quux.control. >> And

Re: [HACKERS] Handling changes to default type transformations in PLs

Jim Nasby writes: > Some of our PLs have the unfortunate problem of making a weak effort > with converting types to and from the PL and Postgres. For example, > plpythonu will correctly transform a complex type to a dict and an array > to a list, but it punts back to

Re: [HACKERS] about google summer of code 2016

Heikki Linnakangas writes: > On 19/02/16 10:10, Álvaro Hernández Tortosa wrote: >> Oleg and I discussed recently that a really good addition to a GSoC >> item would be to study whether it's convenient to have a binary >> serialization format for jsonb over the wire. > Seems a

[HACKERS] Handling changes to default type transformations in PLs

Some of our PLs have the unfortunate problem of making a weak effort with converting types to and from the PL and Postgres. For example, plpythonu will correctly transform a complex type to a dict and an array to a list, but it punts back to text for an array contained inside a complex type. I

Re: [HACKERS] psql metaqueries with \gexec

On 2/19/16 7:32 PM, Corey Huinker wrote: Wow, and I thought *I* liked metaprogramming! :) I like what you've proposed, though I am wondering if you considered doing something server-side instead? It seems a shame to do all this work and exclude all other tools. I frequently find myself

Re: [HACKERS] Allow to specify (auto-)vacuum cost limits relative to the database/cluster size?

On 1/12/16 6:42 AM, Andres Freund wrote: Somehow computing the speed in relation to the cluster/database size is probably possible, but I wonder how we can do so without constantly re-computing something relatively expensive? ISTM relpages would probably be good enough for this, if we take the

Re: [HACKERS] about google summer of code 2016

On 19/02/16 10:10, Álvaro Hernández Tortosa wrote: Oleg and I discussed recently that a really good addition to a GSoC item would be to study whether it's convenient to have a binary serialization format for jsonb over the wire. Some argue this should be benchmarked first. So the scope for

Re: [HACKERS] Proposal: "Causal reads" mode for load balancing reads without stale data

On 21 February 2016 at 23:18, Thomas Munro wrote: > On Mon, Feb 22, 2016 at 2:10 AM, Thom Brown wrote: >> On 3 February 2016 at 10:46, Thomas Munro >> wrote: >>> On Wed, Feb 3, 2016 at 10:59 PM, Amit Langote >>>

Re: [HACKERS] Relaxing SSL key permission checks

Stephen Frost writes: > Just to be clear, I'm not really against this patch as-is, but it > shouldn't be a precedent or limit us from supporting more permissive > permissions in other areas (or even here) if there are sensible > use-cases for more permissive permissions. OK,

Re: [HACKERS] Proposal: "Causal reads" mode for load balancing reads without stale data

On Mon, Feb 22, 2016 at 2:10 AM, Thom Brown wrote: > On 3 February 2016 at 10:46, Thomas Munro > wrote: >> On Wed, Feb 3, 2016 at 10:59 PM, Amit Langote >> wrote: >>> There seems to be a copy-pasto there - shouldn't

[HACKERS] significant semi join overestimates (with CTEs)

Hi, while investigating a poor query plan choice, I've noticed suspicious semi join estimates looking like this: -> Nested Loop (cost=35.52..1787.31 rows=281653470 width=566) Buffers: shared hit=9305 -> HashAggregate (cost=34.81..36.81 rows=200 width=32) Group

Re: [HACKERS] Relaxing SSL key permission checks

* Tom Lane (t...@sss.pgh.pa.us) wrote: > Christoph Berg writes: > > The attached patch has successfully been included in the 9.6 Debian > > package, passed the regression tests there, and I've also done some > > chmod/chown tests on the filesystem to verify it indeed catches the

Re: [HACKERS] checkpointer continuous flushing - V18

ISTM that "progress" and "progress_slice" only depend on num_scanned and per-tablespace num_to_scan and total num_to_scan, so they are somehow redundant and the progress could be recomputed from the initial figures when needed. They don't cause much space usage, and we access the values

Re: [HACKERS] Add generate_series(date,date) and generate_series(date,date,integer)

Christoph Berg writes: > Re: David Fetter 2016-01-26 <20160126180011.ga16...@fetter.org> >> +1 for back-patching. There's literally no case where an infinite >> input could be correct as the start or end of an interval for >> generate_series. > select * from

Re: [HACKERS] checkpointer continuous flushing - V18

[...] I do think that this whole writeback logic really does make sense *per table space*, Leads to less regular IO, because if your tablespaces are evenly sized (somewhat common) you'll sometimes end up issuing sync_file_range's shortly after each other. For latency outside checkpoints it's

Re: [HACKERS] Add generate_series(date,date) and generate_series(date,date,integer)

Re: David Fetter 2016-01-26 <20160126180011.ga16...@fetter.org> > +1 for back-patching. There's literally no case where an infinite > input could be correct as the start or end of an interval for > generate_series. select * from generate_series(now(), 'infinity', '1 day') limit 10; ... seems

Re: [HACKERS] Re: [COMMITTERS] pgsql: Add some isolation tests for deadlock detection and resolution.

I wrote: > Robert Haas writes: >> As for the patch itself, I'm having trouble grokking what it's trying >> to do. I think it might be worth having a comment defining precisely >> what we mean by "A blocks B". I would define "A blocks B" in general >> as either A holds a

Re: [HACKERS] Proposal: "Causal reads" mode for load balancing reads without stale data

On 3 February 2016 at 10:46, Thomas Munro wrote: > On Wed, Feb 3, 2016 at 10:59 PM, Amit Langote > wrote: >> There seems to be a copy-pasto there - shouldn't that be: >> >> + if (walsndctl->lsn[SYNC_REP_WAIT_FLUSH] < MyWalSnd->flush)

Re: [HACKERS] checkpointer continuous flushing - V18

Hi, On 2016-02-21 10:52:45 +0100, Fabien COELHO wrote: > * CpktSortItem: > > I think that allocating 20 bytes per buffer in shared memory is a little on > the heavy side. Some compression can be achieved: sizeof(ForlNum) is 4 bytes > to hold 4 values, could be one byte or even 2 bits somewhere.

Re: [HACKERS] checkpointer continuous flushing - V18

On 2016-02-21 08:26:28 +0100, Fabien COELHO wrote: > >>In the discussion in the wal section, I'm not sure about the effect of > >>setting writebacks on SSD, [...] > > > >Yea, that paragraph needs some editing. I think we should basically > >remove that last sentence. > > Ok, fine with me. Does

Re: [HACKERS] Re: Add generate_series(date, date) and generate_series(date, date, integer)

On 02/21/2016 07:56 PM, Corey Huinker wrote: > > Other than that, the only difference is the ::date part. Is it > really worth adding extra code just for that? I would say not. > > > I would argue it belongs for the sake of completeness. So would I. +1 for adding this missing

Re: [HACKERS] Relaxing SSL key permission checks

Christoph Berg writes: > The attached patch has successfully been included in the 9.6 Debian > package, passed the regression tests there, and I've also done some > chmod/chown tests on the filesystem to verify it indeed catches the > cases laid out by Tom. Please add this to

Re: [HACKERS] Re: Add generate_series(date, date) and generate_series(date, date, integer)

> > > [step] is in days, but is not documented as such. > > It is in days, and is not documented as such, but since a day is the smallest unit of time for a date, I felt there was no other interpretation. > My understanding is you want to replace this > > SELECT d.dt::date as dt > FROM

Re: [HACKERS] [COMMITTERS] pgsql: Cosmetic improvements in new config_info code.

Stephen Frost writes: > * Joe Conway (m...@joeconway.com) wrote: >> FWIW, strcpy() was being used in src/bin/pg_config/pg_config.c that I >> started with -- does that mean we are not getting Coverity coverage of >> src/bin? > Coverity does run against src/bin also. It's

[HACKERS] Re: [COMMITTERS] pgsql: Cosmetic improvements in new config_info code.

Joe, all, * Joe Conway (m...@joeconway.com) wrote: > On 02/21/2016 08:38 AM, Tom Lane wrote: > > Coverity griped about use of unchecked strcpy() into a local variable. > > There's unlikely to be any actual bug there, since no caller would be > > passing a path longer than MAXPGPATH, but

Re: [HACKERS] a raft of parallelism-related bug fixes

Robert Haas writes: > On Mon, Feb 8, 2016 at 2:36 PM, Joshua D. Drake > wrote: >> I have no problem running any test cases you wish on a branch in a loop for >> the next week and reporting back any errors. > Well, what I've done is push into the

Re: [HACKERS] Re: [COMMITTERS] pgsql: Introduce group locking to prevent parallel processes from deadl

I wrote: > Robert Haas writes: >> Yeah, you're right. Attached is a draft patch that tries to clean up >> that and a bunch of other things that you raised. > I've been reviewing this patch, and I had a question: why do we need to > bother with a lockGroupLeaderIdentifier

Re: [HACKERS] proposal: enhancing slow query log, and autoexplain log about waiting on lock before query exec time

Hi >> What would be useful logging-wise is if the log line for the query itself >> could contain lock wait time, but that doesn't sound like what you're >> proposing? >> > > I hope, so I propose this idea. First time I wanted talk about the idea. > Next step is the talk about format. > Some

Re: [HACKERS] Speed up Clog Access by increasing CLOG buffers

On Sun, Feb 21, 2016 at 2:28 PM, Robert Haas wrote: > On Sun, Feb 21, 2016 at 12:24 PM, Amit Kapila > wrote: > >> On Sun, Feb 21, 2016 at 12:02 PM, Robert Haas >> wrote: >> >>> On Sun, Feb 21, 2016 at 10:27 AM, Amit Kapila

Re: [HACKERS] exposing pg_controldata and pg_config as functions

On Sat, Feb 20, 2016 at 12:12 PM, Joe Conway wrote: > On 01/17/2016 04:10 PM, Joe Conway wrote: >> On 01/16/2016 06:02 AM, Michael Paquier wrote: >>> On Wed, Dec 30, 2015 at 9:08 AM, Joe Conway wrote: 3) Adds new functions, more or less in line with

Re: [HACKERS] Re: BUG #13685: Archiving while idle every archive_timeout with wal_level hot_standby

On Fri, Feb 19, 2016 at 10:33 PM, Amit Kapila wrote: > On Fri, Feb 12, 2016 at 6:57 PM, Michael Paquier wrote: > You doesn't seem to have taken care of below typo in your patch as > pointed out by me earlier. > > + * to not rely on taking an exclusive lock an all the WAL insertion locks, > > /an

Re: [HACKERS] Relaxing SSL key permission checks

Re: To Tom Lane 2016-02-19 <20160219115334.gb26...@msg.df7cb.de> > Updated patch attached. *Blush* I though I had compile-tested the patch, but without --enable-openssl it wasn't built :(. The attached patch has successfully been included in the 9.6 Debian package, passed the regression tests

Re: [HACKERS] checkpointer continuous flushing - V18

Hallo Andres, Here is a review for the second patch. For 0002 I've recently changed: * Removed the sort timing information, we've proven sufficiently that it doesn't take a lot of time. I put it there initialy to demonstrate that there was no cache performance issue when sorting on just

Re: [HACKERS] Speed up Clog Access by increasing CLOG buffers

On Sun, Feb 21, 2016 at 12:24 PM, Amit Kapila wrote: > On Sun, Feb 21, 2016 at 12:02 PM, Robert Haas > wrote: > >> On Sun, Feb 21, 2016 at 10:27 AM, Amit Kapila >> wrote: >> >>> >>> Client_Count/Patch_Ver 1 64 128 256 >>>

Re: [HACKERS] postgres_fdw join pushdown (was Re: Custom/Foreign-Join-APIs)

On Thu, Feb 18, 2016 at 4:52 PM, Ashutosh Bapat wrote: > If the list in the joining relation changes (may be because we appended > parameterized conditions), we would be breaking links on all the upper > relations in the join tree in an unpredictable manner. The

Re: [HACKERS] plpgsql - DECLARE - cannot to use %TYPE or %ROWTYPE for composite types

Hi I am sending updated version - the changes are related to fix comments. 2016-02-19 10:41 GMT+01:00 Artur Zakirov : > It seems all fixes are done. I tested the patch and regression tests > passed. > > I think here Alvaro means that you should keep original comment

Re: [HACKERS] checkpointer continuous flushing - V18

Hallo Andres, [...] I do think that this whole writeback logic really does make sense *per table space*, Leads to less regular IO, because if your tablespaces are evenly sized (somewhat common) you'll sometimes end up issuing sync_file_range's shortly after each other. For latency outside