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? I could see the
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 (I measured a ~
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
> 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 routin
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])
> > +
> > + void
>
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 that users can raise
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 may
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 c
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 c
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
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 this functionality.
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 and new schema is
>> the same.
>>
>> The ad
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 wel
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 option. The proposed s
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 the
replace_nestloop_params pr
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 instance, like the pg
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 freed and it is allocated
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 sy
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
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.
> +
> +
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 to identify which data types it should
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 SELEC
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 should apply
> to i
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 envisaged
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 sh
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 that would be
> back-patchable, at least not
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 EXPLAIN output should
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 like,
specifically?
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 we're at, I'll summarize my thoughts.
>
> All of this dis
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 calls, something like:
>
> 1) LWL
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 apply
to is really
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 transactio
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 way to guarantee that
>>> anything works as planned. This is like saying th
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 file which was then invok
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 that's a pretty common pat
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 seems to me the motivat
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 patch, it presents the advantage to be
>> able to track the same queries easi
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 distributing/load balancing
queries so that
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 = Max(local_rscale, NUMERIC_MIN_D
39 matches
Mail list logo
