Hello,
At Fri, 09 Oct 2015 16:32:31 +0200, Tomas Vondra
wrote in <5617cfff.10...@2ndquadrant.com>
> Hello,
>
> On 10/09/2015 02:59 AM, Kyotaro HORIGUCHI wrote:
> >>> The cause of this seeming mismatch would be the place to hold
> >>> indexrinfos. It is determined only by baserestrictinfo and
>
On 14/10/15 18:19, Tom Lane wrote:
I wrote:
Michael Paquier writes:
On Mon, Oct 12, 2015 at 2:54 AM, Josh Berkus wrote:
I don't know that there's anything the PostgreSQL project can do about
it. If anyone on this list is connected with MITRE, please ask them
what they need to be more prompt.
On Tue, Oct 13, 2015 at 3:54 PM, Rajeev rastogi
wrote:
> On 12th October 2015 20:45, Rajeev Rastogi Wrote:
>
>
>
> >>> I observed one strange behavior today that if postmaster process gets
> crashed/killed, then it kill all background processes but not the client
> backend process.
>
>
>
> >> Thi
I wrote:
> Michael Paquier writes:
>> On Mon, Oct 12, 2015 at 2:54 AM, Josh Berkus wrote:
>>> I don't know that there's anything the PostgreSQL project can do about
>>> it. If anyone on this list is connected with MITRE, please ask them
>>> what they need to be more prompt.
>> http://cve.mitre.o
On Wed, Oct 14, 2015 at 3:02 AM, Masahiko Sawada wrote:
> On Sat, Oct 10, 2015 at 4:35 AM, Robert Haas wrote:
>> On Fri, Oct 9, 2015 at 12:00 AM, Amit Kapila wrote:
>>> Sounds like both the approaches have some pros and cons, also there are
>>> some people who prefer mini-language and others who pr
2015-10-13 23:28 GMT+02:00 David Rowley :
> On 4 September 2015 at 04:50, Robert Haas wrote:
>
>>
>> Also: very nice performance results.
>>
>>
> Thanks.
>
> On following a thread in [General] [1] it occurred to me that this patch
> can give a massive improvement on Merge joins where the mark and
On Wed, Oct 14, 2015 at 3:28 AM, Masahiko Sawada wrote:
> The draft patch of replication using priority is already implemented
> by Michael, so I need to implement simple quorum commit logic and
> merge them.
The last patch in date I know of is this one:
http://www.postgresql.org/message-id/CAB7nP
On Tue, Oct 13, 2015 at 8:57 PM, Tom Lane wrote:
>
> Michael Paquier writes:
> > On Tue, Oct 13, 2015 at 5:35 AM, Tom Lane wrote:
> >> After poking around a bit more, I propose the attached patch. I've
> >> checked that this is happy with an EXEC_BACKEND Unix build, but I'm not
> >> able to tes
> -Original Message-
> From: pgsql-hackers-ow...@postgresql.org
> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Etsuro Fujita
> Sent: Thursday, October 08, 2015 7:56 PM
> To: Kyotaro HORIGUCHI; robertmh...@gmail.com
> Cc: Kaigai Kouhei(海外 浩平); pgsql-hackers@postgresql.org;
> shig
On Tue, Oct 13, 2015 at 5:53 AM, David G. Johnston <
david.g.johns...@gmail.com> wrote:
>
>>> > Using this attribute, we can have more control on parallel operations
>>> like,
>>>
>>> > IF SKIPPED_ROW_COUNT =0 THEN
>>> > <>
>>> > ELSE
>>> > <>
>>> > END IF;
>>>
>>> Um ... so what? This is not a u
We've got a few open items remaining at
https://wiki.postgresql.org/wiki/PostgreSQL_9.5_Open_Items - we should
try to get rid of them. Of the 8 items there, 3 are documentation
issues. It looks to me like one of those is for Stephen to deal with,
one for Andres, and one for Alvaro. Is there any
On Tue, Oct 13, 2015 at 3:49 AM, Praveen M wrote:
> Hi All,
>
> I was able to follow the debugging of the child process using this link,
> https://wiki.postgresql.org/wiki/Working_with_Eclipse
>
> As per the notes , I was able to set breakpoints and everything seem to be
> working (hopefully). Ho
Hi,
At Fri, 9 Oct 2015 18:18:52 +0530, Jeevan Chalke
wrote in
> I have noticed that, this thread started saying we are getting a crash
> with the given steps with foreign_join_v16.patch, I am correct?
Your're correct. The immediate cause of the crash is an assertion
failure that EvalPlanQualN
On Mon, Oct 12, 2015 at 11:46:08AM -0400, Robert Haas wrote:
> plpgsql_param_fetch() assumes that it can detect whether it's being
> called from copyParamList() by checking whether params !=
> estate->paramLI. I don't know why this works, but I do know that this
It works because PL/pgSQL creates
On 10/14/2015 01:16 AM, Andres Freund wrote:
> On October 13, 2015 11:14:19 PM GMT+02:00, Alvaro Herrera
> wrote:
>> Amir Rohan wrote:
>>
>>> I've been considering that. Reusing the parser would ensure no errors
>>> are introduces by having a different implementation, but on the other
>>> hand in
On 10/14/2015 01:12 AM, Alvaro Herrera wrote:
> Amir Rohan wrote:
>> On 10/14/2015 12:14 AM, Alvaro Herrera wrote:
>>> Amir Rohan wrote:
>>>
I've been considering that. Reusing the parser would ensure no errors
are introduces by having a different implementation, but on the other
han
Alright, here's v3. As requested, it's one patch now. Other things
addressed herein include:
- postgres.h/assert.h ordering fix
- spacing around casts
- leaking of GSS buffer in be_gss_inplace_decrypt
- libpq-be.h not having a conditional internal include
- always exposing guc veriable gss_
On October 13, 2015 11:14:19 PM GMT+02:00, Alvaro Herrera
wrote:
>Amir Rohan wrote:
>
>> I've been considering that. Reusing the parser would ensure no errors
>> are introduces by having a different implementation, but on the other
>> hand involving the pg build in installation what's intended as
Amir Rohan wrote:
> On 10/14/2015 12:14 AM, Alvaro Herrera wrote:
> > Amir Rohan wrote:
> >
> >> I've been considering that. Reusing the parser would ensure no errors
> >> are introduces by having a different implementation, but on the other
> >> hand involving the pg build in installation what's
On 10/14/2015 12:14 AM, Alvaro Herrera wrote:
> Amir Rohan wrote:
>
>> I've been considering that. Reusing the parser would ensure no errors
>> are introduces by having a different implementation, but on the other
>> hand involving the pg build in installation what's intended as a
>> lightweight,
On Tue, Oct 13, 2015 at 2:45 AM, Amit Kapila wrote:
> Attached is rebased patch for partial seqscan support.
Review comments:
- If you're going to pgindent execParallel.c, you need to add some
entries to typedefs.list so it doesn't mangle the formatting.
ExecParallelEstimate's parameter list is
On 4 September 2015 at 04:50, Robert Haas wrote:
>
> Also: very nice performance results.
>
>
Thanks.
On following a thread in [General] [1] it occurred to me that this patch
can give a massive improvement on Merge joins where the mark and restore
causes an index scan to have to skip over many f
Amir Rohan wrote:
> I've been considering that. Reusing the parser would ensure no errors
> are introduces by having a different implementation, but on the other
> hand involving the pg build in installation what's intended as a
> lightweight, independent tool would hurt.
> Because it's dubious wh
On 10/13/2015 09:20 PM, Robert Haas wrote:
> On Mon, Oct 12, 2015 at 8:01 PM, Amir Rohan wrote:
>> That wasn't my intention. Perhaps I'm overreacting to a long-standing
>> "Tom Lane's bucket of cold water" tradition. I'm new here.
>> I understand your point and I was only reiterating what in parti
La lista de correo apropiada para tu consulta es pgsql-es-ayuda
(pgsql-es-ayuda(at)postgresql(dot)org).
Saludos,
El 13 de octubre de 2015, 16:51, Enrique Escobar
escribió:
> Hola
> Tengo una duda, que tan pesado es poner ssl en una base. (me refiero si es
> mas pesado para el equipo usar esta co
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 which is very useful because we can use this item
This patch is marked as Ready for Committer in the CommitFest
application. Here is my attempt to summarize the votes upthread:
Tom Lane: plpgsql RAISE is sufficient; we don't need this.
Pavel Stehule: could be replaced by custom function, but not against it.
Robert Haas: plpgsql RAISE is sufficie
Hola
Tengo una duda, que tan pesado es poner ssl en una base. (me refiero si
es mas pesado para el equipo usar esta conexión o es igual a una con ip
en hba?
Mil Gracias
--
Saludos Enrique
On Tue, Aug 18, 2015 at 12:08 PM, Alvaro Herrera
wrote:
> Robert Haas wrote:
>> On Sat, Aug 15, 2015 at 6:45 PM, Mark Johnston wrote:
>
>> > The bug is in src/backend/Makefile. probes.o, the dtrace(1)-generated
>> > object file, depends on the objfiles.txt for each of the backend
>> > subdirs. Th
On Sun, Oct 11, 2015 at 8:54 PM, Peter Geoghegan wrote:
> Attached documentation patch is intended to close-out the INSERT ...
> ON CONFLICT documentation items from the 9.5 open item list. I also
> attach a patch that makes a minor adjustment to an error message
> concerning deferred constraints;
On Tue, Oct 13, 2015 at 08:39:16AM -0700, Joshua Drake wrote:
> On 10/13/2015 08:15 AM, Tom Lane wrote:
> >Andres Freund writes:
> >>On 2015-10-13 16:21:54 +0200, �lvaro Hern�ndez Tortosa wrote:
> >>>(50 chars for the commit summary, 72 chars line wrapping)
> >
> >>-1 - imo 50 chars too often make
On Wed, Oct 14, 2015 at 3:16 AM, Josh Berkus wrote:
> On 10/13/2015 11:02 AM, Masahiko Sawada wrote:
>> I thought that this feature for postgresql should be simple at first
>> implementation.
>> It would be good even if there are some restriction such as the
>> nesting level, the group setting.
>>
On Mon, Oct 12, 2015 at 8:01 PM, Amir Rohan wrote:
> That wasn't my intention. Perhaps I'm overreacting to a long-standing
> "Tom Lane's bucket of cold water" tradition. I'm new here.
> I understand your point and I was only reiterating what in particular
> makes the conf checker distinctly useful
On 10/13/2015 11:02 AM, Masahiko Sawada wrote:
> I thought that this feature for postgresql should be simple at first
> implementation.
> It would be good even if there are some restriction such as the
> nesting level, the group setting.
> The another new approach that I came up with is,
> * Add ne
On Sat, Oct 10, 2015 at 4:35 AM, Robert Haas wrote:
> On Fri, Oct 9, 2015 at 12:00 AM, Amit Kapila wrote:
>> Sounds like both the approaches have some pros and cons, also there are
>> some people who prefer mini-language and others who prefer JSON. I think
>> one thing that might help, is to che
On 13 October 2015 at 11:48, Michal Novotny
wrote:
> Hi guys,
>
> I would like to ask you whether is there any tool to be able to compare
> database schemas ideally no matter what the column order is or to dump
> database table with ascending order of all database columns.
>
> For example, if I h
On Mon, Oct 12, 2015 at 12:01 PM, kolo hhmow wrote:
> Wheter it would be a problem to set additional item (rhost) before
> pam_authentication function in backend/libpq/auth.c?
> It is very useful because you can restrict access to given ip address like
> in mysql.
> And this actually utilized in p
On Tue, Oct 13, 2015 at 3:29 AM, Ashutosh Bapat
wrote:
>> - You consider pushing down ORDER BY if any prefix of the query
>> pathkeys satisfy is_foreign_expr(), but that doesn't seem right to me.
>> If the user says SELECT * FROM remotetab ORDER BY a, unsafe(a),
>> ordering the result set by a doe
Joshua D. Drake wrote:
> On 10/13/2015 08:15 AM, Tom Lane wrote:
> >Andres Freund writes:
> >>On 2015-10-13 16:21:54 +0200, �lvaro Hern�ndez Tortosa wrote:
> >>>(50 chars for the commit summary, 72 chars line wrapping)
> >
> >>-1 - imo 50 chars too often makes the commit summary too unspecific,
>
On 13/10/15 17:39, Joshua D. Drake wrote:
On 10/13/2015 08:15 AM, Tom Lane wrote:
Andres Freund writes:
On 2015-10-13 16:21:54 +0200, �lvaro Hern�ndez Tortosa wrote:
(50 chars for the commit summary, 72 chars line wrapping)
-1 - imo 50 chars too often makes the commit summary too unspecif
Hi guys,
I would like to ask you whether is there any tool to be able to compare
database schemas ideally no matter what the column order is or to dump
database table with ascending order of all database columns.
For example, if I have table (called table) in schema A and in schema B
(the time di
On 10/13/2015 08:15 AM, Tom Lane wrote:
Andres Freund writes:
On 2015-10-13 16:21:54 +0200, �lvaro Hern�ndez Tortosa wrote:
(50 chars for the commit summary, 72 chars line wrapping)
-1 - imo 50 chars too often makes the commit summary too unspecific,
requiring to read much more.
I agree -
Michael Paquier writes:
> On Tue, Oct 13, 2015 at 5:35 AM, Tom Lane wrote:
>> After poking around a bit more, I propose the attached patch. I've
>> checked that this is happy with an EXEC_BACKEND Unix build, but I'm not
>> able to test it on Windows ... would somebody do that?
> Looking at the
>>it's approach to this is to summarily kill anything that attempts DDL on a
>>table being repacked.
Why? I am confused with it. Could you please explain this?
Jinyu Zhang
thanks
At 2015-10-12 23:46:12, "Jim Nasby" wrote:
>On 10/11/15 6:55 AM, Jinyu wrote:
>> Are there other solutions to
Andres Freund writes:
> On 2015-10-13 16:21:54 +0200, Álvaro Hernández Tortosa wrote:
>> (50 chars for the commit summary, 72 chars line wrapping)
> -1 - imo 50 chars too often makes the commit summary too unspecific,
> requiring to read much more.
I agree --- I have a hard enough time writing a
On 13/10/15 16:24, Andres Freund wrote:
On 2015-10-13 16:21:54 +0200, Álvaro Hernández Tortosa wrote:
On 13/10/15 04:40, Tom Lane wrote:
I'm with Robert on the idea that commit log entries need to be
limited-width. I personally format them to 75 characters, so that
git_changelog's output is le
On 10/13/2015 10:21 AM, Álvaro Hernández Tortosa wrote:
On 13/10/15 04:40, Tom Lane wrote:
I'm with Robert on the idea that commit log entries need to be
limited-width. I personally format them to 75 characters, so that
git_changelog's output is less than 80 characters. regards, tom lane
On 2015-10-13 16:21:54 +0200, Álvaro Hernández Tortosa wrote:
>
> On 13/10/15 04:40, Tom Lane wrote:
> >I'm with Robert on the idea that commit log entries need to be
> >limited-width. I personally format them to 75 characters, so that
> >git_changelog's output is less than 80 characters. regards,
On 13/10/15 04:40, Tom Lane wrote:
I'm with Robert on the idea that commit log entries need to be
limited-width. I personally format them to 75 characters, so that
git_changelog's output is less than 80 characters. regards, tom lane
Little bit off-topic, but if precisely if we're trying
On Tue, Oct 13, 2015 at 4:07 PM, Andrew Dunstan wrote:
>
>
> On 10/12/2015 07:36 PM, Robert Haas wrote:
>
>> On Tue, Oct 6, 2015 at 2:33 PM, Nathan Wagner
>> wrote:
>>
>>> Two, I think any attempt to tell the developers and committers that they
>>> need to change their workflow to adapt to some
On 10/12/2015 07:36 PM, Robert Haas wrote:
On Tue, Oct 6, 2015 at 2:33 PM, Nathan Wagner wrote:
Two, I think any attempt to tell the developers and committers that they
need to change their workflow to adapt to some system is bound to fail,
so, I have asked, just what changed would you all be
Andrew Dunstan writes:
> On 10/12/2015 04:35 PM, Tom Lane wrote:
>> BTW, it appears from this that Cygwin builds have been broken right along
>> in a different way: according to the code in sysv_shmem's
>> PGSharedMemoryReAttach, Cygwin does cause a re-attach to occur, which we
>> were not undoing
On 10/12/2015 04:35 PM, Tom Lane wrote:
I wrote:
This is kind of a mess :-(. But it does look like what we want is
for SubPostmasterMain to do more than nothing when it chooses not to
reattach. Probably that should include resetting UsedShmemSegAddr to
NULL, as well as closing the handle.
A
On 10/12/2015 10:45 PM, Michael Paquier wrote:
On Tue, Oct 13, 2015 at 11:31 AM, Tom Lane wrote:
Hmm, well, why wasn't that back-patched? We expect these tests to run
on Windows don't we?
The message related to this particular commit is here:
http://www.postgresql.org/message-id/55b90161.509
Michael Paquier writes:
> On Tue, Oct 13, 2015 at 7:41 AM, Tom Lane wrote:
>> I'm not sure if this will completely fix our problems with "pg_ctl start"
>> related buildfarm failures on very slow critters. It does get rid of the
>> hard wired 5-second timeout, but the 60-second timeout could stil
>
>
>> > Using this attribute, we can have more control on parallel operations
>> like,
>>
>> > IF SKIPPED_ROW_COUNT =0 THEN
>> > <>
>> > ELSE
>> > <>
>> > END IF;
>>
>> Um ... so what? This is not a use-case.
>>
>>
> In my view, "How one can be sure that, he obtained all the tuples with
> SKIP LO
On 10/11/2015 03:20 AM, Peter Geoghegan wrote:
> On Thu, Sep 3, 2015 at 5:35 PM, David Rowley
> wrote:
>> My test cases are:
>
> Note that my text caching and unsigned integer comparison patches have
> moved the baseline down quite noticeably. I think that my mobile
> processor out-performs the X
On Tue, Oct 13, 2015 at 1:48 PM, Jeevan Chalke <
jeevan.cha...@enterprisedb.com> wrote:
>
> On Thu, Oct 8, 2015 at 9:39 PM, Robert Haas wrote:
>>
>>>
>>> In the interest of full disclosure, I asked Ashutosh to work on this
>>> patch and have discussed the design with him several times. I believe
Hi All,
I was able to follow the debugging of the child process using this link,
https://wiki.postgresql.org/wiki/Working_with_Eclipse
As per the notes , I was able to set breakpoints and everything seem to be
working (hopefully). However I am not able to see the debug messages in the
eclipse con
On 12th October 2015 20:45, Rajeev Rastogi Wrote:
>>> I observed one strange behavior today that if postmaster process gets
>>> crashed/killed, then it kill all background processes but not the client
>>> backend process.
>> This is a known behaviour and there was some discussion on this
>> top
> On Thu, Oct 8, 2015 at 9:39 PM, Robert Haas wrote:
>
>>
>> In the interest of full disclosure, I asked Ashutosh to work on this
>> patch and have discussed the design with him several times. I believe
>> that this is a good direction for PostgreSQL to be going. It's
>> trivially easy right now
On Tue, Oct 13, 2015 at 5:35 AM, Tom Lane wrote:
> I wrote:
>> This is kind of a mess :-(. But it does look like what we want is
>> for SubPostmasterMain to do more than nothing when it chooses not to
>> reattach. Probably that should include resetting UsedShmemSegAddr to
>> NULL, as well as clo
On Tue, Oct 13, 2015 at 5:53 PM, David Rowley
wrote:
> On 13 October 2015 at 17:09, Haribabu Kommi
> wrote:
>>
>> On Tue, Oct 13, 2015 at 12:14 PM, Robert Haas
>> wrote:
>> > Also, I think the path for parallel aggregation should probably be
>> > something like FinalizeAgg -> Gather -> PartialAg
On Thu, Oct 8, 2015 at 9:39 PM, Robert Haas wrote:
> On Tue, Oct 6, 2015 at 6:46 AM, Ashutosh Bapat
> wrote:
> > standard_qp_callback() sets root->query_pathkeys to pathkeys on which the
> > result of query_planner are expected be sorted upon (see the function for
> > more details). The patch ch
On 13 October 2015 at 02:14, Robert Haas wrote:
> On Sun, Oct 11, 2015 at 10:07 PM, Haribabu Kommi
> wrote:
> > Parallel aggregate is the feature doing the aggregation job parallel
> > with the help of Gather and
> > partial seq scan nodes. The following is the basic overview of the
> > parallel
65 matches
Mail list logo