Re: [HACKERS] Parallel Seq Scan

On Sat, Oct 24, 2015 at 07:49:07AM -0400, Robert Haas wrote: > On Fri, Oct 23, 2015 at 9:38 PM, Noah Misch wrote: > > Since that specification permits ParamListInfo consumers to ignore > > paramMask, > > the plpgsql_param_fetch() change from copy-paramlistinfo-fixes.patch is

Re: [HACKERS] JDBC driver debug out?

Thanks. It works. Best regards, -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese:http://www.sraoss.co.jp > Add > > DriverManager.setLogWriter(new PrintWriter(System.out)); > > below the setLogLevel and it will > > I'll fix this though > > Dave Cramer

Re: [HACKERS] [patch] extensions_path GUC

On Oct 23, 2015, at 9:26 AM, Jim Nasby wrote: > I would love it if make check worked. make installcheck adds extra effort to > extension develoopment, not to mention leaving your actual install in a less > than pristine state. I’ve wanted this for a long time. I

Re: [HACKERS] Rework the way multixact truncations work

I'm several days into a review of this change (commits 4f627f8 and aa29c1c). There's one part of the design I want to understand before commenting on specific code. What did you anticipate to be the consequences of failing to remove SLRU segment files that MultiXactState->oldestMultiXactId

Re: [HACKERS] Patch (2): Implement failover on libpq connect level.

В Fri, 23 Oct 2015 22:14:56 +0100 Thom Brown пишет: c> > > > pg_basebackup -v -x -D standby1 \ > > -d "host=localhost port=5532 user=rep_user readonly=1" > > Yes, this works: > > $ pg_basebackup -v -x -D standby1 -d "host=localhost port=5532 > user=rep_user readonly=1" >

Re: [HACKERS] Allow ssl_renegotiation_limit in PG 9.5

> > > Here's a patch that adds back the GUC, with default/min/max 0 and > > GUC_NO_SHOW_ALL | GUC_NOT_IN_SAMPLE | GUC_DISALLOW_IN_FILE. > > > > This is my first pg patch, please be gentle with any screwups :) > > Why, you dummy. > > No, actually, this looks fine. I've committed it and

Re: [HACKERS] Proposal: Trigonometric functions in degrees

On 24 October 2015 at 05:24, Dean Rasheed wrote: > Currently PostgreSQL only has trigonometric functions that work in > radians. I think it would be quite useful to have an equivalent set of > functions that worked in degrees. In other environments these are > commonly

Re: [HACKERS] Re: [BUGS] BUG #13611: test_postmaster_connection failed (Windows, listen_addresses = '0.0.0.0' or '::')

On 10/23/15 11:10 PM, Noah Misch wrote: > On RHEL 5 and some other "active adult" systems, "localhost" does not reach a > listen_addresses='::' server. IPv6 is available, but "localhost" resolves to > 127.0.0.1 only. > > The latest systems resolve "localhost" to both 127.0.0.1 and ::1, in which

Re: [HACKERS] Patch (2): Implement failover on libpq connect level.

В Fri, 23 Oct 2015 16:02:33 -0400 Korry Douglas пишет: d> > Now support for service files is implemented and multiple host > > statements in the service file are allowed. > > A couple of minor nits: > > When you call pg_is_in_recovery(), you should

Re: [HACKERS] JDBC driver debug out?

Add DriverManager.setLogWriter(new PrintWriter(System.out)); below the setLogLevel and it will I'll fix this though Dave Cramer da...@postgresintl.com www.postgresintl.com On 23 October 2015 at 22:35, Tatsuo Ishii wrote: > Unfortunately it doesn't work (no debug

[HACKERS] Proposal: Trigonometric functions in degrees

Currently PostgreSQL only has trigonometric functions that work in radians. I think it would be quite useful to have an equivalent set of functions that worked in degrees. In other environments these are commonly spelled sind(), cosd(), etc. Partly, this would be a matter of convenience. It's

Re: [HACKERS] Patch (2): Implement failover on libpq connect level.

On Fri, Oct 23, 2015 at 4:02 PM, Korry Douglas wrote: > When you call pg_is_in_recovery(), you should schema-qualify the function > name, just in case some other version of that function exists in the > search_path. I wonder whether it's really a good idea to put

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

On Sat, Oct 24, 2015 at 10:59 AM, Amit Kapila wrote: > On Mon, Oct 5, 2015 at 9:53 PM, Masahiko Sawada > wrote: >> >> On Mon, Oct 5, 2015 at 11:03 PM, Fujii Masao >> wrote: >> > On Fri, Oct 2, 2015 at 8:14 PM, Masahiko

Re: [HACKERS] Parallel Seq Scan

On Fri, Oct 23, 2015 at 9:38 PM, Noah Misch wrote: > Since that specification permits ParamListInfo consumers to ignore paramMask, > the plpgsql_param_fetch() change from copy-paramlistinfo-fixes.patch is still > formally required. So why am I not just doing that, then? Seems