Re: [HACKERS] Showing parallel status in \df+

Michael Paquier writes: > On Tue, Jul 12, 2016 at 11:36 AM, Alvaro Herrera > wrote: >> So prosrc for internal/C and NULL for others? WFM. > And so we'd remove "Language" at the same time? That does not sound bad to me. Hm, I wasn't thinking

Re: [HACKERS] Showing parallel status in \df+

On Tue, Jul 12, 2016 at 11:36 AM, Alvaro Herrera wrote: > Stephen Frost wrote: >> * Tom Lane (t...@sss.pgh.pa.us) wrote: > >> > It would certainly be easy enough to do that, as long as you don't mind >> > hard-wiring into psql the knowledge that "internal" and "C" are

Re: [HACKERS] [BUG] pg_basebackup from disconnected standby fails

On Thu, Jun 23, 2016 at 12:20 PM, Michael Paquier wrote: > On Wed, Jun 15, 2016 at 4:52 PM, Kyotaro HORIGUCHI > wrote: >> Hello, > > Sorry for the late reply, Horiguchi-san. I have finally been able to > put some mind power into that. >

Re: [HACKERS] asynchronous and vectorized execution

I forgot to mention. At Tue, 12 Jul 2016 11:04:17 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI wrote in <20160712.110417.145469826.horiguchi.kyot...@lab.ntt.co.jp> > Cooled down then measured performance again. > > I show you the true result briefly for now.

Re: [HACKERS] Showing parallel status in \df+

Stephen Frost wrote: > * Tom Lane (t...@sss.pgh.pa.us) wrote: > > It would certainly be easy enough to do that, as long as you don't mind > > hard-wiring into psql the knowledge that "internal" and "C" are the > > languages to show prosrc for. "Source code" would no longer be a very > >

Re: [HACKERS] asynchronous and vectorized execution

Cooled down then measured performance again. I show you the true result briefly for now. At Mon, 11 Jul 2016 19:07:22 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI wrote in <20160711.190722.145849861.horiguchi.kyot...@lab.ntt.co.jp> > Anyway I need some time

[HACKERS] use of SEQ_MINVALUE in btree_gin

btree_gin uses SEQ_MINVALUE as a way to get the smallest int64 value. This is actually wrong because the smallest int64 value is SEQ_MINVALUE-1, so this might be slightly broken. The whole thing was done as a convenience when INT64_IS_BUSTED had to be considered, but I think we can get rid of

Re: [HACKERS] remove checkpoint_warning

On 11 July 2016 at 22:25, Stephen Frost wrote: > * Tom Lane (t...@sss.pgh.pa.us) wrote: > > Alvaro Herrera writes: > > > the checkpoint_warning feature was added by commit > 2986aa6a668bce3cfb836 > > > in November 2002 when we didn't have any

Re: [HACKERS] Changing the result set to contain the cost of the optimizer's chosen plan

On 11 July 2016 at 23:29, Tom Lane wrote: > Srinivas Karthik V writes: > > Specifically, I have a Java program which calls > > ResultSet rs = statement.executeQuery("explain select * from table"); > > I would like to change PostgreSQL such that

Re: [HACKERS] remove checkpoint_warning

* Andres Freund (and...@anarazel.de) wrote: > On 2016-07-11 11:14:29 -0700, Peter Geoghegan wrote: > > On Mon, Jul 11, 2016 at 7:25 AM, Stephen Frost wrote: > > >> Or in short, this may be a fine change to make, but I don't like your > > >> argument for it. > > > > > > I don't

Re: [HACKERS] Showing parallel status in \df+

* Tom Lane (t...@sss.pgh.pa.us) wrote: > Stephen Frost writes: > > I agree with removing the source code field, though I did like the > > suggestion mentioned elsewhere for having it shown when it's just a C > > symbol but not otherwise. If we can find a way to have the C

Re: [HACKERS] GiST index build versus NaN coordinates

Emre Hasegeli writes: >> I think that probably the most reasonable answer is to replace all the >> raw "double" comparisons in this code with float8_cmp_internal() or >> something that's the moral equivalent of that. Does anyone want to >> propose something else? > We can

Re: [HACKERS] GiST index build versus NaN coordinates

> I think that probably the most reasonable answer is to replace all the > raw "double" comparisons in this code with float8_cmp_internal() or > something that's the moral equivalent of that. Does anyone want to > propose something else? We can probably get away by changing the comparison on the

Re: [HACKERS] IMPORT FOREIGN SCHEMA can't be run in in pl/pgsql due to INTO

Merlin Moncure writes: > Currently pl/pgsql interprets the mandatory INTO of IMPORT FOREIGN > SCHEMA as INTO variable. Ugh, that's definitely a bug. > I estimate this to be minor oversight in > pl/pgsql parsing with respect to the introduction of this statement. While we

[HACKERS] IMPORT FOREIGN SCHEMA can't be run in in pl/pgsql due to INTO

Currently pl/pgsql interprets the mandatory INTO of IMPORT FOREIGN SCHEMA as INTO variable. I estimate this to be minor oversight in pl/pgsql parsing with respect to the introduction of this statement. Assuming it's easily fixed, would a patch to fix pl/pgsql parsing be accepted? merlin --

