Tom Lane wrote:
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
...Further those who have provided reasonable contribution really should be
mentioned on the contributors page that is up for discussion which would
make the rest of this moot yes?
I don't have any objection to listing people on th
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> ...Further those who have provided reasonable contribution really should be
> mentioned on the contributors page that is up for discussion which would
> make the rest of this moot yes?
I don't have any objection to listing people on the contributor
Tom Lane wrote:
As of CVS HEAD, some of the contrib module documentation pages have
extensive credit screeds, eg
http://developer.postgresql.org/pgdocs/postgres/cube.html
and some just have the author's name, with or without an link,
and some don't have anything at all.
I don't have a strong
"Walter Cruz" <[EMAIL PROTECTED]> writes:
> My initdb was:
> initdb -E LATIN1 --locale=pt_BR
> By that initdb, the $LANG of the system was pt_BR.UTF-8 .
> A simple query that shows the problem:
> select true AS
> "áaaa"
OK, I was able to
Tom Lane wrote:
As of CVS HEAD, some of the contrib module documentation pages have
extensive credit screeds, eg
http://developer.postgresql.org/pgdocs/postgres/cube.html
and some just have the author's name, with or without an link,
and some don't have anything at all.
This bothers me; it seem
As of CVS HEAD, some of the contrib module documentation pages have
extensive credit screeds, eg
http://developer.postgresql.org/pgdocs/postgres/cube.html
and some just have the author's name, with or without an link,
and some don't have anything at all.
This bothers me; it seems like we should h
While using PostgreSQL 8.1.4 for Windows on Windows XP (SP2),
the following errors had occurred.
-
2007-10-11 12:38:21 LOG: autovacuum: processing database "hoge"
2007-10-11 12:38:21 ERROR: xlog flush request 0/2BEB2198 is not satisfied ---
flushed only to 0/2BE32740
2007-10-11 12:38:21 CO
On Wed, 5 Dec 2007, Alvaro Herrera wrote:
Bruce Momjian wrote:
In an attempt to move us toward 8.3 RC1 I have put all open item emails
into the patches queue:
http://momjian.postgresql.org/cgi-bin/pgpatches
FWIW it seems the only remaining issue is the ltree bug #3720:
http://archiv
Magnus Hagander wrote:
On Tue, Dec 04, 2007 at 09:31:30AM -0500, Andrew Dunstan wrote:
Magnus Hagander wrote:
My recollection is that I changed the minimum amount necessary, because
I was expecting us to go into beta at anmy moment (silly me). That might
be why we still have both. Th
Bruce Momjian wrote:
> In an attempt to move us toward 8.3 RC1 I have put all open item emails
> into the patches queue:
>
> http://momjian.postgresql.org/cgi-bin/pgpatches
FWIW it seems the only remaining issue is the ltree bug #3720:
http://archives.postgresql.org/pgsql-bugs/2007-11/msg0
On Dec 5, 2007 3:26 PM, Greg Sabino Mullane <[EMAIL PROTECTED]> wrote:
> Agreed, this would be a nice 8.4 thing. But what about 8.3 and 8.2? Is
> there a reason not to make this change? I know I've been lazy and not run
> any absolute figures, but rough tests show that raising it (from 10 to
> 100)
Hi,
First, I'm not sure this mail should go to this mailing list. As it
refers to source code (mainly src/backend/postmaster/bgwriter.c and
src/backend/access/transam/xlog.c), I sent it here. I apologize if I'm
wrong.
I'm a bit puzzled by the different informations I can read on the
documentation
Patrick Welche wrote:
> I know that it doesn't matter as configure is in CVS, so there is no
> need for mere mortals to regenerate it, but why is
>
> RCS file: /projects/cvsroot/pgsql/configure.in,v
> revision 1.538
> date: 2007/11/26 12:31:07; author: petere; state: Exp; lines: +2 -2
>
Yes, I did.
What have I done.
My Linux version: Debian Etch.
My Postgres version:
"PostgreSQL 8.2.5 on x86_64-unknown-linux-gnu, compiled by GCC gcc
(GCC) 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)"
It was compiled by myself.
My initdb was:
initdb -E LATIN1 --locale=pt_BR
By that initdb,
I know that it doesn't matter as configure is in CVS, so there is no
need for mere mortals to regenerate it, but why is
RCS file: /projects/cvsroot/pgsql/configure.in,v
revision 1.538
date: 2007/11/26 12:31:07; author: petere; state: Exp; lines: +2 -2
Require a specific Autoconf version
On Dec 4, 2007 7:19 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Walter Cruz" <[EMAIL PROTECTED]> writes:
> > I posted on hackers cause I think that was a bug, os something.
>
> Yeah, I think so too. Can you extract a reproducible test case?
I'm trying to extract that case!
[]'s
- Walter
On Tue, Dec 04, 2007 at 09:31:30AM -0500, Andrew Dunstan wrote:
>
>
> Magnus Hagander wrote:
> >>My recollection is that I changed the minimum amount necessary, because
> >>I was expecting us to go into beta at anmy moment (silly me). That might
> >>be why we still have both. There was an expec
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Simon spoke:
> The choice of 100 is because of the way the LIKE estimator is
> configured. Greg is not suggesting he measured it and found 100 to be
> best, he is saying that the LIKE operator is hard-coded at 100 and so
> the stats_target shoul
Am Dienstag, 4. Dezember 2007 schrieb Tom Lane:
> The particular
> cases that were biting Devrim seemed to all be occurrences of <>
> which perhaps is an allowed tag in his release.
<> means whatever the last opening tag was (much like ). So it should
definitely be escaped.
--
Peter Eisentraut
On Fri, 2007-11-30 at 13:07 -0500, Tom Lane wrote:
> FWIW, I tend to agree with the folks who think Bruce trimmed too much
> this time. But the release notes are, and always have been, intended to
> boil the CVS history down to something useful by eliminating irrelevant
> detail.
OK, so given e
What it turns out is hard to determine is whether the column was stored
externally. To do that you have to rely on the trick of checking
pg_column_size(table.*) and that only works if it's the only column likely to
be stored externally.
--
Gregory Stark
EnterpriseDB http://www.enter
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> On Wed, 2007-12-05 at 08:24 +, Gregory Stark wrote:
>> "Tom Lane" <[EMAIL PROTECTED]> writes:
>>
>> > Simon Riggs <[EMAIL PROTECTED]> writes:
>> >> I'm thinking that there isn't any way currently of working out how big a
>> >> compressed toast objec
Simon Riggs wrote:
That sounds more like what I was after.
So let me check my understanding: For TOASTed data pg_column_size()
tells you how many bytes the column value occupies when decompressed. So
there isn't any way of finding out how many bytes a column value
actually occupies when it is
On Wed, 2007-12-05 at 08:24 +, Gregory Stark wrote:
> "Tom Lane" <[EMAIL PROTECTED]> writes:
>
> > Simon Riggs <[EMAIL PROTECTED]> writes:
> >> I'm thinking that there isn't any way currently of working out how big a
> >> compressed toast object is?
> >
> > pg_column_size() ?
>
> I was going
On Dec 4, 2007 7:47 PM, Peter Childs <[EMAIL PROTECTED]> wrote:
>
>
> On 04/12/2007, Aftab Hussain <[EMAIL PROTECTED]> wrote:
> >
> >
> > Hi all,
> >
> > I have a patch which tries to improve the '\d some_sequence_name'
> > command output in psql utility. Before sending the patch to pgsql-patches
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Simon Riggs <[EMAIL PROTECTED]> writes:
>> I'm thinking that there isn't any way currently of working out how big a
>> compressed toast object is?
>
> pg_column_size() ?
I was going to send the same thing but I think he's looking for the compressed
size of
26 matches
Mail list logo
