Re: [HACKERS] Inaccurate results from numeric ln(), log(), exp() and pow()

On 14 November 2015 at 20:05, Tom Lane wrote: > I committed this with that change and some other > mostly-cosmetic revisions. Thanks. > Notable non-cosmetic changes: > > * I forced all the computed rscales to be at least 0, via code like > local_rscale =

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

On 11/15/2015 08:50 AM, Catalin Iacob wrote: On Sun, Nov 15, 2015 at 1:27 AM, Andrew Dunstan wrote: That seems to me to get rid of the main motivation for this change, which is to allow multiple such arguments, which together would as as if they were all written to a

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

On Sun, Nov 15, 2015 at 1:27 AM, Andrew Dunstan wrote: > That seems to me to get rid of the main motivation for this change, which is > to allow multiple such arguments, which together would as as if they were > all written to a file which was then invoked like -f file. It

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

On Sun, Nov 15, 2015 at 5:41 AM, Simon Riggs wrote: > Hmm, if that's where we're at, I'll summarize my thoughts. > > All of this discussion presupposes we are distributing/load balancing > queries so that reads and writes might occur on different nodes. Agreed. I think

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

On 12 November 2015 at 18:25, Thomas Munro wrote: > I don't want to get bogged down in details, while we're talking about the > 30,000 foot view). > Hmm, if that's where we're at, I'll summarize my thoughts. All of this discussion presupposes we are

Re: [HACKERS] pg_stat_statements query jumbling question

On Sun, Nov 15, 2015 at 1:34 AM, Tom Lane wrote: > Michael Paquier writes: >> On Sun, Nov 1, 2015 at 2:03 AM, Julien Rouhaud >> wrote: >>> I'm also rather sceptical about this change. > >> Hm. Thinking a bit about this

Re: [HACKERS] eXtensible Transaction Manager API

I am sorry, looks like I had incorrectly interpret Michael's comment: Not always. If COMMIT PREPARED fails at some of the nodes but succeeds on others, the transaction is already partially acknowledged as committed in the cluster. Hence it makes more sense for the coordinator to commit

Re: [HACKERS] psql: add \pset true/false

On 11/12/15 3:09 PM, Tom Lane wrote: Peter Eisentraut writes: Plus we already have \pset numericlocale as a similar feature in psql. But \pset numericlocale is also a crock. It doesn't affect COPY output for instance, and its ability to identify which data types it should

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

On Fri, Nov 13, 2015 at 11:37 AM, Ildus Kurbangaliev wrote: > Thanks! That's very inspiring. Cool. It was great work; I am very happy with how it turned out. > I have some questions about next steps on other tranches. > First of all, I think we can have two API

Re: [HACKERS] check for interrupts in set_rtable_names

Jeff Janes writes: > On Fri, Nov 13, 2015 at 3:13 PM, Tom Lane wrote: >> There's probably no reason not to do that, but I'd be much more interested >> in eliminating the slowness to begin with ... > I was thinking about that as well, but I don't think

Re: [HACKERS] Parallel Seq Scan

On 16/11/15 12:05, Robert Haas wrote: On Fri, Nov 13, 2015 at 10:46 AM, Thom Brown wrote: And perhaps associated PIDs? Yeah, that can be useful, if others also feel like it is important, I can look into preparing a patch for the same. Thanks. Thom, what do you think the

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

On 11/15/15 9:53 AM, Andrew Dunstan wrote: > I suggest you review the original thread on this subject before a line > was ever written. "multiple" (see subject line on this whole thread) is > clearly what is being asked for. Making people turn that into a single > argument is not what was

Re: [HACKERS] psql: add \pset true/false

On 11/12/15 4:09 PM, Tom Lane wrote: > Peter Eisentraut writes: >> Plus we already have \pset numericlocale as a similar feature in psql. > > But \pset numericlocale is also a crock. It doesn't affect COPY output > for instance, and its ability to identify which data types it

Re: [HACKERS] pglogical_output - a general purpose logical decoding output plugin

On 16 November 2015 at 09:57, Peter Eisentraut wrote: > On 11/2/15 7:17 AM, Craig Ringer wrote: > > The output plugin is suitable for a number of uses. It's designed > > primarily to supply a data stream to drive a logical replication > > client running in another PostgreSQL

Re: [HACKERS] Minor comment improvement to create_foreignscan_plan