Re: [HACKERS] Disable WAL completely - Performance and Persistency research

On Thu, Jul 7, 2016 at 1:01 AM, Netanel Katzburg wrote: > Hi All, > > As part of my masters at TAU, I'm currently conducting some research > regarding new persistent memory technology. > I'm using PG for this research and would like to better understand some of > the

Re: [HACKERS] remove checkpoint_warning

On 2016-07-11 11:14:29 -0700, Peter Geoghegan wrote: > On Mon, Jul 11, 2016 at 7:25 AM, Stephen Frost wrote: > >> Or in short, this may be a fine change to make, but I don't like your > >> argument for it. > > > > I don't agree that it's sensible to get rid of. Having just >

Re: [HACKERS] remove checkpoint_warning

On Mon, Jul 11, 2016 at 7:25 AM, Stephen Frost wrote: >> Or in short, this may be a fine change to make, but I don't like your >> argument for it. > > I don't agree that it's sensible to get rid of. Having just > log_checkpoints will have the logs filled with checkpoints

Re: [HACKERS] Showing parallel status in \df+

Stephen Frost writes: > I agree with removing the source code field, though I did like the > suggestion mentioned elsewhere for having it shown when it's just a C > symbol but not otherwise. If we can find a way to have the C symbol > shown when it's a C or internal function,

Re: [HACKERS] Showing parallel status in \df+

* Tom Lane (t...@sss.pgh.pa.us) wrote: > Michael Paquier writes: > > On Mon, Jul 11, 2016 at 12:42 AM, Tom Lane wrote: > >> (Of course, if we were to get rid of "Source code", the point > >> would be moot ...) > > > I still think that having source

Re: [HACKERS] Changing the result set to contain the cost of the optimizer's chosen plan

Srinivas Karthik V writes: > Specifically, I have a Java program which calls > ResultSet rs = statement.executeQuery("explain select * from table"); > I would like to change PostgreSQL such that ResultSet rs should contain a > field that contains also the cost of the

Re: [HACKERS] [CF2016-9] Allow spaces in working path on tap-tests

Michael Paquier writes: > On Sun, Jul 10, 2016 at 11:52 PM, Tom Lane wrote: >> Yes, please --- I thought it'd all gotten done. > OK, here are patches for 9.1, 9.2 and 9.3. Pushed, thanks. regards, tom lane -- Sent via

[HACKERS] Changing the result set to contain the cost of the optimizer's chosen plan

Hello, I am Srinivas and have been working inside PostgreSQL (mostly in the optimizer module and few times in the executor module). I would like to change PostgreSQL code such that it also returns the cost of the optimizer chosen plan to the Java program (through JDBC) as part of the result set.

Re: [HACKERS] pg_xlogdump bad error msg?

On 2016-07-11 13:36:37 +0200, Magnus Hagander wrote: > When you don't specify a start segment to pg_xlogdump, you get: > > pg_xlogdump: no start log position given in range mode. > > > What is "range mode", and is there any other mode for pg_xlogdump? Should > it not just be "no start log

Re: [HACKERS] Reviewing freeze map code

On Fri, Jul 8, 2016 at 10:24 PM, Amit Kapila wrote: > On Thu, Jul 7, 2016 at 12:34 PM, Masahiko Sawada > wrote: >> Than you for reviewing! >> >> On Thu, Jul 7, 2016 at 7:06 AM, Andres Freund wrote: >>> On 2016-07-05 23:37:59

Re: [HACKERS] Showing parallel status in \df+

Michael Paquier writes: > On Mon, Jul 11, 2016 at 12:42 AM, Tom Lane wrote: >> (Of course, if we were to get rid of "Source code", the point >> would be moot ...) > I still think that having source code is useful for debugging, so I > left it out.

Re: [HACKERS] sslmode=require fallback

On Thu, Jun 23, 2016 at 1:50 AM, Bruce Momjian wrote: > On Thu, Jun 16, 2016 at 10:42:56AM +0200, Magnus Hagander wrote: > > However, if this is the expected behavior, the documentation > at https:// > > www.postgresql.org/docs/current/static/libpq-ssl.html should be >

Re: [HACKERS] remove checkpoint_warning

* Tom Lane (t...@sss.pgh.pa.us) wrote: > Alvaro Herrera writes: > > the checkpoint_warning feature was added by commit 2986aa6a668bce3cfb836 > > in November 2002 when we didn't have any logging of checkpointing at > > all. I propose to remove it: surely anyone who cares

[HACKERS] GiST index build versus NaN coordinates

I looked into the problem reported in bug #14238, https://www.postgresql.org/message-id/20160708151747.1426.60...@wrigleys.postgresql.org The submitter was kind enough to give me a copy of the problem data, and it turns out that the issue is that a few of the boxes contain NaN coordinates. Armed

Re: [HACKERS] pg_hba_lookup function to get all matching pg_hba.conf entries

Haribabu Kommi writes: > On Sat, Apr 9, 2016 at 6:36 AM, Tom Lane wrote: >> More generally, I'm not convinced about the use-case for this patch. >> What problem is it supposed to help in dealing with, exactly? Not syntax >> errors in the hba file,

