Robert,
On 08/25/2011 04:59 AM, Robert Haas wrote:
> True; although there are some other complications. With a
> sufficiently sophisticated allocator you can avoid mutex contention
> when allocating chunks, but then you have to store a pointer to the
> chunk somewhere or other, and that then requ
On Wed, Aug 24, 2011 at 4:30 AM, Markus Wanner wrote:
> I'm in respectful disagreement regarding the ring-buffer approach and
> think that dynamic allocation can actually be more efficient if done
> properly, because there doesn't need to be head and tail pointers, which
> might turn into a point
On Tue, Aug 23, 2011 at 4:51 PM, Alvaro Herrera
wrote:
> Excerpts from Robert Haas's message of mar ago 23 17:43:13 -0300 2011:
>> On Tue, Aug 23, 2011 at 4:17 PM, Tom Lane wrote:
>> > Robert Haas writes:
>> >> What I think would be really interesting is a way to make this work
>> >> when the ta
On 08/24/2011 08:43 PM, Josh Berkus wrote:
On 8/23/11 1:30 PM, Andrew Dunstan wrote:
Attached is an undocumented patch that allows pg_restore to omit
post-data items or omit all but post-data items. This has been discussed
before, and Simon sent in a patch back on 2008, which has bitrotted
som
On Wed, Aug 24, 2011 at 9:11 PM, Tom Lane wrote:
> Alvaro Herrera writes:
>> After having to play with this, I didn't like it very much, because
>> regression.diffs gets spammed with the (rather massive and completely
>> useless) diff in that test. For the xml tests, rather than ignoring it
>> f
FYI, I was just checking out the contributors page and noticed that he's
listed under Past Contributors.
http://www.postgresql.org/community/contributors/
On Fri, Jul 8, 2011 at 1:55 PM, Bruce Momjian wrote:
> Tom Lane wrote:
> > Robert Haas writes:
> > >> Anyone feels in mood for a comment?
Alvaro Herrera writes:
> After having to play with this, I didn't like it very much, because
> regression.diffs gets spammed with the (rather massive and completely
> useless) diff in that test. For the xml tests, rather than ignoring it
> fail on an installation without libxml, we use an alterna
On 8/23/11 1:30 PM, Andrew Dunstan wrote:
>
> Attached is an undocumented patch that allows pg_restore to omit
> post-data items or omit all but post-data items. This has been discussed
> before, and Simon sent in a patch back on 2008, which has bitrotted
> some. I'm not sure why it was dropped at
On Wed, Aug 24, 2011 at 2:01 PM, Josh Berkus wrote:
>
> FWIW, I have immediate use for this in creating cut-down versions of
> databases for testing purposes. It'll eliminate a couple pages of shell
> scripts for me.
Speaking of "cut-down versions", I have recently been using pg_sample,
and been
Excerpts from Heikki Linnakangas's message of jue ago 18 09:57:34 -0400 2011:
> Committed. I removed the second expected output file, and marked the
> prepared-transactions tests in the schedule as "ignore" instead. That
> way if max_prepared_transactions=0, you get a notice that the test case
Excerpts from Kevin Grittner's message of mar ago 23 15:07:33 -0300 2011:
> Heikki Linnakangas wrote:
> > I did change the lexer slightly, to trim whitespace from the
> > beginning and end of SQL blocks. This cuts the size of expected
> > output a bit, and makes it look nicer anyway.
>
> OK. Y
> For those who are (like my clients :-) ) anxious to get their hands on
> this immediately, a backport patch is also attached which applies to 9.0
> sources, and applies with offsets to 8.4 sources.
FWIW, I have immediate use for this in creating cut-down versions of
databases for testing purpos
Hello,
I am interesting about a CONTINUE HANDLER behave, please can you
check, and send a result of following function?
CREATE FUNCTION REVERSE(INSTR VARCHAR(4000))
RETURNS INT
DETERMINISTIC NO EXTERNAL ACTION CONTAINS SQL
BEGIN
DECLARE RES INT;
DECLARE CONTINUE HANDL
On Wed, Aug 24, 2011 at 12:38 PM, Tom Lane wrote:
> Merlin Moncure writes:
>> On Wed, Aug 24, 2011 at 1:24 PM, Daniel Farina wrote:
>>> At Heroku we use CREATE INDEX CONCURRENTLY with great success, but
>>> recently when frobbing around some indexes I realized that there is no
>>> equivalent for
Merlin Moncure writes:
> On Wed, Aug 24, 2011 at 1:24 PM, Daniel Farina wrote:
>> At Heroku we use CREATE INDEX CONCURRENTLY with great success, but
>> recently when frobbing around some indexes I realized that there is no
>> equivalent for DROP INDEX, and this is a similar but lesser problem
>>
On Wed, Aug 24, 2011 at 2:24 PM, Daniel Farina wrote:
> Could I make the ACCESS EXCLUSIVE section just long enough to commit
> catalog updates, and then have the bulk of the work happen afterwards?
>
> The general idea is:
>
> 1) set an index as "invalid", to ensure no backend will use it in plann
Peter Eisentraut writes:
> On tor, 2011-08-18 at 18:56 -0400, Tom Lane wrote:
>> I ran into $SUBJECT whilst doing trial RPM packaging of 9.1.
> Fixed.
Works for me --- thanks!
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To ma
The attached change to postgresql.conf.sample makes it more clear at a
glance that the default value of listen_addresses is 'localhost', not
'localhost, *'. This would have saved a friend an hour or two of fiddling
tonight.
Thanks,
Dougal
doc-clarity.patch
Description: Binary data
--
Sent via
On tor, 2011-08-18 at 18:56 -0400, Tom Lane wrote:
> I ran into $SUBJECT whilst doing trial RPM packaging of 9.1. The problem
> is that make starts building contrib modules before errcodes.h has been
> made, leading to failures such as
>
> In file included from ../../src/include/postgres.h:48:0,
On lör, 2011-08-20 at 09:56 -0400, Bruce Momjian wrote:
> Peter Eisentraut wrote:
> > On tis, 2011-08-16 at 20:35 -0400, Tom Lane wrote:
> > > In fact, now that I think about it, setting the transaction snapshot
> > > from a utility statement would be functionally useful because then you
> > > coul
On Wed, Aug 24, 2011 at 1:24 PM, Daniel Farina wrote:
> Hello list,
>
> At Heroku we use CREATE INDEX CONCURRENTLY with great success, but
> recently when frobbing around some indexes I realized that there is no
> equivalent for DROP INDEX, and this is a similar but lesser problem
> (as CREATE IND
On tis, 2011-08-23 at 21:17 -0400, Tom Lane wrote:
> There are at least two ways we could fix this: change
> earthdistance/Makefile to do this:
>
> REGRESS_OPTS = --extra-install=contrib/cube --dbname=$(CONTRIB_TESTDB)
>
> or change pgxs.mk to do this:
>
> REGRESS_OPTS += --dbname=$(CONTRIB_TEST
Hello list,
At Heroku we use CREATE INDEX CONCURRENTLY with great success, but
recently when frobbing around some indexes I realized that there is no
equivalent for DROP INDEX, and this is a similar but lesser problem
(as CREATE INDEX takes much longer), as DROP INDEX takes an ACCESS
EXCLUSIVE loc
Robert Haas writes:
> On Wed, Aug 24, 2011 at 11:45 AM, Tom Lane wrote:
>> I kinda suspect that the NaN behavior was not designed but accidental.
>> What I'm wondering is whether it's really the "right", sensible,
>> behavior.
> On a blank slate, I might choose to do it differently, but consider
On Wed, Aug 24, 2011 at 11:45 AM, Tom Lane wrote:
> Euler Taveira de Oliveira writes:
>> Em 24-08-2011 11:27, Tom Lane escreveu:
>>> Hmm. I agree we need to avoid executing 0/0 here, but should we force
>>> the result to 0, or to NaN?
>
>> If it returns NaN on other platforms, let's be consisten
Euler Taveira de Oliveira writes:
> Em 24-08-2011 11:27, Tom Lane escreveu:
>> Hmm. I agree we need to avoid executing 0/0 here, but should we force
>> the result to 0, or to NaN?
> If it returns NaN on other platforms, let's be consistent.
I kinda suspect that the NaN behavior was not designed
Dimitri Fontaine writes:
> Tom Lane writes:
>> Hence, proposed patch attached (which also improves some of the related
>> comments).
> +1 on the idea, although I'm not in a position to further review or play
> with the patch today.
Further testing shows that this patch still doesn't make things
Em 24-08-2011 11:27, Tom Lane escreveu:
Hmm. I agree we need to avoid executing 0/0 here, but should we force
the result to 0, or to NaN?
If it returns NaN on other platforms, let's be consistent.
--
Euler Taveira de Oliveira - Timbira http://www.timbira.com.br/
PostgreSQL: Consult
Rushabh Lathia writes:
> After debugging I noticed that "0/0" returning NaN on linux but it returns
> "-1.#JIND" on windows.
[ rolls eyes ]
> I added to check into pgstatindex() to avoid "0/0" situation and issue got
> fixed.
Hmm. I agree we need to avoid executing 0/0 here, but should we
I've added some testing results to the wiki page:
http://wiki.postgresql.org/wiki/Fast_GiST_index_build_GSoC_2011
There are not all the results I planned for the first chunk because it takes
more time than I expect.
Some notes about it.
Now I see two causes which accelerate regular build of GiST i
>
>
> There are extensive comments on this in visibilitymap.c and, in
> heapam.c, heap_xlog_visible().
>
> I went through the design again and again. I am convinced that this should
not have any functional bugs and should not cause much performance issues.
Nice thoughts on bypassing the WAL Logging
Description:
===
Error Message " invalid input syntax for type double precision: -1#I" is
displayed while running "select pgstatindex"
Issue only getting reproduce on windows environment.
Analysis:
=
Consider the following testcase to reproduce the issue on windows:
create tabl
Robert, Jim,
thanks for thinking out loud about dynamic allocation of shared memory.
Very much appreciated.
On 08/23/2011 01:22 AM, Robert Haas wrote:
> With respect to a general-purpose shared memory allocator, I think
> that there are cases where that would be useful to have, but I don't
> thi
Hello Dimitri,
On 08/23/2011 06:39 PM, Dimitri Fontaine wrote:
> I'm far from familiar with the detailed concepts here, but allow me to
> comment. I have two open questions:
>
> - is it possible to use a distributed algorithm to produce XIDs,
>something like Vector Clocks?
>
>Then each
Tom Lane writes:
> On further reflection, it seems more in keeping with the coding
> elsewhere in this module to treat this as a distinct dependency type,
> instead of confusing it with a NORMAL dependency. There's no actual
> functional difference at the moment, but more info is better than less
35 matches
Mail list logo