On 2015/11/12 19:02, Etsuro Fujita wrote: On 2015/11/10 3:53, Robert Haas wrote: On Mon, Nov 9, 2015 at 5:34 AM, Etsuro Fujita wrote: Here is a small patch to update an comment in create_foreignscan_plan; add fdw_recheck_quals to the list of expressions that need

Re: [HACKERS] Proposing COPY .. WITH PERMISSIVE

On Mon, Nov 16, 2015 at 11:05 AM, Peter Eisentraut wrote: > On 9/2/15 4:19 PM, Stefan Kaltenbrunner wrote: >> maybe - but having a fixed "default" is very different from baking a >> classic unix permission concept of user/group/world^others into actual >> DDL or into a COPY

Re: [HACKERS] Foreign join pushdown vs EvalPlanQual

On 2015/11/13 11:31, Kouhei Kaigai wrote: On 2015/11/12 2:53, Robert Haas wrote: From my point of view I'm now thinking this solution has two parts: (1) Let foreign scans have inner and outer subplans. For this purpose, we only need one, but it's no more work to enable both, so we may as

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

On Sun, Nov 15, 2015 at 11:41 PM, Simon Riggs wrote: > On 12 November 2015 at 18:25, Thomas Munro > wrote: > > >> I don't want to get bogged down in details, while we're talking about >> the 30,000 foot view). >> > > Hmm, if that's where

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

On 2015-11-15 16:24:24 -0500, Robert Haas wrote: > I think it needs to be adapted to use predefined constants for the > tranche IDs instead of hardcoded values, maybe based on the attached > tranche-constants.patch. Yea, that part is clearly not ok. Let me look at the patch. > Also, I think we

Re: [HACKERS] [PATCH] Skip ALTER x SET SCHEMA if the schema didn't change

On Thu, Nov 5, 2015 at 10:20 PM, Haribabu Kommi wrote: > On Tue, Sep 29, 2015 at 12:17 AM, Marti Raudsepp wrote: >> Hi list >> >> The attached patch changes the behavior of multiple ALTER x SET SCHEMA >> commands, to skip, rather than fail, when the old

Re: [HACKERS] [PATCH] SQL function to report log message

On 10/22/15 3:20 AM, dinesh kumar wrote: > + > + > + > pg_report_log(logleveltext, > message anyelement[, ishidestmt > boolean ] [, detail text] [, > hint text] [, sqlstate > text]) > + > + void > + > +Report message or error. > + > +

Re: [HACKERS] Parallel Seq Scan

On Fri, Nov 13, 2015 at 10:46 AM, Thom Brown wrote: >>> And perhaps associated PIDs? >> >> Yeah, that can be useful, if others also feel like it is important, I can >> look into preparing a patch for the same. > > Thanks. Thom, what do you think the EXPLAIN output should look

Re: [HACKERS] psql: add \pset true/false

On 11/15/15 3:20 PM, Jim Nasby wrote: > As to the argument about displaying a check or an X, why should that > capability only exist for boolean types? For example, why not allow psql > to convert a numeric value into a bar of varying sizes? I've frequently > emulated that with something like

Re: [HACKERS] psql: add \pset true/false

On Thu, Nov 12, 2015 at 1:09 PM, Tom Lane wrote: > Peter Eisentraut writes: >> Plus we already have \pset numericlocale as a similar feature in psql. > > But \pset numericlocale is also a crock. It doesn't affect COPY output > for instance, and its ability

Re: [HACKERS] pglogical_output - a general purpose logical decoding output plugin

On 11/2/15 7:17 AM, Craig Ringer wrote: > The output plugin is suitable for a number of uses. It's designed > primarily to supply a data stream to drive a logical replication > client running in another PostgreSQL instance, like the pglogical > client discussed at PGConf.EU 2015. So where is that

Re: [HACKERS] Proposing COPY .. WITH PERMISSIVE

On 9/2/15 4:19 PM, Stefan Kaltenbrunner wrote: > maybe - but having a fixed "default" is very different from baking a > classic unix permission concept of user/group/world^others into actual > DDL or into a COPY option. The proposed syntax might make some sense to > a admin used to a unix style

Re: [HACKERS] Parallel Seq Scan

