On Wednesday, September 12, 2012 10:15 PM Fujii Masao
On Wed, Sep 12, 2012 at 8:54 PM, wrote:
>> The following bug has been logged on the website:
>>
>> Bug reference: 7534
>> Logged by: Amit Kapila
>> Email address: amit.kap...@huawei.com
>> PostgreSQL version: 9.2.0
>> Operat
Thanks!
Best regards,
Etsuro Fujita
> -Original Message-
> From: pgsql-hackers-ow...@postgresql.org
> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Kevin Grittner
> Sent: Thursday, September 13, 2012 12:40 PM
> To: fujita.ets...@lab.ntt.co.jp; pgsql-hackers@postgresql.org
> Sub
"Etsuro Fujita" wrote:
> This is a little patch to fix a typo in a comment.
Applied to HEAD and 9.2, which as far back as it went. I figured it
was easy and eliminated any back-patch issues for subsequent changes.
Thanks!
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postg
On Wed, 2012-09-12 at 17:20 +0300, Heikki Linnakangas wrote:
> On 12.09.2012 17:10, Peter Eisentraut wrote:
> > I was surprised to find that psql -f file.sql with a file such as this
> >
> > select 1;
> > select 2
> >
> > executes both commands even though the second one is not terminated.
> >
> >
On Wed, 2012-09-12 at 19:13 +0200, Magnus Hagander wrote:
> Just to be clear, what you're saying is we want to change the policy
> that says "committer must be on list of approved committers &&
> commiter==author" to "committer must be on list of approved committers
> && author must be on list of a
On Wed, Sep 12, 2012 at 07:19:06PM -0400, Tom Lane wrote:
> Sam Ross writes:
> > On Sat, Sep 1, 2012 at 8:47 PM, Tom Lane wrote:
> >> Do you want to try it and submit a patch for testing?
>
> > Thanks for the answer, and sorry for the slow reply - I'm not sure
> > I have the necessary expertise,
Sam Ross writes:
> On Sat, Sep 1, 2012 at 8:47 PM, Tom Lane wrote:
>> Do you want to try it and submit a patch for testing?
> Thanks for the answer, and sorry for the slow reply -
> I'm not sure I have the necessary expertise, but I'll be happy to give
> it a shot. Is there an already-assembled
On Sat, Sep 1, 2012 at 8:47 PM, Tom Lane wrote:
> [ sorry for slow response, but I'd not gotten time to think about this... ]
>
> Sam Ross writes:
>> I was wondering why it seems that the query planner can't "see", based
>> on the histograms, that two join-columns have a very small
>> intersectio
On Wed, Sep 12, 2012 at 4:08 PM, Noah Misch wrote:
> On Wed, Sep 12, 2012 at 06:44:37AM -0400, Gurjeet Singh wrote:
> > Thinking a bit more about the need for locks, I guess even the shared
> > variables whose read/write ops are considered atomic need to be protected
> > by locks so that the effe
On Wed, Sep 12, 2012 at 06:44:37AM -0400, Gurjeet Singh wrote:
> Thinking a bit more about the need for locks, I guess even the shared
> variables whose read/write ops are considered atomic need to be protected
> by locks so that the effects of NUMA architectures can be mitigated.
src/backend/stor
On Mon, Sep 10, 2012 at 04:23:00PM -0700, David E. Wheeler wrote:
> Well given that OSSP seems to be abandon ware (no activity since July
> 2008), it might be time to dump it in favor of something else.
Perhaps this would be a good time to bring up my uuid code again. I've
got a module for uuid s
Peter Eisentraut writes:
> I was surprised to find that psql -f file.sql with a file such as this
> select 1;
> select 2
> executes both commands even though the second one is not terminated.
> I realize that this is inconsistently handled throughout the system, for
> example libpq APIs don't ca
2012/9/12 Peter Eisentraut
> I was surprised to find that psql -f file.sql with a file such as this
>
> select 1;
> select 2
>
> executes both commands even though the second one is not terminated.
>
> I realize that this is inconsistently handled throughout the system, for
> example libpq APIs d
Magnus Hagander writes:
> Just to be clear, what you're saying is we want to change the policy
> that says "committer must be on list of approved committers &&
> commiter==author" to "committer must be on list of approved committers
> && author must be on list of approved committers"?
Works for m
Louis-David Mitterrand writes:
> See test case at: http://titus.apartia.fr/stuff/pg_92_error_sql.txt
> Works fine on 9.1
Thanks for the example. Looks like in commit
1bc16a946008a7cbb33a9a06a7c6765a807d7f59 I overlooked the need to
twiddle the logic that computes the starting-point targetlist fo
On Wed, Sep 12, 2012 at 4:21 PM, Peter Eisentraut wrote:
> A while ago I wanted to cherry-pick a patch from master to a back-branch
> that was initially committed by someone else. That was rejected because
> our git server requires author==committer. I don't think that
> restriction is particula
It looks like commit 09ff76fcdb275769ac4d1a45a67416735613d04b that
changed the name of pg_constraint.conisonly to connoinherit neglected to
change the System Catalog docs :-(
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscript
On 09/12/2012 07:36 AM, Louis-David Mitterrand wrote:
See test case at: http://titus.apartia.fr/stuff/pg_92_error_sql.txt
Works fine on 9.1
I cannot absolutely say it is a bug as I haven't yet reviewed the
relevant release notes but I can confirm that I also see your test-case
working on 9.1
Excerpts from Peter Eisentraut's message of mié sep 12 11:21:36 -0300 2012:
> A while ago I wanted to cherry-pick a patch from master to a back-branch
> that was initially committed by someone else. That was rejected because
> our git server requires author==committer. I don't think that
> restri
See test case at: http://titus.apartia.fr/stuff/pg_92_error_sql.txt
Works fine on 9.1
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
A while ago I wanted to cherry-pick a patch from master to a back-branch
that was initially committed by someone else. That was rejected because
our git server requires author==committer. I don't think that
restriction is particularly useful and should be lifted. I'm not saying
we should let any
I was surprised to find that psql -f file.sql with a file such as this
select 1;
select 2
executes both commands even though the second one is not terminated.
I realize that this is inconsistently handled throughout the system, for
example libpq APIs don't care about the missing semicolon, but
i
On Wed, Sep 12, 2012 at 10:06:15AM -0400, Peter Eisentraut wrote:
> On Wed, 2012-09-12 at 10:00 -0400, Bruce Momjian wrote:
> > Magnus, are you saying we don't backpatch wording improvements, but we
> > do backpatch spelling corrections?
>
> You could argue that a spelling correction is a bug fix
On Wed, 2012-09-12 at 10:00 -0400, Bruce Momjian wrote:
> Magnus, are you saying we don't backpatch wording improvements, but we
> do backpatch spelling corrections?
You could argue that a spelling correction is a bug fix but a wording
improvement is a new feature. (Unless the old wording is wild
On Wed, Sep 12, 2012 at 02:23:50PM +0200, Magnus Hagander wrote:
>
> On Sep 12, 2012 2:00 PM, "Kevin Grittner" wrote:
> >
> > Magnus Hagander wrote:
> > > "Kevin Grittner" wrote:
> > > Dan Scott wrote:
> > >>> I ran across a minor typo while reviewing the full-text search
> > >>> documentation.
Magnus Hagander wrote:
"Kevin Grittner" wrote:
> I'd back patch it in the docs. It's docs that people are going to
> be referring to for years to come.. And the effort is close to zero
> to back patch it. If it was more complex, I'd think twice about it.
OK, done. Back-patched to 9.1 where t
On Sep 12, 2012 2:00 PM, "Kevin Grittner"
wrote:
>
> Magnus Hagander wrote:
> > "Kevin Grittner" wrote:
> > Dan Scott wrote:
> >>> I ran across a minor typo while reviewing the full-text search
> >>> documentation. Attached is a patch to address the one usage of
> >>> "lexems" in a sea of "lexem
Magnus Hagander wrote:
> "Kevin Grittner" wrote:
> Dan Scott wrote:
>>> I ran across a minor typo while reviewing the full-text search
>>> documentation. Attached is a patch to address the one usage of
>>> "lexems" in a sea of "lexemes".
>>
>> Applied to HEAD.
>>
> No back patch? Seems like a bug
On Friday, September 07, 2012 8:24 PM Amit Kapila wrote:
On Thursday, September 06, 2012 9:58 PM Josh Berkus wrote:
On 9/6/12 7:06 AM, Amit Kapila wrote:
>>> 1.Set up postgresql-9.2beta2 on all hosts.
>> Did you retest this with 9.2rc1? Beta2 was a while ago
> Tested in 9.2rc1, th
On Tue, Sep 11, 2012 at 11:19 PM, Amit Kapila wrote:
> On Wednesday, September 12, 2012 5:33 AM Gurjeet Singh wrote:
>
> ** **
>
> ** **
>
> > This comment in UpdateFullPageWrites() seems to be inaccurate:
>
> > * It's safe to check the shared full_page_writes without the lock,
> >* b
Hello
I try to identify of our slow queries - we have lot of queries like
select count(*) from a,b where a.a = b.b;
our servers has usually enough memory (we do OLAP) - we use some
pooling for limiting memory expensive queries - and I found so
hashjoin based queries are significantly slower tha
On Sep 12, 2012 2:52 AM, "Kevin Grittner"
wrote:
>
> Dan Scott wrote:
> > I ran across a minor typo while reviewing the full-text search
> > documentation. Attached is a patch to address the one usage of
> > "lexems" in a sea of "lexemes".
>
> Applied to HEAD.
>
No back patch? Seems like a bugfix
This is a little patch to fix a typo in a comment.
Best regards,
Etsuro Fujit
commentfix.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
33 matches
Mail list logo
