On Sat, Apr 4, 2015 at 6:21 AM, Tom Lane wrote:
> I wrote:
>> Peter Eisentraut writes:
>>> These warnings also happen with older versions of clang. Now idea how
>>> to fix yet. I'm thinking that clang should be fixed, because these
>>> warnings are stupid.
>
>> Yeah, they're utterly stupid; who
> "Tom" == Tom Lane writes:
>> For those following along at home, the failures are on these queries:
>> SELECT 1.1 AS two UNION SELECT 2.2;
>> SELECT 1.1 AS two UNION SELECT 2;
>> SELECT 1 AS two UNION SELECT 2.2;
>> SELECT 1.1 AS three UNION SELECT 2 UNION ALL SELECT 2;
>> In each ca
Hi
2015-03-31 14:38 GMT+02:00 Haribabu Kommi :
> On Mon, Mar 30, 2015 at 4:34 AM, Pavel Stehule
> wrote:
> > Hi
> >
> > I checked this patch. I like the functionality and behave.
>
> Thanks for the review.
>
> Here I attached updated patch with the following changes.
>
> 1. Addition of two new k
Robert Haas writes:
> For those following along at home, the failures are on these queries:
> SELECT 1.1 AS two UNION SELECT 2.2;
> SELECT 1.1 AS two UNION SELECT 2;
> SELECT 1 AS two UNION SELECT 2.2;
> SELECT 1.1 AS three UNION SELECT 2 UNION ALL SELECT 2;
> In each case, the expected result i
On Fri, Apr 3, 2015 at 3:46 PM, Andrew Gierth
wrote:
> (This does rather suggest to me that some better regression tests for
> sorting would be a good idea, possibly even including on-disk sorts.)
Yeah. I've been unpleasantly surprised by how easy it is to pass the
regression tests with sorting
On Fri, Apr 3, 2015 at 5:45 PM, Tom Lane wrote:
> ... btw, has anyone noticed that this patch broke hamerkop and
> bowerbird? Or at least, it's hard to see what other recent commit
> would explain the failures they're showing.
I noticed the failure on bowerbird today and I agree that looks an
aw
The symptom is that the same join query yield different results with
MJ and NLJ/HJ. Here is a repro:
---
create table t1(a int);create table t2(b int);
insert into t1 values(10); insert into t2 values(2);
analyze t1; analyze t2;
set enable_mergejoin=on; set enable_nestloop=off; set enable_hashjoi
On Thu, Apr 02, 2015 at 07:31:52AM -0400, Bruce Momjian wrote:
> On Thu, Apr 2, 2015 at 01:44:59AM -0400, Noah Misch wrote:
> > On Wed, Apr 01, 2015 at 10:49:01PM -0400, Bruce Momjian wrote:
> > > On Sat, Jan 10, 2015 at 02:53:13PM -0500, Tom Lane wrote:
> > > > While looking at fe-auth.c I notice
I have confirmed that "-Wno-unused-command-line-argument"
suppresses the "-pthread" warning for clang 6.0 and does not
trigger a warning in gcc 4.9.
Works for me!
John
On Fri, Apr 3, 2015 at 5:21 PM, Tom Lane wrote:
> I wrote:
> > Peter Eisentraut writes:
> >> These warnings also happen with
... btw, has anyone noticed that this patch broke hamerkop and
bowerbird? Or at least, it's hard to see what other recent commit
would explain the failures they're showing.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make c
On Fri, Apr 3, 2015 at 9:57 PM, Fujii Masao wrote:
> On Fri, Apr 3, 2015 at 8:37 PM, Michael Paquier
> wrote:
>> On Fri, Apr 3, 2015 at 6:35 PM, Fujii Masao wrote:
>>> Regarding the second patch, you added the checks of the return value of
>>> XLogReaderAllocate(). But it seems half-baked. XLogRe
On Fri, Apr 3, 2015 at 11:59 PM, Alvaro Herrera
wrote:
> Michael Paquier wrote:
>> On Fri, Apr 3, 2015 at 3:26 PM, Michael Paquier wrote:
>> > [...]
>> > Fine for me.
>>
>> And here are the correct patches. Sorry for that.
>
> Thanks, pushed. I added one extra comment to the SIGHUP patch in the
>
I wrote:
> Peter Eisentraut writes:
>> These warnings also happen with older versions of clang. Now idea how
>> to fix yet. I'm thinking that clang should be fixed, because these
>> warnings are stupid.
> Yeah, they're utterly stupid; whoever put them in obviously doesn't
> have a clue about ty
Peter Eisentraut writes:
> On 4/3/15 4:02 PM, John Gorman wrote:
>> I am getting compile warnings on OSX 10.10 from clang 6.0:
>>
>> clang: warning: argument unused during compilation: '-pthread'
>>
>> The 5 warnings are where we are making a -dynamiclib and
>> the -pthread argument is not neces
Petr Jelinek writes:
> my compiler complains about unused variable nblkno in _hash_splitbucket
> in no-assert build. It looks like relic of commit ed9cc2b5d which
> removed the only use of that variable besides the Assert.
Fixed, thanks!
regards, tom lane
--
Sent via
On 4/3/15 4:02 PM, John Gorman wrote:
> I am getting compile warnings on OSX 10.10 from clang 6.0:
>
> clang: warning: argument unused during compilation: '-pthread'
>
> The 5 warnings are where we are making a -dynamiclib and
> the -pthread argument is not necessary:
>
> ./src/interfaces/libpq/
Hi All
I am getting compile warnings on OSX 10.10 from clang 6.0:
clang: warning: argument unused during compilation: '-pthread'
The 5 warnings are where we are making a -dynamiclib and
the -pthread argument is not necessary:
./src/interfaces/libpq/
./src/interfaces/ecpg/pgtypeslib/
./src/inter
> "Robert" == Robert Haas writes:
>> It already does; it changes how int64 values are expected to be
>> stored in Datum variables. _Everything_ that currently stores an
>> int64 value in a Datum is affected.
Robert> But this isn't a value of the SQL type "int64". It's just a
Robert> bi
I wrote:
> FWIW, I think it's sensible to define NumericAbbrevGetDatum and the
> converse, but I'd suggest you just do it like
> #define NumericAbbrevGetDatum(X) Int64GetDatum(X)
> or
> #define NumericAbbrevGetDatum(X) Int32GetDatum(X)
Oh, scratch that, I'd failed to look at the upthread messages.
Robert Haas writes:
> On Fri, Apr 3, 2015 at 1:39 PM, Andrew Gierth
> wrote:
>> If you're determined to go this route - over my protest - then you need
>> to do something like define a NumericAbbrevGetDatum(x) macro and use it
>> in place of the Int64GetDatum / Int32GetDatum ones for both NAN and
On Fri, Apr 3, 2015 at 1:39 PM, Andrew Gierth
wrote:
> It already does; it changes how int64 values are expected to be stored
> in Datum variables. _Everything_ that currently stores an int64 value in
> a Datum is affected.
But this isn't a value of the SQL type "int64". It's just a bit
pattern
> "Robert" == Robert Haas writes:
>> I don't consider it appropriate to override ./configure in this way.
Robert> I don't see how that's overriding configure. Commit
Robert> 8472bf7a73487b0535c95e299773b882f7523463, which introduced
Robert> --disable-float8-byval in 2008, states that th
Abhijit Menon-Sen wrote:
> At 2015-01-15 14:32:45 +0100, and...@2ndquadrant.com wrote:
> Patch attached.
>
> Changes:
>
> 1. Renamed perform_fsync to fsync_recursively (otherwise it would read
>"fsync_pgdata(pg_data)")
Okay, but as far as I can tell this function is very specific to
PGDATA;
At 2015-03-31 22:43:49 +0530, a...@2ndquadrant.com wrote:
>
> I'm just posting this WIP patch where I've renamed fastbloat to
> pgstatbloat as suggested by Tomas, and added in the documentation, and
> so on.
Here's the revised version that also adds the count of RECENTLY_DEAD and
INSERT/DELETE_IN_
Michael Paquier wrote:
> On Fri, Apr 3, 2015 at 3:26 PM, Michael Paquier wrote:
> > [...]
> > Fine for me.
>
> And here are the correct patches. Sorry for that.
Thanks, pushed. I added one extra comment to the SIGHUP patch in the
place where you previously had the exit.
--
Álvaro Herrera
Amit Langote writes:
> Attached does:
> -/* Open rel if needed; we already have required locks */
> +/* Open rel if needed; we already have acquired locks */
> Does that make sense?
No, not particularly. It could be made to say "the locks we require"
but I don't find anything wrong with
On Fri, Apr 3, 2015 at 9:06 AM, Andrew Gierth
wrote:
>> "Robert" == Robert Haas writes:
> >> No, that's wrong; it must use USE_FLOAT8_BYVAL since that's what the
> >> definitions of Int64GetDatum / DatumGetInt64 are conditional on. As
> >> you have it now, it'll break if you build with
>
> The simple workaround for this was adding a fallback to GEE when f[1] or
f[2] is 0. GEE is another estimator described in the paper, behaving much
better in those cases.
For completeness, what's the downside in just always using GEE?
> "Robert" == Robert Haas writes:
>> No, that's wrong; it must use USE_FLOAT8_BYVAL since that's what the
>> definitions of Int64GetDatum / DatumGetInt64 are conditional on. As
>> you have it now, it'll break if you build with
>> --disable-float8-byval on a 64bit platform.
Robert> I'd p
On Fri, Apr 3, 2015 at 1:49 PM, Robert Haas wrote:
> Committed. For future reference, I'd prefer to have things like this
> added to the next CF rather than no CF at all.
I'll bear that in mind. Thanks.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org
On Thu, Apr 2, 2015 at 10:41 PM, Andrew Gierth
wrote:
> Robert> - Changed some definitions to depend on SIZEOF_DATUM rather
> Robert> than USE_FLOAT8_BYVAL. Hopefully I didn't muff this; please
> Robert> check it.
>
> No, that's wrong; it must use USE_FLOAT8_BYVAL since that's what the
> defin
On 4/3/15 3:59 AM, Sawada Masahiko wrote:
> On Thu, Apr 2, 2015 at 2:46 AM, David Steele wrote:
>> Let me know if you see any other issues.
>>
>
> I pulled HEAD, and then tried to compile source code after applied
> following "deparsing utility command patch" without #0001 and #0002.
> (because t
On Fri, Apr 3, 2015 at 8:37 PM, Michael Paquier
wrote:
> On Fri, Apr 3, 2015 at 6:35 PM, Fujii Masao wrote:
>> Regarding the second patch, you added the checks of the return value of
>> XLogReaderAllocate(). But it seems half-baked. XLogReaderAllocate() still
>> uses palloc(), but don't we need to
On Mon, Feb 23, 2015 at 7:44 PM, Peter Geoghegan wrote:
> On Mon, Feb 23, 2015 at 4:41 PM, Tomas Vondra
> wrote:
>> Are you going to add this into the CF? Would be nice to get this into
>> 9.5. Strictly speaking it should go to 2015-06 I guess, but I'd consider
>> it part of one of the existing s
On Thu, Mar 12, 2015 at 8:43 PM, Stas Kelvich
wrote:
> Documentation along with style fix.
>
Since we change the interface of extension we have to change it version and
create a migration script.
E.g. you have to rename cube--1.0.sql to cube--1.1.sql and create
cube--1.0--1.1.sql to migrate the
On Fri, Apr 3, 2015 at 1:17 PM, Stephen Frost wrote:
>> but even I'm not willing to
>> expend the amount of ink and emotional energy you have on whether a
>> variable that holds +1, 0, or -1 ought to be declared as "int" or
>> "int32". Does it matter? Yeah. Is it worth this much argument? No.
* Robert Haas (robertmh...@gmail.com) wrote:
> I'm about as much
> of a stickler for the details as you will find on this mailing list,
> or possibly, in the observable universe,
This made me laugh. :)
> but even I'm not willing to
> expend the amount of ink and emotional energy you have on wheth
On Fri, Apr 3, 2015 at 1:07 PM, Robert Haas wrote:
> I'm about as much
> of a stickler for the details as you will find on this mailing list,
> or possibly, in the observable universe, but even I'm not willing to
> expend the amount of ink and emotional energy you have on whether a
> variable that
On Thu, Apr 2, 2015 at 7:02 PM, Peter Geoghegan wrote:
> On Thu, Apr 2, 2015 at 11:21 PM, Robert Haas wrote:
>>> The changes that Andrew
>>> took issue with are utterly insignificant.
>>
>> Great. Then you will be utterly indifferent to which version gets committed.
>
> *shrug*
>
> You were the
Peter Eisentraut writes:
> On 4/2/15 4:32 AM, Jan Urbański wrote:
>>
>> Peter Eisentraut writes:
>>> I don't think this patch would actually fix the problem that was
>>> described after the original bug report
>>> (http://www.postgresql.org/message-id/5436991b.5020...@vmware.com),
>>> namely that
On 2015/03/13 0:50, Tom Lane wrote:
I think the real fix as far as postgres_fdw is concerned is in fact
to let it adopt a different ROW_MARK strategy, since it has meaningful
ctid values. However, that is not a one-size-fits-all answer.
The tableoid problem can be fixed much less invasively a
On Fri, Apr 3, 2015 at 6:35 PM, Fujii Masao wrote:
> Regarding the second patch, you added the checks of the return value of
> XLogReaderAllocate(). But it seems half-baked. XLogReaderAllocate() still
> uses palloc(), but don't we need to replace it with palloc_extended(), too?
Doh, you are right.
On 2015/03/25 4:56, Tom Lane wrote:
> Etsuro Fujita writes:
>> Let me explain further. Here is the comment in ExecOpenScanRelation:
>
>>* Determine the lock type we need. First, scan to see if target
>> relation
>>* is a result relation. If not, check if it's a FOR UPDATE/FOR S
On Fri, Apr 3, 2015 at 2:30 PM, Michael Paquier
wrote:
> On Fri, Apr 3, 2015 at 12:56 PM, Fujii Masao wrote:
>> The first patch looks good to me basically. But I have one comment:
>> shouldn't we expose pg_malloc_extended as a global function like
>> we did pg_malloc? Some frontends might need to
On Thu, Apr 2, 2015 at 2:46 AM, David Steele wrote:
> Hi Sawada,
>
> On 3/25/15 9:24 AM, David Steele wrote:
>> On 3/25/15 7:46 AM, Sawada Masahiko wrote:
>>> 2.
>>> I got ERROR when executing function uses cursor.
>>>
>>> 1) create empty table (hoge table)
>>> 2) create test function as follows.
On 03-04-2015 PM 03:58, Amit Langote wrote:
> Index childRTindex;
> AppendRelInfo *appinfo;
>
> -/* Open rel if needed; we already have required locks */
> +/* Open rel if needed; we already have acquired locks */
> if (childOID != parentOID)
> newrelation = h
46 matches
Mail list logo
