Hi.
We're into the last full week of this CommitFest. Here's an update on
the current state of the queue.
Needs review: 31
Waiting on author: 18
Ready for committer:13
Committed: 19
(I'll send separate topic-wise updates too.)
Reviewers, please tr
Hi,
Here's a table I have
postgres=# \d+ tab1
Table "public.tab1"
Column | Type | Modifiers | Storage | Stats target | Description
+-+---+-+--+-
val| integer | | plain | |
val2 | in
On 2014-07-07 12:50:17 +0900, Fujii Masao wrote:
> On Sun, Jul 6, 2014 at 2:41 AM, Christoph Moench-Tegeder
> wrote:
> > Hi,
> >
> > while reading the logical decoding docs, I came across a duplicated
> > paragraph in doc/src/sgml/logicaldecoding.sgml - in the current
> > master branch, lines 108
On 2014-07-07 04:20:12 +, Rajeev rastogi wrote:
>
> On 04 July 2014 19:29, MauMau Wrote:
>
> > [How to fix]
> > Of course, adding "-o '-c synchronous_commit=local'" or "-o '-c
> > synchronous_standby_names='" to pg_ctl start in the recovery script
> > would prevent the problem.
> >
> > But i
On 04 July 2014 19:29, MauMau Wrote:
> [How to fix]
> Of course, adding "-o '-c synchronous_commit=local'" or "-o '-c
> synchronous_standby_names='" to pg_ctl start in the recovery script
> would prevent the problem.
>
> But isn't there anything to fix in PostgreSQL? I think the doc needs
> imp
On Wed, 2014-04-16 at 12:50 +0100, Nicholas White wrote:
> Thanks for the detailed feedback, I'm sorry it took so long to
> incorporate it. I've attached the latest version of the patch, fixing
> in particular:
I took a good look at this today.
* It fails for offset of 0 with IGNORE NULLS. Fixed
On Sun, Jul 6, 2014 at 2:41 AM, Christoph Moench-Tegeder
wrote:
> Hi,
>
> while reading the logical decoding docs, I came across a duplicated
> paragraph in doc/src/sgml/logicaldecoding.sgml - in the current
> master branch, lines 108 to 115 are the same as lines 117 to 124.
> I've attached a patc
On Sun, Jul 6, 2014 at 1:57 PM, Christoph Berg wrote:
> Re: Amit Kapila 2014-07-06
> > Another could be that during initdb all the uncommented settings be
> > written to postgresql.auto.conf file rather than to postgresql.conf.
> > I think we can do this by changing code in initdb.c->setup_config
On Sun, Jul 6, 2014 at 8:40 AM, Sergey Muraviov
wrote:
> Is there anyone who can commit the patch?
So what I'm inclined to do here (sigh) is commit it into 9.5 and
revert it in 9.4. I think it's an improvement but I there's enough
confusion and surprise about the changes from people who weren't
e
On Thu, Jul 3, 2014 at 9:03 AM, Fujii Masao wrote:
> On Thu, Jul 3, 2014 at 4:26 AM, Andres Freund wrote:
>> Hi,
>> Fujii noticed that I'd used
>> \echo Use "CREATE EXTENSION pg_buffercache" to load this file. \quit
>> in an extension upgrade script. That's obviously wrong, because it
>> should s
> "Tom" == Tom Lane writes:
>> I've experimented with the attached patch, which detects when this
>> situation might have occurred and does another pass to try and
>> build ordered scans without the SAOP condition. However, the
>> results may not be quite ideal, because at least in some t
I recently upgraded my machine from PostgreSQL8.3 to PostgreSQL9.3.4. After
upgrade, when I ran TPC-H queries for performance testing, I could see
drastic change in timings. Especially TPC-H query 5 which was taking 4
minutes to execute in pgsql8.3, took just 15 seconds in postgresql9.3.4. I
think
On 2014-07-06 15:02:21 -0400, Robert Haas wrote:
> On Tue, Jul 1, 2014 at 12:22 PM, Robert Haas wrote:
> >>> Since we have a Sun Studio machine in the buildfarm, we shouldn't give
> >>> up on SPARC completely, but maybe we should only add the cases for
> >>> sparcv8+ and above? That at least has
On Tue, Jul 1, 2014 at 12:22 PM, Robert Haas wrote:
>>> Since we have a Sun Studio machine in the buildfarm, we shouldn't give
>>> up on SPARC completely, but maybe we should only add the cases for
>>> sparcv8+ and above? That at least has some chance of getting tested.
>>
>> That we have code fo
"EXPLAIN (format XML) " command in PostgreSQL9.3.4 gives the plan
chosen by the optimizer in XML format. In my program, I have to extract
certain data about optimizer plan from this XML output.
I am using *LibXML2* library for parsing the XML. I had successfully
extracted information about w
On Fri, Jun 20, 2014 at 7:17 PM, Jeevan Chalke
wrote:
> Hi Sawada Masahiko,
>
> I liked this feature. So I have reviewed it.
>
> Changes are straight forward and looks perfect.
> No issues found with make/make install/initdb/regression.
>
> However I would suggest removing un-necessary braces at i
Hi,
On 2014-07-06 14:01:11 +, Andres Freund wrote:
> Fix decoding of MULTI_INSERTs when rows other than the last are toasted.
>
> When decoding the results of a HEAP2_MULTI_INSERT (currently only
> generated by COPY FROM) toast columns for all but the last tuple
> weren't replaced by their ac
On 6.7.2014 17:57, Stephen Frost wrote:
> Tomas,
>
> * Tomas Vondra (t...@fuzzy.cz) wrote:
>> I can't find the thread / test cases in the archives. I've found this
>> thread in hackers:
>>
>> http://www.postgresql.org/message-id/caoezvif-r-ilf966weipk5by-khzvloqpwqurpak3p5fyw-...@mail.gmail.com
>>
Andrew Gierth writes:
> commit 807a40c5 fixed a bug in handling of (new in 9.2) functionality
> of ScalarArrayOpExpr in btree index quals, forcing the results of
> scans including such a qual to be treated as unordered (because the
> order can in fact be wrong).
> However, this kills any chance of
David Rowley writes:
> On 6 July 2014 03:20, Tom Lane wrote:
>> Just to note that I've started looking at this, and I've detected a rather
>> significant omission: there's no check that the join operator has anything
>> to do with the subquery's grouping operator.
> hmm, good point. If I underst
Tomas,
* Tomas Vondra (t...@fuzzy.cz) wrote:
> I can't find the thread / test cases in the archives. I've found this
> thread in hackers:
>
> http://www.postgresql.org/message-id/caoezvif-r-ilf966weipk5by-khzvloqpwqurpak3p5fyw-...@mail.gmail.com
>
> Can you point me to the right one, please?
Th
Thank you for looking at it.
> In inet_his_inclusion_selec function,
> When the constant matches only the right side of the bucket, and if it’s a
> last bucket then it's never considered as partial match candidate.
> In my opinion, if it's not a last bucket then for next bucket it will become
>
On 6.7.2014 06:47, Stephen Frost wrote:
> * Greg Stark (st...@mit.edu) wrote:
>> Last time was we wanted to use bloom filters in hash joins to
>> filter out tuples that won't match any of the future hash batches
>> to reduce the amount of tuples that need to be spilled to disk.
>> However the probl
Hi Steve,
On 2014-06-30 11:40:50 -0400, Steve Singer wrote:
> In 9.4 we've the below block of code to walsender.c as
>
> /*
> * We only send regular messages to the client for full decoded
> * transactions, but a synchronous replication and walsender shutdown
> * possibly are waiting for a la
Re: Amit Kapila 2014-07-06
> Another could be that during initdb all the uncommented settings be
> written to postgresql.auto.conf file rather than to postgresql.conf.
> I think we can do this by changing code in initdb.c->setup_config().
> This will ensure that unless user is changing settings i
Hi all
After someone reported somewhat less than informative errors in bytea
decoding (http://stackoverflow.com/q/24588866/398670) I thought I'd put
together a quick patch to improve the errors here.
Please merge.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Develo
Hi.
Is there anyone who can commit the patch?
2014-06-25 20:17 GMT+04:00 Pavel Stehule :
>
>
>
> 2014-06-24 19:45 GMT+02:00 Sergey Muraviov :
>
> Hi.
>>
>> Is there any problem with the patch?
>>
>
> I tested it and I had not any issue with last version
>
> So, please, commit it
>
> Regards
>
27 matches
Mail list logo