On Sun, Nov 15, 2015 at 1:12 AM, Amit Kapila wrote: > Thanks for the report. > > I think main reason of the leak in workers seems to be due the reason > that one of the buffer used while sending tuples (in function > BuildRemapInfo) > from worker to master is not getting

Re: [HACKERS] [PATCH] SQL function to report log message

On 16 November 2015 at 09:50, Peter Eisentraut wrote: > > > I haven't seen this discussed before, but I don't find the name > pg_report_log particularly good. Why not jut pg_log? > > Sounds like a better name to me. 'report' is noise that adds nothing useful. I'd like to have

Re: [HACKERS] proposal: PL/Pythonu - function ereport

I don't think it's right to reuse SPIError for this. SPIError is clearly meant to signal an error in the SPI calls. Of course, we can't stop users from raising whatever exception they want, but if we're going to advertise that users can raise exceptions, then we should create separate exception

Re: [HACKERS] Making tab-complete.c easier to maintain

On Thu, Nov 12, 2015 at 5:16 PM, Kyotaro HORIGUCHI < horiguchi.kyot...@lab.ntt.co.jp> wrote: > Hello. How about regular expressions? > > I've been thinking of better mechanism for tab-compltion for > these days since I found some bugs in it. > > At Fri, 23 Oct 2015 14:50:58 -0300, Alvaro Herrera

Re: [HACKERS] pam auth - add rhost item

On 10/13/15 4:12 PM, kolo hhmow wrote: > Yes, sorry. I was in hurry when I posted this message. > I dont understand whay in CheckPAMAuth function only PAM_USER item is > adding to pam information before authenticate? > Wheter it would be a problem to set additional pam information like > PAM_RHOST

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

On 7/21/15 5:15 AM, Haribabu Kommi wrote: > With the output of this view, administrator can identify the lines > that are matching for the given > criteria easily without going through the file. How is this useful? I could see the use if you want to debug cases of user foo on host bar says they

Re: [HACKERS] Foreign join pushdown vs EvalPlanQual

On 2015/11/13 13:44, Kyotaro HORIGUCHI wrote: I wrote: What I think is, I see zero evidence that there is a good use-case for an FDW to do something other than doing an ExecProcNode in the callback routine, as I said below, so I don't see the need to add such a routine while that would cause

Re: [HACKERS] proposal: PL/Pythonu - function ereport

2015-11-16 5:20 GMT+01:00 Peter Eisentraut : > I don't think it's right to reuse SPIError for this. SPIError is > clearly meant to signal an error in the SPI calls. Of course, we can't > stop users from raising whatever exception they want, but if we're going > to advertise

Re: [HACKERS] [PATCH] SQL function to report log message

Hi, On Mon, Nov 16, 2015 at 2:50 AM, Peter Eisentraut wrote: > On 10/22/15 3:20 AM, dinesh kumar wrote: > > + > > + > > + > pg_report_log(logleveltext, > message anyelement[, ishidestmt > boolean ] [, detail text] [, > hint text] [, sqlstate > text]) > > +

Re: [HACKERS] Foreign join pushdown vs EvalPlanQual

> On 2015/11/13 13:44, Kyotaro HORIGUCHI wrote: > > I wrote: > >>> What I think is, I > >>> see zero evidence that there is a good use-case for an FDW to do > >>> something other than doing an ExecProcNode in the callback routine, as I > >>> said below, so I don't see the need to add such a

Re: [HACKERS] COPY (INSERT/UPDATE/DELETE .. RETURNING ..)

On Sun, Nov 1, 2015 at 2:49 AM, Marko Tiikkaja wrote: > Attached is a patch for being able to do $SUBJECT without a CTE. The > reasons this is better than a CTE version are: > > 1) It's not obvious why a CTE version works but a plain one doesn't > 2) This one has less overhead

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

On Mon, Nov 16, 2015 at 2:30 PM, Peter Eisentraut wrote: > On 7/21/15 5:15 AM, Haribabu Kommi wrote: >> With the output of this view, administrator can identify the lines >> that are matching for the given >> criteria easily without going through the file. > > How is this useful?

Re: [HACKERS] eXtensible Transaction Manager API

On Saturday, November 14, 2015 8:41 AM, Craig Ringer wrote: > On 13 November 2015 at 21:35, Michael Paquier > wrote: >> On Tue, Nov 10, 2015 at 3:46 AM, Robert Haas wrote: >>> If the database is corrupted, there's no