On Wed, Feb 15, 2012 at 2:54 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Alexander Korotkov aekorot...@gmail.com 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
On Wed, Feb 15, 2012 at 02:23, Bruce Momjian br...@momjian.us 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 br...@momjian.us writes:
On Mon, Feb 13, 2012 at 08:28:03PM -0500, Tom Lane wrote:
+1,
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:
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
/synopsis
In this case we must have
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 kai...@kaigai.gr.jp:
2012/2/14 Robert Haas robertmh...@gmail.com:
On Tue, Feb
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 setting up
(2012/02/14 23:50), Tom Lane wrote:
Shigeru Hanadashigeru.han...@gmail.com 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
On 15.02.2012 10:18, Alexander Korotkov wrote:
On Wed, Feb 15, 2012 at 2:54 AM, Tom Lanet...@sss.pgh.pa.us wrote:
Alexander Korotkovaekorot...@gmail.com writes:
ITSM, I found the problem. This piece of code is triggering an error. It
assumes each page of corresponding to have initialized
On 15 February 2012 06:16, Robert Haas robertmh...@gmail.com wrote:
On Fri, Feb 10, 2012 at 10:30 AM, Peter Geoghegan pe...@2ndquadrant.com
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.
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 we
On Wed, Feb 15, 2012 at 5:38 AM, Christoph Berg c...@df7cb.de 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
***
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 09:54:04AM +0100, Magnus Hagander wrote:
On Wed, Feb 15, 2012 at 02:23, Bruce Momjian br...@momjian.us 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 br...@momjian.us
Re: Robert Haas 2012-02-15
ca+tgmozjutszhpxwwzcm4kjjwh__1admo3kosbbq+fhscqp...@mail.gmail.com
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
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 br...@momjian.us writes:
On Mon, Feb 13, 2012 at 08:28:03PM -0500, Tom Lane wrote:
+1, I
On Wed, Feb 15, 2012 at 8:29 AM, Peter Geoghegan pe...@2ndquadrant.com 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
Alexander Korotkov aekorot...@gmail.com 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
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
On Wed, Feb 15, 2012 at 6:14 AM, Kohei KaiGai kai...@kaigai.gr.jp 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
On 13.02.2012 19:13, Fujii Masao wrote:
On Mon, Feb 13, 2012 at 8:37 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com 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
On Wed, Feb 15, 2012 at 16:14, Bruce Momjian br...@momjian.us wrote:
On Wed, Feb 15, 2012 at 09:54:04AM +0100, Magnus Hagander wrote:
On Wed, Feb 15, 2012 at 02:23, Bruce Momjian br...@momjian.us wrote:
On Wed, Feb 15, 2012 at 01:35:05AM +0200, Marko Kreen wrote:
On Tue, Feb 14, 2012 at
On Tue, Feb 14, 2012 at 4:29 PM, Dimitri Fontaine
dimi...@2ndquadrant.fr 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,
On Mon, Feb 13, 2012 at 20:48, Greg Stark st...@mit.edu 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
On Thu, Feb 16, 2012 at 1:01 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 13.02.2012 19:13, Fujii Masao wrote:
On Mon, Feb 13, 2012 at 8:37 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 13.02.2012 01:04, Jeff Janes wrote:
Attached is my
On Mon, Feb 13, 2012 at 5:38 AM, Marti Raudsepp ma...@juffo.org wrote:
On Sat, Feb 11, 2012 at 01:54, Gaetano Mendola mend...@gmail.com 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.
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
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
Heikki Linnakangas heikki.linnakan...@enterprisedb.com 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
On Sat, Feb 11, 2012 at 1:36 PM, Kevin Grittner
kevin.gritt...@wicourts.gov 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
Excerpts from Christoph Berg's message of mié feb 15 12:16:52 -0300 2012:
Re: Robert Haas 2012-02-15
ca+tgmozjutszhpxwwzcm4kjjwh__1admo3kosbbq+fhscqp...@mail.gmail.com
Fixed, but note that I had to recreate the patch by manual
examination. Including it inline tends to garble things.
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
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,
On Sun, Feb 5, 2012 at 4:09 AM, Kohei KaiGai kai...@kaigai.gr.jp 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
On Wed, Feb 15, 2012 at 1:45 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Excerpts from Christoph Berg's message of mié feb 15 12:16:52 -0300 2012:
Re: Robert Haas 2012-02-15
ca+tgmozjutszhpxwwzcm4kjjwh__1admo3kosbbq+fhscqp...@mail.gmail.com
Fixed, but note that I had to recreate the
Pavan Deolasee pavan.deola...@gmail.com writes:
On Tue, Feb 7, 2012 at 3:03 AM, Tom Lane t...@sss.pgh.pa.us 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
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
Robert Haas rh...@postgresql.org 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
On Wed, Feb 15, 2012 at 2:24 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas rh...@postgresql.org 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
On 15.02.2012 18:52, Fujii Masao wrote:
On Thu, Feb 16, 2012 at 1:01 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com 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
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
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
Hi,
Thanks for your time reviewing that patch!
Robert Haas robertmh...@gmail.com 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
[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;
On Wed, Feb 15, 2012 at 2:54 PM, Robert Haas robertmh...@gmail.com wrote:
On Wed, Feb 15, 2012 at 2:24 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas rh...@postgresql.org writes:
Speed up in-memory tuplesorting.
This patch appears to have broken those members of the buildfarm that
use
On Wed, Feb 15, 2012 at 3:25 PM, Dimitri Fontaine
dimi...@2ndquadrant.fr 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
Robert Haas robertmh...@gmail.com 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
Robert Haas robertmh...@gmail.com wrote:
On Sat, Feb 11, 2012 at 1:36 PM, Kevin Grittner
kevin.gritt...@wicourts.gov 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.
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Robert Haas robertmh...@gmail.com 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
Tom Lane t...@sss.pgh.pa.us 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
On 15 February 2012 20:00, Gaetano Mendola mend...@gmail.com 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
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
On Wed, Feb 15, 2012 at 4:32 PM, Dimitri Fontaine
dimi...@2ndquadrant.fr 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
On Wed, Feb 15, 2012 at 4:47 PM, Kevin Grittner
kevin.gritt...@wicourts.gov 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
Jay Levitt jay.lev...@gmail.com 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
Robert Haas robertmh...@gmail.com wrote:
On Wed, Feb 15, 2012 at 4:47 PM, Kevin Grittner
kevin.gritt...@wicourts.gov 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
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
On 15/02/2012 23:11, Peter Geoghegan wrote:
On 15 February 2012 20:00, Gaetano Mendolamend...@gmail.com 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
On 15/02/2012 23:11, Peter Geoghegan wrote:
On 15 February 2012 20:00, Gaetano Mendolamend...@gmail.com 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
On 15 February 2012 15:27, Robert Haas robertmh...@gmail.com 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
On 15 February 2012 22:54, Gaetano Mendola mend...@gmail.com 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:
-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
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
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 Experts
63 matches
Mail list logo