Re: [HACKERS] Disable WAL completely - Performance and Persistency research

Hi, You were right, the method you described worked well. Thanks you! But so far, could not get any noticeable improvement in Number of transactions / latency. I have tried: 1. At xlog.c, CopyXLogRecordToWAL(int write_len, bool isLogSwitch, XLogRecData *rdata, XLogRecPtr StartPos, XLogRecPtr

Re: [HACKERS] [BUGS] BUG #14230: Wrong timeline returned by pg_stop_backup on a standby

On Mon, Jul 11, 2016 at 3:05 PM, Michael Paquier wrote: > On Mon, Jul 11, 2016 at 7:01 PM, Magnus Hagander > wrote: > > But isn't this also a pre-existing bug in 9.5? Or did we change something > > else that suddenly made it visible? > > What has

Re: [HACKERS] [BUGS] BUG #14230: Wrong timeline returned by pg_stop_backup on a standby

On Mon, Jul 11, 2016 at 7:01 PM, Magnus Hagander wrote: > But isn't this also a pre-existing bug in 9.5? Or did we change something > else that suddenly made it visible? What has been patched here is a defect caused by pg_start_backup(), and not pg_basebackup. In the case of

Re: [HACKERS] PSA: Systemd will kill PostgreSQL

On 11 July 2016 at 17:49, Bernd Helmle wrote: > > > --On 11. Juli 2016 13:25:51 +0800 Craig Ringer > wrote: > > > Perhaps by uid threshold in login.defs? > > systemd's configure.ac has this: > > AC_ARG_WITH(system-uid-max, >

Re: [HACKERS] Disable WAL completely - Performance and Persistency research

On 11 July 2016 at 19:14, Netanel Katzburg wrote: > Hi, > > You were right, the method you described worked well. Thanks you! > > But so far, could not get any noticeable improvement in Number of > transactions / latency. > > What are you comparing to? To start with,

Re: [HACKERS] \timing interval

On 7/9/16 4:00 PM, Andrew Gierth wrote: How about Time: 1234567.666 ms (20m 34.6s) That's similar to what I had in mind, so I'd be happy with that. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via

[HACKERS] pg_xlogdump bad error msg?

When you don't specify a start segment to pg_xlogdump, you get: pg_xlogdump: no start log position given in range mode. What is "range mode", and is there any other mode for pg_xlogdump? Should it not just be "no start log position or segment given" or something like that? -- Magnus Hagander

Re: [HACKERS] [BUGS] BUG #14230: Wrong timeline returned by pg_stop_backup on a standby

On Mon, Jul 11, 2016 at 3:31 PM, Magnus Hagander wrote: > > > On Thu, Jul 7, 2016 at 8:38 AM, Michael Paquier > wrote: >> >> On Thu, Jul 7, 2016 at 12:57 AM, Marco Nenciarini >> wrote: >> > After further analysis,

Re: [HACKERS] asynchronous and vectorized execution

At Mon, 11 Jul 2016 17:10:11 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI wrote in <20160711.171011.133133724.horiguchi.kyot...@lab.ntt.co.jp> > > Two things: > > > > 1. That's not the scenario I'm talking about. I'm concerned about > > making sure that

Re: [HACKERS] [BUGS] BUG #14230: Wrong timeline returned by pg_stop_backup on a standby

On Thu, Jul 7, 2016 at 8:38 AM, Michael Paquier wrote: > On Thu, Jul 7, 2016 at 12:57 AM, Marco Nenciarini > wrote: > > After further analysis, the issue is that we retrieve the starttli from > > the ControlFile structure, but it was

Re: [HACKERS] PSA: Systemd will kill PostgreSQL

--On 11. Juli 2016 13:25:51 +0800 Craig Ringer wrote: > Perhaps by uid threshold in login.defs? systemd's configure.ac has this: AC_ARG_WITH(system-uid-max, AS_HELP_STRING([--with-system-uid-max=UID] [Maximum UID for system users]),

Re: [HACKERS] asynchronous and vectorized execution

Hello, At Thu, 7 Jul 2016 13:59:54 -0400, Robert Haas wrote in > On Wed, Jul 6, 2016 at 3:29 AM, Kyotaro HORIGUCHI > wrote: > > This seems to be a good opportunity to

Re: [HACKERS] [BUG] pg_basebackup from disconnected standby fails

On Mon, Jul 11, 2016 at 4:40 PM, Kyotaro HORIGUCHI wrote: > That's true, but we don't always have a perfectly comprehensive > test suite, consciously or unconsciously. The sentence was > inattentive but the "bug" was just the negative comparable to > "feature" in

Re: [HACKERS] [BUG] pg_basebackup from disconnected standby fails

Hello, thank you for the comment. At Fri, 8 Jul 2016 14:42:20 -0400, Alvaro Herrera wrote in <20160708184220.GA733807@alvherre.pgsql> > Kyotaro HORIGUCHI wrote: > > > At Fri, 10 Jun 2016 17:39:59 +0900, Michael Paquier > > wrote in > >