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
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
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
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
>
>
> 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
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
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
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
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
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
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
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
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
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
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 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 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,
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
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
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
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 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
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
> 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
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
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
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
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
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
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?
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
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 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 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
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
35 matches
Mail list logo
