Hello, Josh.
You wrote:
JB> Hackers,
JB> The call is now open for Google Summer of Code.
JB> If you are interested in being a GSoC mentor this summer, please reply
JB> to this email. I want to gauge whether or not we should participate
JB> this summer.
JB> --
JB> Josh Berkus
JB> PostgreSQL E
Hello, sorry for long absense.
As far as I see, on an out-of-memory in getAnotherTuple() makes
conn->result->resultStatus = PGRES_FATAL_ERROR and
qpParseInputp[23]() skips succeeding 'D' messages consequently.
When exception raised within row processor, pg_conn->inCursor
always positioned in cons
-Original Message-
From: pgsql-hackers-ow...@postgresql.org
[mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Gaetano Mendola
Sent: Wednesday, February 15, 2012 2:54 PM
To: Peter Geoghegan; pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] CUDA Sorting
On 15/02/2012 23:11, Peter
On 15 February 2012 22:54, Gaetano Mendola wrote:
> That sounds a bit harsh. I'm one of those indeed, I haven't look in the
> details not having enough time for it. At work we do GPU computing (not
> the sort type stuff) and given the fact I'm a Postgres enthusiast I
> asked my self: "my server is
On 15 February 2012 15:27, Robert Haas wrote:
>> I am inclined to agree that given that we already use Perl to generate
>> source code like this, it seems natural that we should prefer to do
>> that, if only to avoid paranoia about the inclusion of a dial-a-bloat
>> knob. I am at a disadvantage he
On 15/02/2012 23:11, Peter Geoghegan wrote:
On 15 February 2012 20:00, Gaetano Mendola wrote:
On 13/02/2012 19:48, Greg Stark wrote:
I don't think we should be looking at either CUDA or OpenCL directly.
We should be looking for a generic library that can target either and
is well maintained a
On 15/02/2012 23:11, Peter Geoghegan wrote:
On 15 February 2012 20:00, Gaetano Mendola wrote:
On 13/02/2012 19:48, Greg Stark wrote:
I don't think we should be looking at either CUDA or OpenCL directly.
We should be looking for a generic library that can target either and
is well maintained a
In bug #6457 it's pointed out that we *still* don't have full
functionality for locale-dependent regexp behavior with UTF8 encoding.
The reason is that there's old crufty code in regc_locale.c that only
considers character codes up to 255 when searching for characters that
should be considered "let
Robert Haas wrote:
> On Wed, Feb 15, 2012 at 4:47 PM, Kevin Grittner
> wrote:
>> That is unfortunate. I guess it points out the value of adding a
>> comment to point out why we would want to check these values even
>> on a reset to a previously-used value.
>
> +1 for such a comment.
Will do.
Jay Levitt writes:
> - I'm not sure how to represent arbitrary column-like features without
> reinventing the wheel and putting a database in the database.
ISTM you could define a composite type and then create operators and an
operator class over that type. If you were trying to make a btree
o
On Wed, Feb 15, 2012 at 4:47 PM, Kevin Grittner
wrote:
> That is unfortunate. I guess it points out the value of adding a
> comment to point out why we would want to check these values even on
> a reset to a previously-used value.
+1 for such a comment.
>> I assume that you're thinking we'd onl
On Wed, Feb 15, 2012 at 4:32 PM, Dimitri Fontaine
wrote:
> Ok, I can perfectly understand that. The principled implementation is
> not saving us here, we still need to review each call site. The way I
> read your comment, I continue working on my big patch and we'll see what
> pieces get in, rig
Hackers,
The call is now open for Google Summer of Code.
If you are interested in being a GSoC mentor this summer, please reply
to this email. I want to gauge whether or not we should participate
this summer.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hacke
On 15 February 2012 20:00, Gaetano Mendola wrote:
> On 13/02/2012 19:48, Greg Stark wrote:
>>
>> I don't think we should be looking at either CUDA or OpenCL directly.
>> We should be looking for a generic library that can target either and
>> is well maintained and actively developed. Any GPU code
Tom Lane wrote:
> The main thing I would be worried about is whether you're sure
> that you have separated the RESET-as-a-command case from the cases
> where we actually are rolling back to a previous state.
I will double-check that, and make sure there is regression test
coverage of that case
"Kevin Grittner" writes:
> Robert Haas wrote:
>> This patch makes me a little nervous, because the existing
>> behavior seems to have been coded for quite deliberately.
> It does, although I'm not clear *why* it was. I suspect it may have
> been based on an assumption that whatever value is in
Robert Haas wrote:
> On Sat, Feb 11, 2012 at 1:36 PM, Kevin Grittner
> wrote:
>> "Kevin Grittner" wrote:
>> Tom Lane wrote:
>>
I agree it's a bug that you can do what Kevin's example shows.
>>>
>>> I'll look at it and see if I can pull together a patch.
>>
>> Attached.
>>
>> Basically, if a
Robert Haas writes:
> I'm just saying that nobody's realistically going to be able to verify
> a patch of this size. It's either going to get committed warts and
> all, or it's going to not get committed. Decomposing it into a series
> of patches would make it possible to actually verify the log
On Wed, Feb 15, 2012 at 3:25 PM, Dimitri Fontaine
wrote:
>> 1. I fear that the collection of commands to which this applies is
>> going to end up being kind of a random selection. I suggest that for
>> the first version of the patch, just pick a couple of simple commands
>> like VACUUM and ANALYZ
On Wed, Feb 15, 2012 at 2:54 PM, Robert Haas wrote:
> On Wed, Feb 15, 2012 at 2:24 PM, Tom Lane wrote:
>> Robert Haas writes:
>>> Speed up in-memory tuplesorting.
>>
>> This patch appears to have broken those members of the buildfarm that
>> use VPATH builds. I assume you didn't think about the
[Preamble: I've been told that the hackers list is appropriate for
extension-related topics like this, even if it's not about contributing to
core. If I'm misappropriating, please let me know.]
Goal: Personalized, context-relevant query results
We are building a deeply personalized site; think
Hi,
Thanks for your time reviewing that patch!
Robert Haas writes:
> I took a brief look at this just now, and in general I'm pleasantly
> surprised. But, as you might imagine, I have some reservations:
Good starting point, let's see about the details :)
> 1. I fear that the collection of com
On 13/02/2012 19:48, Greg Stark wrote:
I don't think we should be looking at either CUDA or OpenCL directly.
We should be looking for a generic library that can target either and
is well maintained and actively developed. Any GPU code we write
ourselves would rapidly be overtaken by changes in th
On 13/02/2012 19:48, Greg Stark wrote:
I don't think we should be looking at either CUDA or OpenCL directly.
We should be looking for a generic library that can target either and
is well maintained and actively developed. Any GPU code we write
ourselves would rapidly be overtaken by changes in th
On 15.02.2012 18:52, Fujii Masao wrote:
On Thu, Feb 16, 2012 at 1:01 AM, Heikki Linnakangas
wrote:
Are you still seeing this failure with the latest patch I posted
(http://archives.postgresql.org/message-id/4f38f5e5.8050...@enterprisedb.com)?
Yes. Just to be safe, I again applied the latest
On Wed, Feb 15, 2012 at 2:24 PM, Tom Lane wrote:
> Robert Haas writes:
>> Speed up in-memory tuplesorting.
>
> This patch appears to have broken those members of the buildfarm that
> use VPATH builds. I assume you didn't think about the path to
> qsort_tuple.c very carefully.
So it appears. I c
Robert Haas writes:
> Speed up in-memory tuplesorting.
This patch appears to have broken those members of the buildfarm that
use VPATH builds. I assume you didn't think about the path to
qsort_tuple.c very carefully.
regards, tom lane
--
Sent via pgsql-hackers mailing
On Wed, Feb 15, 2012 at 07:50:41PM +0200, Peter Eisentraut wrote:
> pg_upgrade prints something like this:
>
> Restoring user relation files
> /var/lib/postgresql/8.4/main/base/35338/37229
>
> But it's not actually "restoring" anything, is it?
>
> Maybe "transferring" would be better? (Or cop
Pavan Deolasee writes:
> On Tue, Feb 7, 2012 at 3:03 AM, Tom Lane wrote:
>> Hmm. It works fine if you issue an actual ROLLBACK command there,
>> so my gut reaction is that AbortOutOfAnyTransaction isn't sufficiently
>> duplicating the full-fledged ROLLBACK code path. No time to dig further
>> r
On Wed, Feb 15, 2012 at 1:45 PM, Alvaro Herrera
wrote:
> Excerpts from Christoph Berg's message of mié feb 15 12:16:52 -0300 2012:
>> Re: Robert Haas 2012-02-15
>>
>> > Fixed, but note that I had to recreate the patch by manual
>> > examination. Including it inline tends to garble things.
>>
>>
On Sun, Feb 5, 2012 at 4:09 AM, Kohei KaiGai wrote:
> The attached part-1 patch moves related routines from hooks.c to
> label.c because of references to static variables.
I have committed this part. Seems like a better location for that code, anyhow.
--
Robert Haas
EnterpriseDB: http://www.en
>>So I want to know what exactly the operations are involved in the server
side statistics in EXPLAIN ANALYZE
It gives the time for execution of Query on server. According to my
knowledge, it doesn't account for data to send over TCP.
From: Zhou Han [mailto:zhou...@gmail.com]
Sent: Wednesday,
>>So, is it client interface (ODBC, libpq) 's cost mainly due to TCP?
The difference as compare to your embedded DB you are seeing is mainly seems
to be due to TCP.
One optimization you can use is to use Unix-domain socket mode of
PostgreSQL. You can refer unix_socket_directory parameter in po
Excerpts from Christoph Berg's message of mié feb 15 12:16:52 -0300 2012:
> Re: Robert Haas 2012-02-15
>
> > Fixed, but note that I had to recreate the patch by manual
> > examination. Including it inline tends to garble things.
>
> Hmm, I thought I had :set paste and everything...
If you copi
On Sat, Feb 11, 2012 at 1:36 PM, Kevin Grittner
wrote:
> "Kevin Grittner" wrote:
> Tom Lane wrote:
>
>>> I agree it's a bug that you can do what Kevin's example shows.
>>
>> I'll look at it and see if I can pull together a patch.
>
> Attached.
>
> Basically, if a GUC has a check function, this pa
Heikki Linnakangas writes:
> To fix this, we need to somehow pass the caller's text domain to
> errcontext(). The most straightforward way is to pass it as an extra
> argument. Ideally, errcontext() would be a macro that passes TEXTDOMAIN
> to the underlying function, so that you don't need to
As per http://archives.postgresql.org/pgsql-general/2012-02/msg00304.php
there is no switch case in shdepReassignOwned for foreign data wrappers.
The obvious short-term answer (and probably the only back-patchable one)
is to add a case for that object type. But after all the refactoring
that's be
pg_upgrade prints something like this:
Restoring user relation files
/var/lib/postgresql/8.4/main/base/35338/37229
But it's not actually "restoring" anything, is it?
Maybe "transferring" would be better? (Or copying/linking, to be more
precise.)
--
Sent via pgsql-hackers mailing list (pgsq
On Mon, Feb 13, 2012 at 5:38 AM, Marti Raudsepp wrote:
> On Sat, Feb 11, 2012 at 01:54, Gaetano Mendola wrote:
>> I wonder if somewhere in Postgres source "we" are relying on the GCC
>> "correct behaviour" regarding the read-modify-write of bitfield in
>> structures.
>
> Probably not. I'm pretty
On Thu, Feb 16, 2012 at 1:01 AM, Heikki Linnakangas
wrote:
> On 13.02.2012 19:13, Fujii Masao wrote:
>>
>> On Mon, Feb 13, 2012 at 8:37 PM, Heikki Linnakangas
>> wrote:
>>>
>>> On 13.02.2012 01:04, Jeff Janes wrote:
Attached is my quick and dirty attempt to set XLP_FIRST_IS_CONTRE
On Mon, Feb 13, 2012 at 20:48, Greg Stark wrote:
> I don't think we should be looking at either CUDA or OpenCL directly.
> We should be looking for a generic library that can target either and
> is well maintained and actively developed.
I understand your point about using some external library f
On Tue, Feb 14, 2012 at 4:29 PM, Dimitri Fontaine
wrote:
>>> An ack about the way it's now implemented would be awesome
> I'm still missing that, which is only fair, just a ping from me here.
I took a brief look at this just now, and in general I'm pleasantly
surprised. But, as you might imagine
On Wed, Feb 15, 2012 at 16:14, Bruce Momjian wrote:
> On Wed, Feb 15, 2012 at 09:54:04AM +0100, Magnus Hagander wrote:
>> On Wed, Feb 15, 2012 at 02:23, Bruce Momjian wrote:
>> > On Wed, Feb 15, 2012 at 01:35:05AM +0200, Marko Kreen wrote:
>> >> On Tue, Feb 14, 2012 at 05:59:06PM -0500, Tom Lane
On 13.02.2012 19:13, Fujii Masao wrote:
On Mon, Feb 13, 2012 at 8:37 PM, Heikki Linnakangas
wrote:
On 13.02.2012 01:04, Jeff Janes wrote:
Attached is my quick and dirty attempt to set XLP_FIRST_IS_CONTRECORD.
I have no idea if I did it correctly, in particular if calling
GetXLogBuffer(Curr
On Wed, Feb 15, 2012 at 6:14 AM, Kohei KaiGai wrote:
> The attached patch is additional regression tests of ALTER FUNCTION with
> LEAKPROOF based on your patch.
> It also moves create_function_3 into the group with create_aggregate and so
> on.
Committed, thanks.
--
Robert Haas
EnterpriseDB: h
Hello
I encountered a bug which always causes PostgreSQL to crash on Windows.
Attached is a patch that fixes it. Please review it and include it in the
upcoming minor releases of supported versions.
The following is a bug report.
Your name :MauMau
Your email address :maumau...@gmail.com
Alexander Korotkov writes:
> On Wed, Feb 15, 2012 at 4:26 PM, Heikki Linnakangas <
> heikki.linnakan...@enterprisedb.com> wrote:
>> So, I think we should go with your original fix and simply do nothing in
>> gistRelocateBuildBuffersOnSpli**t() if the page doesn't have a buffer.
> I agree.
OK, I
On Wed, Feb 15, 2012 at 8:29 AM, Peter Geoghegan wrote:
> Cool. I agree that we should do this. It doesn't need to be justified
> as a performance optimisation - it makes sense to refactor in this
> way. If that makes things faster, then so much the better.
Well, maybe so, but I think if the perf
On Tue, Feb 14, 2012 at 08:23:10PM -0500, Bruce Momjian wrote:
> On Wed, Feb 15, 2012 at 01:35:05AM +0200, Marko Kreen wrote:
> > On Tue, Feb 14, 2012 at 05:59:06PM -0500, Tom Lane wrote:
> > > Bruce Momjian writes:
> > > > On Mon, Feb 13, 2012 at 08:28:03PM -0500, Tom Lane wrote:
> > > >> +1, I w
Re: Robert Haas 2012-02-15
> Fixed, but note that I had to recreate the patch by manual
> examination. Including it inline tends to garble things.
Hmm, I thought I had :set paste and everything...
> > (It is unclear to me why the same example is cited twice here, but the
> > text around them is
On Wed, Feb 15, 2012 at 09:54:04AM +0100, Magnus Hagander wrote:
> On Wed, Feb 15, 2012 at 02:23, Bruce Momjian wrote:
> > On Wed, Feb 15, 2012 at 01:35:05AM +0200, Marko Kreen wrote:
> >> On Tue, Feb 14, 2012 at 05:59:06PM -0500, Tom Lane wrote:
> >> > Bruce Momjian writes:
> >> > > On Mon, Feb
Harada-san,
I checked the v9 patch, however, it still has some uncertain implementation.
[memory context of tuple store]
It calls tuplestore_begin_heap() under the memory context of
festate->scan_cxt at pgsqlBeginForeignScan.
On the other hand, tuplestore_gettupleslot() is called under the
memory
On Wed, Feb 15, 2012 at 5:38 AM, Christoph Berg wrote:
> diff --git a/doc/src/sgml/sepgsql.sgml b/doc/src/sgml/sepgsql.sgml
> index e45c258..ee0a255 100644
> *** a/doc/src/sgml/sepgsql.sgml
> --- b/doc/src/sgml/sepgsql.sgml
> *** UPDATE t1 SET x = 2, y = md5sum(y) WHERE
> *** 358,364 *
On Wed, Feb 15, 2012 at 4:26 PM, Heikki Linnakangas <
heikki.linnakan...@enterprisedb.com> wrote:
> Actually, I think it made sense to simply do nothing if the buffer doesn't
> exist. The algorithm doesn't require that all the buffers must exist at all
> times. It is quite accidental that whenever
On 15 February 2012 06:16, Robert Haas wrote:
> On Fri, Feb 10, 2012 at 10:30 AM, Peter Geoghegan
> wrote:
>> [ new patch ]
>
> I spent quite a bit of time looking at this today - the patch
> specifically, and the issue of making quicksort fast more generally.
> It seemed to me that if we're goi
On 15.02.2012 10:18, Alexander Korotkov wrote:
On Wed, Feb 15, 2012 at 2:54 AM, Tom Lane wrote:
Alexander Korotkov writes:
ITSM, I found the problem. This piece of code is triggering an error. It
assumes each page of corresponding to have initialized buffer. That
should
be true because we'
(2012/02/14 23:50), Tom Lane wrote:
> Shigeru Hanada writes:
>> (2012/02/14 17:40), Etsuro Fujita wrote:
>>> As discussed at
>>> that thread, it would have to change the PlanForeignScan API to let the
>>> FDW generate multiple paths and dump them all to add_path instead of
>>> returning a FdwPlan
On ons, 2012-02-08 at 09:16 +0100, Magnus Hagander wrote:
> > My best idea at the moment is that we should set these parameters to
> > empty by default, and make users point them to existing files if they
> > want to use that functionality. Comments?
> >
>
> +1. Anybody who actually cares about s
The attached patch is additional regression tests of ALTER FUNCTION with
LEAKPROOF based on your patch.
It also moves create_function_3 into the group with create_aggregate and so on.
Thanks,
2012/2/14 Kohei KaiGai :
> 2012/2/14 Robert Haas :
>> On Tue, Feb 14, 2012 at 4:55 AM, Kohei KaiGai wrot
diff --git a/doc/src/sgml/sepgsql.sgml b/doc/src/sgml/sepgsql.sgml
index e45c258..ee0a255 100644
*** a/doc/src/sgml/sepgsql.sgml
--- b/doc/src/sgml/sepgsql.sgml
*** UPDATE t1 SET x = 2, y = md5sum(y) WHERE
*** 358,364
In this case we must have db_table:select in additio
I just noticed that we use the same gettext domain for all messages
attached to one error. That is wrong in case of context information,
where you have a stack of context lines, originating from different
modules. The result is that context lines don't always get translated.
For example:
post
On Wed, Feb 15, 2012 at 02:23, Bruce Momjian wrote:
> On Wed, Feb 15, 2012 at 01:35:05AM +0200, Marko Kreen wrote:
>> On Tue, Feb 14, 2012 at 05:59:06PM -0500, Tom Lane wrote:
>> > Bruce Momjian writes:
>> > > On Mon, Feb 13, 2012 at 08:28:03PM -0500, Tom Lane wrote:
>> > >> +1, I was about to su
On Wed, Feb 15, 2012 at 2:54 AM, Tom Lane wrote:
> Alexander Korotkov writes:
> > ITSM, I found the problem. This piece of code is triggering an error. It
> > assumes each page of corresponding to have initialized buffer. That
> should
> > be true because we're inserting index tuples from up to
63 matches
Mail list logo
