Attached is updated SP-GiST patch, which provides full logging support and
fixed several bugs (Thanks ALexander Korotkov for help).
Regards,
Oleg
On Thu, 1 Sep 2011, Oleg Bartunov wrote:
This is updates SP-GiST patch, which fixed one bug and replaced test to the
locale independent one.
On
I attached wrong patch in previous message, sorry ! Here is a last version.
This is a new WIP of SP-GiST patch, which provides support for:
1. Concurrent vacuum
2. Vacuum logging
3. WAL replay
Oleg
On Thu, 1 Sep 2011, Oleg Bartunov wrote:
This is updates SP-GiST patch, which fixed one bug and
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
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, Sep 4, 2011 at 19:02, Simon Riggs si...@2ndquadrant.com wrote:
On Fri, Sep 2, 2011 at 6:52 PM, Magnus Hagander mag...@hagander.net wrote:
Attached patch implements a low watermark wal location in the
walsender shmem array. Setting this value in a walsender prevents
transaction log
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 regular
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
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 of a
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 that
On Mon, Sep 5, 2011 at 2:52 PM, Bruce Momjian br...@momjian.us 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
On Mon, Sep 5, 2011 at 15:55, Greg Stark st...@mit.edu wrote:
On Mon, Sep 5, 2011 at 2:52 PM, Bruce Momjian br...@momjian.us 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
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
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 st...@mit.edu wrote:
On Mon, Sep 5, 2011 at 2:52 PM, Bruce Momjian br...@momjian.us wrote:
Well, I assume we are done for another five years. The includes removed
were
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, that'd be
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
properly. I
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 didn't
Alvaro Herrera alvhe...@commandprompt.com 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
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
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,
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
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 it
Alvaro Herrera wrote:
Excerpts from Tom Lane's message of mar mar 01 19:03:35 -0300 2011:
Alvaro Herrera alvhe...@alvh.no-ip.org 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?
Bruce Momjian br...@momjian.us 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,
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:
Robert Haas wrote:
On Fri, Mar 11, 2011 at 3:59 AM, Fujii Masao masao.fu...@gmail.com wrote:
On Fri, Mar 11, 2011 at 5:52 PM, Itagaki Takahiro
itagaki.takah...@gmail.com wrote:
contrib/pg_trgm in 9.1 becomes more attractive feature by index supports
for LIKE operators, but only alphabet
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
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
Marti Raudsepp ma...@juffo.org 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
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
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 where relname in
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
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 a
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 typechar/type, not typechar/type.
Oddly enough, there is a difference.
I am unsure on
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,
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 would expect
Hello
2011/9/5 Andy Colson a...@squeakycode.net:
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
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 confused by
Hello
2011/9/5 Andy Colson a...@squeakycode.net:
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
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/gather to help
Heikki Linnakangas wrote:
On 11.03.2011 19:41, Tom Lane wrote:
Heikki Linnakangasheikki.linnakan...@enterprisedb.com 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
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 to
hubert depesz lubaczewski dep...@depesz.com 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
Andy Colson a...@squeakycode.net 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.
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.
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 value of
Bruce Momjian br...@momjian.us 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,
Alvaro Herrera wrote:
Excerpts from Tom Lane's message of mar mar 15 11:42:06 -0300 2011:
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Tom Lane t...@sss.pgh.pa.us wrote:
Dimitri Fontaine dimi...@2ndquadrant.fr writes:
Would it help moving toward Leap Second support, and is this
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
*
Alvaro Herrera alvhe...@alvh.no-ip.org 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 */
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
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 this
Jeremy Drake pg...@jdrake.com 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
Excerpts from Tom Lane's message of lun sep 05 16:43:32 -0300 2011:
Alvaro Herrera alvhe...@alvh.no-ip.org 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,
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/compilation, but it
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
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
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 because of
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 lubaczewski
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 \
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
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 because of
Bruce Momjian br...@momjian.us 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.
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 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
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
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
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
On 2 Září 2011, 22:04, Tom Lane wrote:
Tomas Vondra t...@fuzzy.cz 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 be
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 typechar/type, not
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
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
pg_type name is
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,
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
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
that name came
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:
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 archives of
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
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 br...@momjian.us 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
Robert Haas wrote:
On Wed, Mar 23, 2011 at 1:48 AM, Fujii Masao masao.fu...@gmail.com wrote:
On Sat, Mar 19, 2011 at 10:20 AM, Robert Haas robertmh...@gmail.com wrote:
On Fri, Mar 18, 2011 at 1:19 PM, Erik Rijkers e...@xs4all.nl wrote:
This is OK and expected. ?But then it continues (in the
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 not
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 9.0.4. I
On Fri, Sep 2, 2011 at 12:45 PM, Tom Lane t...@sss.pgh.pa.us 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
On Mon, Sep 5, 2011 at 9:14 AM, Yeb Havinga yebhavi...@gmail.com 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
On Mon, Sep 5, 2011 at 1:01 PM, Bruce Momjian br...@momjian.us wrote:
Alvaro Herrera wrote:
Excerpts from Tom Lane's message of mar mar 01 19:03:35 -0300 2011:
Alvaro Herrera alvhe...@alvh.no-ip.org writes:
Strangely, we made pg_database have a toast table, and the only reason
for this
On Mon, Sep 5, 2011 at 1:56 PM, Andy Colson a...@squeakycode.net 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?
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 clogs out of
On Mon, Sep 5, 2011 at 2:02 PM, Andy Colson a...@squeakycode.net 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
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 yebhavi...@gmail.com 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
On Mon, Sep 5, 2011 at 6:56 PM, Alvaro Herrera
alvhe...@commandprompt.com 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
On Mon, Sep 5, 2011 at 10:52 PM, Alvaro Herrera
alvhe...@commandprompt.com 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 yebhavi...@gmail.com wrote:
On 2011-09-01 14:40, Robert Haas wrote:
userspace avc.
I've
On Mon, Sep 5, 2011 at 7:52 PM, Tomas Vondra t...@fuzzy.cz 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
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 worth
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
alvhe...@commandprompt.com 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 yebhavi...@gmail.com
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
94 matches
Mail list logo
