On mån, 2011-09-05 at 16:53 -0400, Bruce Momjian wrote:
> hubert depesz lubaczewski wrote:
> > > Good. Is it possible to compile with debug symbols, -g? Odd you are
> > > crashing in libc.
> >
> > this had debug:
> >
> > ./configure \
> > --prefix=/opt/pgsql-9.0.5a-int \
> > --e
Interesting.
http://pgxn.org/dist/pg-json/
Best,
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Excerpts from Robert Haas's message of lun sep 05 23:55:33 -0300 2011:
> On Mon, Sep 5, 2011 at 10:52 PM, Alvaro Herrera
> wrote:
> > Excerpts from Robert Haas's message of lun sep 05 23:27:16 -0300 2011:
> >> On Mon, Sep 5, 2011 at 9:14 AM, Yeb Havinga wrote:
> >> > On 2011-09-01 14:40, Robert H
On Mon, Sep 05, 2011 at 10:07:29PM -0300, Alvaro Herrera wrote:
> Excerpts from David Fetter's message of lun sep 05 21:05:10 -0300 2011:
>
> > On brief inspection, it appears that each of these would be better
> > served, at least functionally, with some kind of enumerated type.
> > Might it be w
On Mon, Sep 5, 2011 at 7:52 PM, Tomas Vondra wrote:
>> If your logging criteria for the write phase was "display a message any
>> time more than 30 seconds have passed since last seeing one", that would
>> give you only a few lines of output in a boring, normal
>> checkpoint--certainly less than t
On Mon, Sep 5, 2011 at 10:52 PM, Alvaro Herrera
wrote:
> Excerpts from Robert Haas's message of lun sep 05 23:27:16 -0300 2011:
>> On Mon, Sep 5, 2011 at 9:14 AM, Yeb Havinga wrote:
>> > On 2011-09-01 14:40, Robert Haas wrote:
>> >>
>> >> userspace avc.
>> >> I've committed this, but I still thi
On Mon, Sep 5, 2011 at 6:56 PM, Alvaro Herrera
wrote:
> Excerpts from Bruce Momjian's message of sáb sep 03 20:18:47 -0300 2011:
>> FYI, here are all the C files with over 6k lines:
>>
>> - 45133 ./interfaces/ecpg/preproc/preproc.c
>> - 33651 ./backend/parser/gram.c
>> - 17551 ./backend/parser/
Excerpts from Robert Haas's message of lun sep 05 23:27:16 -0300 2011:
> On Mon, Sep 5, 2011 at 9:14 AM, Yeb Havinga wrote:
> > On 2011-09-01 14:40, Robert Haas wrote:
> >>
> >> userspace avc.
> >> I've committed this, but I still think it would be helpful to revise
> >> that comment. The turn "
On Mon, Sep 5, 2011 at 2:02 PM, Andy Colson wrote:
> Taking into account Noah's and Greg's "Displaying accumulated autovacuum
> cost" patch is also sending to logs, do we all now agree that this is proper
> way?
My general impression of the thread is that nobody really wants to
reject the patch (
daveg wrote:
> > > As far as I can tell pg_upgrade never copied any pg_clog files from the
> > > old cluster to the new cluster. I wish I had detected that before running
> > > the remove_old_cluster.sh script.
> >
> > Wow, no clogs? That would make the system very confused. You can pull
> > the
On Mon, Sep 5, 2011 at 1:56 PM, Andy Colson wrote:
> This patch:
>
> https://commitfest.postgresql.org/action/patch_view?id=605
>
> Seems to have been after thoughts, and back burner stuff, and forgotten
> about...
>
> Has it already been commit?
>
> http://archives.postgresql.org/pgsql-committers
On Mon, Sep 5, 2011 at 1:01 PM, Bruce Momjian wrote:
> Alvaro Herrera wrote:
>> Excerpts from Tom Lane's message of mar mar 01 19:03:35 -0300 2011:
>> > Alvaro Herrera writes:
>> > > Strangely, we made pg_database have a toast table, and the only reason
>> > > for this is datacl. Should we creat
On Mon, Sep 5, 2011 at 9:14 AM, Yeb Havinga wrote:
> On 2011-09-01 14:40, Robert Haas wrote:
>>
>> userspace avc.
>> I've committed this, but I still think it would be helpful to revise
>> that comment. The turn "boosted up" is not very precise or
>> informative. Could you submit a separate, co
On Fri, Sep 2, 2011 at 12:45 PM, Tom Lane wrote:
> column values). But GROUP BY or DISTINCT would entirely invalidate the
> column frequency statistics, which makes me think that ignoring the
> pg_statistic entry might be the thing to do. Comments?
There's a possible problem there in that you m
On Mon, Sep 05, 2011 at 08:19:21PM -0400, Bruce Momjian wrote:
> daveg wrote:
> > > Can you tell me what table is showing this error? Does it happen during
> > > vacuum? Can you run a vacuum verbose to see what it is throwing the
> > > error on? Thanks.
> >
> > This was upgrading from 8.4.8 to
Did we ever address this?
---
Tom Lane wrote:
> I've been able to reproduce the behavior described here:
> http://archives.postgresql.org/pgsql-general/2011-03/msg00538.php
> It's specific to UTF8 locales on Mac OS X. I'm n
Robert Haas wrote:
> On Wed, Mar 23, 2011 at 1:48 AM, Fujii Masao wrote:
> > On Sat, Mar 19, 2011 at 10:20 AM, Robert Haas wrote:
> >> On Fri, Mar 18, 2011 at 1:19 PM, Erik Rijkers wrote:
> >>> This is OK and expected. ?But then it continues (in the logfile) with:
> >>>
> >>> FATAL: ?lock file "
Jim Nasby wrote:
> On Mar 14, 2011, at 9:29 AM, Robert Haas wrote:
>
> > On Mon, Mar 14, 2011 at 10:21 AM, Bruce Momjian wrote:
> >>> Since your original email is fairly unclear about what you think the
> >>> problem is, it's a bit hard to speculate here, but like Simon, I don't
> >>> see any obv
Excerpts from David Fetter's message of lun sep 05 21:05:10 -0300 2011:
> On brief inspection, it appears that each of these would be better
> served, at least functionally, with some kind of enumerated type.
> Might it be worth trying to micro-optimize this case for a one-byte
> enum? Or maybe s
daveg wrote:
> > Can you tell me what table is showing this error? Does it happen during
> > vacuum? Can you run a vacuum verbose to see what it is throwing the
> > error on? Thanks.
>
> This was upgrading from 8.4.8 to 9.0.4. I don't have the running cluster
> anymore, but I do have tar.gz arc
Sorry I missed your reply, catching up now.
On Wed, Aug 31, 2011 at 09:56:59PM -0400, Bruce Momjian wrote:
> daveg wrote:
> > On Mon, Aug 29, 2011 at 07:49:24PM +0200, hubert depesz lubaczewski wrote:
> > > On Mon, Aug 29, 2011 at 06:54:41PM +0200, hubert depesz lubaczewski wrote:
> > > vacuumdb:
On Mon, Sep 05, 2011 at 07:33:09PM -0400, Bruce Momjian wrote:
> David Fetter wrote:
> > > > > I am unsure on that one. We have many 'char' mentions in
> > > > > catalog.sgml, and I don't see any of them shown as '"char"'.
> > > > > (Wow, we should have just called this type char1, but I think
> >
On 09/05/2011 05:27 PM, Andy Colson wrote:
On 09/05/2011 05:04 PM, Andrew Dunstan wrote:
On 09/05/2011 05:03 PM, Andy Colson wrote:
Pavel, this patch:
https://commitfest.postgresql.org/action/patch_view?id=624
It applied clean and compiled ok, but I cannot get it to work at all.
$ psql
Tim
On 3 Září 2011, 8:19, Greg Smith wrote:
> If you're expanding log_checkpoints to an enum, for that to handle what
> I think everybody might ever want (for what checkpoints do now at
> least), I'd find that more useful if it happened like this instead:
>
> log_checkpoints = {off, on, write, sync, ve
David Fetter wrote:
> > > > I am unsure on that one. We have many 'char' mentions in
> > > > catalog.sgml, and I don't see any of them shown as '"char"'.
> > > > (Wow, we should have just called this type char1, but I think
> > > > that name came from Berkeley!) The big problem is that the
> > > >
Piyush Newe wrote:
> Hi,
>
> I was randomly testing some date related stuff on PG & observed that the
> outputs were wrong.
>
> e.g.
> postgres=# SELECT TO_DATE('01-jan-2010', 'DD-MON-YY');
> to_date
>
> 3910-01-01 <- Look at this
> (1 row)
>
> postgres=# SELECT TO_DATE
On Mon, Sep 05, 2011 at 02:21:46PM -0400, Bruce Momjian wrote:
> Alvaro Herrera wrote:
> > Removing CC to pg-docs so that Robert reads it.
> >
> > Excerpts from Bruce Momjian's message of vie mar 11 08:13:20 -0300 2011:
> > > Kevin Grittner wrote:
> >
> > > > relpersistence should be "char", not
On 2 Září 2011, 22:04, Tom Lane wrote:
> "Tomas Vondra" writes:
>> On 2 Z?? 2011, 21:23, Tom Lane wrote:
>>> Well, to be blunt, putting stuff into the postmaster log is entirely
>>> the
>>> wrong way to satify a requirement like that. If you want to expose
>>> progress information, it should
Excerpts from Bruce Momjian's message of sáb sep 03 20:18:47 -0300 2011:
> FYI, here are all the C files with over 6k lines:
>
> - 45133 ./interfaces/ecpg/preproc/preproc.c
> - 33651 ./backend/parser/gram.c
> - 17551 ./backend/parser/scan.c
>14209 ./bin/pg_dump/pg_dump.c
>10590 ./backen
On 09/05/2011 05:04 PM, Andrew Dunstan wrote:
On 09/05/2011 05:03 PM, Andy Colson wrote:
Pavel, this patch:
https://commitfest.postgresql.org/action/patch_view?id=624
It applied clean and compiled ok, but I cannot get it to work at all.
$ psql
Timing is on.
psql (9.2devel)
Type "help" for h
Small bugfix: in gistBufferingFindCorrectParent check that downlinkoffnum
doesn't exceed maximal offset number.
--
With best regards,
Alexander Korotkov.
gist_fast_build-0.14.3.patch.gz
Description: GNU Zip compressed data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.or
On 09/03/2011 07:58 PM, Tom Lane wrote:
Anyway, after giving up on that I went back to plan A, namely install
regress.so and friends into $libdir. That turns out to be really quite
straightforward, though I had to hack pg_regress.c a bit to get its idea
of $libdir to match up exactly with the
On 09/05/2011 05:03 PM, Andy Colson wrote:
Pavel, this patch:
https://commitfest.postgresql.org/action/patch_view?id=624
It applied clean and compiled ok, but I cannot get it to work at all.
$ psql
Timing is on.
psql (9.2devel)
Type "help" for help.
andy=# set plpgsql.prepare_plans to on_st
Bruce Momjian writes:
> Odd it is dying in the memory freeing at executor close --- not in the
> ltree code.
Doesn't seem odd. The glibc complaint previously shown already
indicates this is a memory stomp problem.
--enable-cassert might (or might not) provide additional help.
hubert depesz lubaczewski wrote:
> On Mon, Sep 05, 2011 at 02:51:12PM -0400, Bruce Momjian wrote:
> > hubert depesz lubaczewski wrote:
> > > On Mon, Sep 05, 2011 at 02:18:18PM -0400, Bruce Momjian wrote:
> > > > hubert depesz lubaczewski wrote:
> > > > > I'm not sure if it's upgrade thing, or is it
Pavel, this patch:
https://commitfest.postgresql.org/action/patch_view?id=624
It applied clean and compiled ok, but I cannot get it to work at all.
$ psql
Timing is on.
psql (9.2devel)
Type "help" for help.
andy=# set plpgsql.prepare_plans to on_start;
ERROR: unrecognized configuration parame
hubert depesz lubaczewski wrote:
> > Good. Is it possible to compile with debug symbols, -g? Odd you are
> > crashing in libc.
>
> this had debug:
>
> ./configure \
> --prefix=/opt/pgsql-9.0.5a-int \
> --enable-debug \
> --disable-rpath \
> --without-perl \
>
On Mon, Sep 05, 2011 at 04:43:47PM -0400, Bruce Momjian wrote:
> hubert depesz lubaczewski wrote:
> > On Mon, Sep 05, 2011 at 02:51:12PM -0400, Bruce Momjian wrote:
> > > hubert depesz lubaczewski wrote:
> > > > On Mon, Sep 05, 2011 at 02:18:18PM -0400, Bruce Momjian wrote:
> > > > > hubert depesz
hubert depesz lubaczewski wrote:
> On Mon, Sep 05, 2011 at 02:51:12PM -0400, Bruce Momjian wrote:
> > hubert depesz lubaczewski wrote:
> > > On Mon, Sep 05, 2011 at 02:18:18PM -0400, Bruce Momjian wrote:
> > > > hubert depesz lubaczewski wrote:
> > > > > I'm not sure if it's upgrade thing, or is it
On lör, 2011-09-03 at 19:58 -0400, Tom Lane wrote:
> Anyway, after giving up on that I went back to plan A, namely install
> regress.so and friends into $libdir. That turns out to be really quite
> straightforward, though I had to hack pg_regress.c a bit to get its idea
> of $libdir to match up ex
On 5 Září 2011, 19:17, Andy Colson wrote:
> Tomas, I cannot seem to see any of the patches you link here:
>
> https://commitfest.postgresql.org/action/patch_view?id=628
>
> Looks like you need to take the < > out of the messageid.
Sorry, fixed.
Tomas
--
Sent via pgsql-hackers mailing list (pgs
On Mon, Sep 05, 2011 at 02:51:12PM -0400, Bruce Momjian wrote:
> hubert depesz lubaczewski wrote:
> > On Mon, Sep 05, 2011 at 02:18:18PM -0400, Bruce Momjian wrote:
> > > hubert depesz lubaczewski wrote:
> > > > I'm not sure if it's upgrade thing, or is it because of error in
> > > > ltree/compilat
Excerpts from Tom Lane's message of lun sep 05 16:43:32 -0300 2011:
> Alvaro Herrera writes:
> > I think the proper fix would be to use the /* trick, such as in
> > postmaster.c:
>
> > /*--
> > translator: %s is a noun phrase describing a child process, such
> > as
> >
Jeremy Drake writes:
> On Mon, 5 Sep 2011, Bruce Momjian wrote:
>> What would we investigate except a compiler bug?
> To me, simply chalking it up to some uncharacterized compiler bug is still
> quite a bit of black magic.
If there were some reason to believe either that it wasn't a compiler
bug
Jeremy Drake wrote:
> On Mon, 5 Sep 2011, Bruce Momjian wrote:
>
> > Jeremy Drake wrote:
> > > I think tomorrow I'll try to get the 9.0 compiler set up on a clean VM,
> > > and if the issue duplicates there, I can see about setting up SSH access
> > > if anyone is still interested in investigating
On Mon, 5 Sep 2011, Bruce Momjian wrote:
> Jeremy Drake wrote:
> > I think tomorrow I'll try to get the 9.0 compiler set up on a clean VM,
> > and if the issue duplicates there, I can see about setting up SSH access
> > if anyone is still interested in investigating this further.
>
> What would we
Alvaro Herrera writes:
> I think the proper fix would be to use the /* trick, such as in
> postmaster.c:
> /*--
> translator: %s is a noun phrase describing a child process,
> such as
> "server process" */
> (err
Excerpts from Alvaro Herrera's message of lun sep 05 16:21:38 -0300 2011:
> I just noticed that this comment got reindented by pgindent
> (xlog.c, line 3226 in REL9_1_STABLE):
> /*
> * translator: First %s represents a recovery.conf parameter name like
> * "recovery_end_co
Alvaro Herrera wrote:
> Excerpts from Tom Lane's message of mar mar 15 11:42:06 -0300 2011:
> > "Kevin Grittner" writes:
> > > Tom Lane wrote:
> > >> Dimitri Fontaine writes:
> > >>> Would it help moving toward Leap Second support, and is this
> > >>> something we want to have?
> >
> > >> IMO w
Bruce Momjian writes:
> Did we conclude any of these were useful?
> http://archives.postgresql.org/pgsql-hackers/2011-03/msg00856.php
> I know there were concerns about some of them in the thread.
Hmm, I guess this slipped through the cracks. I thought that avoiding
memcpy(x, x, n) was unn
Alvaro Herrera wrote:
> I just noticed that this comment got reindented by pgindent
> (xlog.c, line 3226 in REL9_1_STABLE):
> /*
>* translator: First %s represents a recovery.conf parameter
> name like
>* "recovery_end_command", and the 2nd is the valu
I just noticed that this comment got reindented by pgindent
(xlog.c, line 3226 in REL9_1_STABLE):
/*
* translator: First %s represents a recovery.conf parameter
name like
* "recovery_end_command", and the 2nd is the value of that
parameter.
Andy Colson writes:
> This patch:
> https://commitfest.postgresql.org/action/patch_view?id=597
> caches the cache because, I guess, the cache is slow.
> Simon asked, "What is making the first cache so slow?". Pavel does not know,
> nor how to fix it, and nobody else responded.
Well, the cache
hubert depesz lubaczewski writes:
> On Mon, Sep 05, 2011 at 02:18:18PM -0400, Bruce Momjian wrote:
>> If I had to take a guess, it would be that there is some ltree
>> incompatibility from PG 8.3 that we didn't know about.
> it's possible.
[ checks the git history... ] This 8.4 commit:
http://g
Noah Misch wrote:
> A suitably-instrumented run of "make installcheck-world" under valgrind turned
> up a handful of memory-related bugs:
>
> * memcpy()/strncpy() between overlapping regions
> uniqueentry() and dispell_lexize() both deduplicate an array by iteratively
> copying elements downward t
Heikki Linnakangas wrote:
> On 11.03.2011 19:41, Tom Lane wrote:
> > Heikki Linnakangas writes:
> >> On 11.03.2011 17:59, Tom Lane wrote:
> >>> But that will be fixed during WAL replay.
> >
> >> Not under the circumstances that started the original thread:
> >
> >> 1. Backend splits a page
> >> 2.
hubert depesz lubaczewski wrote:
> On Mon, Sep 05, 2011 at 02:18:18PM -0400, Bruce Momjian wrote:
> > hubert depesz lubaczewski wrote:
> > > I'm not sure if it's upgrade thing, or is it because of error in
> > > ltree/compilation, but it looks bad.
> > >
> > > Is there any more info I could show/g
Hello
2011/9/5 Andy Colson :
> Pavel, I have not taken on your patch for review, but I was reading the
> history of it, and one question popped up:
>
> If you are allocating a new cache, what if the array is really big, will 1st
> cache + your cache get bigger than work_mem? (or are array op's no
On Mon, Sep 05, 2011 at 02:18:18PM -0400, Bruce Momjian wrote:
> hubert depesz lubaczewski wrote:
> > I'm not sure if it's upgrade thing, or is it because of error in
> > ltree/compilation, but it looks bad.
> >
> > Is there any more info I could show/gather to help debug the issue?
>
> I am conf
Hello
2011/9/5 Andy Colson :
> This patch:
>
> https://commitfest.postgresql.org/action/patch_view?id=597
>
> caches the cache because, I guess, the cache is slow.
>
> Simon asked, "What is making the first cache so slow?". Pavel does not
> know, nor how to fix it, and nobody else responded.
>
>
Excerpts from Bruce Momjian's message of lun sep 05 15:21:46 -0300 2011:
> Alvaro Herrera wrote:
> > Discussed the idea a bit on IM with Bruce, but couldn't find any really
> > good alternative. Idea floated so far:
> >
> > * byte (seems pretty decent to me)
> > * octet (though maybe people woul
Pavel, I have not taken on your patch for review, but I was reading the history
of it, and one question popped up:
If you are allocating a new cache, what if the array is really big, will 1st
cache + your cache get bigger than work_mem? (or are array op's not
constrained by work_mem? Sorry,
Alvaro Herrera wrote:
> Removing CC to pg-docs so that Robert reads it.
>
> Excerpts from Bruce Momjian's message of vie mar 11 08:13:20 -0300 2011:
> > Kevin Grittner wrote:
>
> > > relpersistence should be "char", not char.
> > > Oddly enough, there is a difference.
> >
> > I am unsure on that
This patch:
https://commitfest.postgresql.org/action/patch_view?id=597
caches the cache because, I guess, the cache is slow.
Simon asked, "What is making the first cache so slow?". Pavel does not know,
nor how to fix it, and nobody else responded.
So my question is: is someone going to take
hubert depesz lubaczewski wrote:
> I'm not sure if it's upgrade thing, or is it because of error in
> ltree/compilation, but it looks bad.
>
> Is there any more info I could show/gather to help debug the issue?
I am confused by the error --- is it not loading, or can you get a
backtrace of the cr
Bruce Momjian wrote:
> hubert depesz lubaczewski wrote:
> > On Wed, Aug 31, 2011 at 01:23:05PM -0400, Bruce Momjian wrote:
> > > Can you get me the 9.0.X pg_class.relfrozenxid for the toast and heap
> > > tables involved?
> >
> > Sure:
> >
> > =# select oid::regclass, relfrozenxid from pg_class
On 09/05/2011 12:17 PM, Andy Colson wrote:
Tomas, I cannot seem to see any of the patches you link here:
https://commitfest.postgresql.org/action/patch_view?id=628
Looks like you need to take the < > out of the messageid.
-Andy
This patch seems to solve the problem of going back in time to
Marti Raudsepp writes:
> This simple query shouldn't cause two bitmap index scans:
> EXPLAIN select * from test where b='0';
> Bitmap Heap Scan on test (cost=1056.68..8200.12 rows=29839 width=314)
>Recheck Cond: ((b = 0) AND (b = 0::smallint))
>-> BitmapAnd (cost=1056.68..1056.68 rows
This patch:
https://commitfest.postgresql.org/action/patch_view?id=605
Seems to have been after thoughts, and back burner stuff, and forgotten about...
Has it already been commit?
http://archives.postgresql.org/pgsql-committers/2011-07/msg00206.php
Oh, wait, nevermind, it was revoked and rewo
On Mon, Sep 05, 2011 at 05:48:50PM +0200, hubert depesz lubaczewski wrote:
> On Thu, Sep 01, 2011 at 08:05:51AM +0200, hubert depesz lubaczewski wrote:
> > On Wed, Aug 31, 2011 at 09:54:20PM -0400, Bruce Momjian wrote:
> > > Working with depesz, I have found the cause. The code I added to fix
> >
Robert Haas wrote:
> On Fri, Mar 11, 2011 at 3:59 AM, Fujii Masao wrote:
> > On Fri, Mar 11, 2011 at 5:52 PM, Itagaki Takahiro
> > wrote:
> >> contrib/pg_trgm in 9.1 becomes more attractive feature by index supports
> >> for LIKE operators, but only alphabet and numeric characters are indexed
> >
Tomas, I cannot seem to see any of the patches you link here:
https://commitfest.postgresql.org/action/patch_view?id=628
Looks like you need to take the < > out of the messageid.
-Andy
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
h
Bruce Momjian writes:
> Tom Lane wrote:
>> Did anybody do any performance measurements to demonstrate that this
>> code has a reason to live? Because if I don't see some, I'm going
>> to rip it out.
> Did we decide to keep the cache in attoptcache.c? Is this a TODO?
It's still a TODO, I think
Alvaro Herrera wrote:
> Excerpts from Tom Lane's message of mar mar 01 19:03:35 -0300 2011:
> > Alvaro Herrera writes:
> > > Strangely, we made pg_database have a toast table, and the only reason
> > > for this is datacl. Should we create toast tables for the remaining
> > > catalogs?
> >
> > As
Tom Lane wrote:
> So while poking at a recent example from Marc Cousin (hundreds of tables
> each with 1000 attributes) I observed that a simple ANALYZE would bloat
> the backend process to the tune of several hundred megabytes. I think
> there is a leak in CacheMemoryContext, but haven't tracked
Barring any disastrous bug reports in the next few days, 9.1.0 will be
wrapped Thursday evening for public announcement Monday September 12.
Try not to break the 9.1 branch this week ;-)
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.o
On 05.09.2011 14:10, Heikki Linnakangas wrote:
On 01.09.2011 12:23, Alexander Korotkov wrote:
On Thu, Sep 1, 2011 at 12:59 PM, Heikki Linnakangas<
heikki.linnakan...@enterprisedb.com> wrote:
So I changed the test script to generate the table as:
CREATE TABLE points AS SELECT random() as x, ra
I am writing a talk about the lock manager for PG Open and I would like
suggestions on how to improve a query in my talk. The query creates a
lockinfo_hierarchy view of a recursive query on other views. The output
shows the locks held and the locks being waited for:
\! psql -e -c 'SELECT
Alvaro Herrera writes:
> I am not sure it is really feasible to build a complete graph for all
> headers. We have too many of them and too many dependencies.
Yeah, it's the "too many dependencies" aspect that is bothering me.
The only concrete idea I've come up with so far is that it'd be a goo
hubert depesz lubaczewski wrote:
> On Thu, Sep 01, 2011 at 08:05:51AM +0200, hubert depesz lubaczewski wrote:
> > On Wed, Aug 31, 2011 at 09:54:20PM -0400, Bruce Momjian wrote:
> > > Working with depesz, I have found the cause. The code I added to fix
> > > pg_upgrade in 9.0.4 and earlier releases
On Thu, Sep 01, 2011 at 08:05:51AM +0200, hubert depesz lubaczewski wrote:
> On Wed, Aug 31, 2011 at 09:54:20PM -0400, Bruce Momjian wrote:
> > Working with depesz, I have found the cause. The code I added to fix
> > pg_upgrade in 9.0.4 and earlier releases didn't handle old 8.3 servers
> > proper
On Sun, Sep 04, 2011 at 09:39:39AM -0400, Joe Abbate wrote:
> On 09/04/2011 08:57 AM, Andrew Dunstan wrote:
> > In what locale does 'sc' sort before 's4'? (And I'd humbly suggest that
> > whatever locale it is is possibly broken.)
>
> EBCDIC?
If you have any EBCDIC machines for the buildfarm, tha
Excerpts from Magnus Hagander's message of lun sep 05 11:02:23 -0300 2011:
> On Mon, Sep 5, 2011 at 15:55, Greg Stark wrote:
> > On Mon, Sep 5, 2011 at 2:52 PM, Bruce Momjian wrote:
> >> Well, I assume we are done for another five years. The includes removed
> >> were minimal, especially conside
At the PGCon 2011 PostgreSQL Developer Meeting the CommitFest
schedule for 9.2 development was set. This called for four CFs, one
month each, to start on these dates:
- June 15
- September 15
- November 15
- January 15
We're coming up on the start of the second of those in ten days. I
hav
On Mon, Sep 5, 2011 at 15:55, Greg Stark wrote:
> On Mon, Sep 5, 2011 at 2:52 PM, Bruce Momjian wrote:
>> Well, I assume we are done for another five years. The includes removed
>> were minimal, especially considering five years of work.
>>
>
> What I wouldn't mind seeing is a graph of all inclu
On Mon, Sep 5, 2011 at 2:52 PM, Bruce Momjian wrote:
> Well, I assume we are done for another five years. The includes removed
> were minimal, especially considering five years of work.
>
What I wouldn't mind seeing is a graph of all includes and what they
include. This might help figure out wha
Tom Lane wrote:
> Clean up the #include mess a little.
>
> walsender.h should depend on xlog.h, not vice versa. (Actually, the
> inclusion was circular until a couple hours ago, which was even sillier;
> but Bruce broke it in the expedient rather than logically correct
> direction.) Because of t
Jeremy Drake wrote:
> On Sun, 4 Sep 2011, Tom Lane wrote:
>
> > What I would suggest is to see whether a more recent x86 version shows
> > the problem or not. If not, let's just write it off as an already-fixed
> > compiler bug.
>
> I have installed the most recent version in the home directory
On 2011-09-01 14:40, Robert Haas wrote:
userspace avc.
I've committed this, but I still think it would be helpful to revise
that comment. The turn "boosted up" is not very precise or
informative. Could you submit a separate, comment-only patch to
improve this?
I didn't see my name as one of
> In my usual environment that test passed, but finally I've reproduced the
> failure with setting
> $LC_COLLATE to "es_ES.UTF-8". Do you have set any $LC_COLLATE in your test
> environment?
>
It is not set in my environment.
I checked the behavior of ORDER BY when we set a collation on the reg
On Sun, Sep 4, 2011 at 19:02, Simon Riggs wrote:
> On Fri, Sep 2, 2011 at 6:52 PM, Magnus Hagander wrote:
>
>> Attached patch implements a "low watermark wal location" in the
>> walsender shmem array. Setting this value in a walsender prevents
>> transaction log removal prior to this point - simi
Hi list,
This simple query shouldn't cause two bitmap index scans:
EXPLAIN select * from test where b='0';
Bitmap Heap Scan on test (cost=1056.68..8200.12 rows=29839 width=314)
Recheck Cond: ((b = 0) AND (b = 0::smallint))
-> BitmapAnd (cost=1056.68..1056.68 rows=5237 width=0)
On Sun, 4 Sep 2011, Tom Lane wrote:
> What I would suggest is to see whether a more recent x86 version shows
> the problem or not. If not, let's just write it off as an already-fixed
> compiler bug.
I have installed the most recent version in the home directory of a
purpose-made user on that mac
93 matches
Mail list logo
