ITAGAKI Takahiro wrote:
There is UnusedLock1 in LWLockId enumerations in storage/lwlock.h .
| UnusedLock1,/* FreeSpaceMapLock used to be
here */
I thought it is for keeping LWLockId same as 8.3 at first,
but we've already split SInvalLock to SInvalReadLock and
On Tue, Mar 3, 2009 at 3:33 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Because it would be the wrong answer, except in the uncommon case where
the field values are completely independent (at least, I would expect
that to be uncommon when people have multicolumn indexes on them).
Actually I think
On Mon, 2009-03-02 at 21:11 -0500, Robert Treat wrote:
On Wednesday 25 February 2009 16:43:54 Simon Riggs wrote:
On Wed, 2009-02-25 at 13:33 -0800, Josh Berkus wrote:
You raised that as an annoyance previously because it means that
connection in hot standby mode may be delayed in cases
there will be planned maintenance tomorrow(4 March 2009) from 09:00 to
10:00 CET for the following servers and corresponding services:
barzan.postgresql.org - affecting:
* xindi.postgresql.org (wiki.postgresql.org)
* rakhar.postgresql.org (planet.postgresql.org)
* pentarus.postgresql.org
hi all,
After Andrew corrected the bug I found on pg_restore (-C -m misbehaving
one with the other), I played again yesterday.
before the end of restore, I get this :
pg_restore: launching item 4202 INDEX idx_typeper_actif
pg_restore: [custom archiver] could not close archive file: Argument
o...@pyrenet.fr wrote:
hi all,
After Andrew corrected the bug I found on pg_restore (-C -m
misbehaving one with the other), I played again yesterday.
before the end of restore, I get this :
pg_restore: launching item 4202 INDEX idx_typeper_actif
pg_restore: [custom archiver] could not
Dne 2.03.09 08:59, Heikki Linnakangas napsal(a):
Fujii Masao wrote:
On Fri, Feb 27, 2009 at 6:52 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
I'm leaning towards option 3, but I wonder if anyone sees a better
solution.
4. Use the shared memory to tell the startup
All,
Who's looking at SEPostgres other than Jaime and Tom? Do we have any
other reviewers?
We could get this closed out faster with a couple more.
--Josh
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
Zdenek Kotala wrote:
Dne 2.03.09 08:59, Heikki Linnakangas napsal(a):
Fujii Masao wrote:
On Fri, Feb 27, 2009 at 6:52 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
I'm leaning towards option 3, but I wonder if anyone sees a better
solution.
4. Use the shared memory to
Hi,
I noticed that if you start from a clean tree, it doesn't work to build
pg_dump because gram.h has not been generated yet:
make -C ../../../src/backend/parser keywords.o
make[1]: Entering directory
`/home/alvherre/Code/CVS/pgsql/build/00head/src/backend/parser'
gcc -O0 -Wall
Alvaro Herrera wrote:
Hi,
I noticed that if you start from a clean tree, it doesn't work to build
pg_dump because gram.h has not been generated yet:
make -C ../../../src/backend/parser keywords.o
make[1]: Entering directory
`/home/alvherre/Code/CVS/pgsql/build/00head/src/backend/parser'
Alvaro Herrera alvhe...@commandprompt.com writes:
Alvaro Herrera wrote:
I noticed that if you start from a clean tree, it doesn't work to build
pg_dump because gram.h has not been generated yet:
This patch fixes it.
I think this is probably going in the wrong direction. The reason
gram.h
After some discussion the pgsql-security team has decided that we must
treat this bug as a security issue:
http://archives.postgresql.org/pgsql-bugs/2009-02/msg00172.php
because an unprivileged user can crash his backend and thereby create
a denial-of-service situation. There's no point in
Tom Lane wrote:
I think this is probably going in the wrong direction. The reason
gram.h isn't already in the main include tree is that we don't *want*
all and sundry depending on it --- we have very carefully minimized
the number of files that depend on the grammar's symbol codes.
ISTM
Hi,
On Mon, Mar 2, 2009 at 4:59 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Fujii Masao wrote:
On Fri, Feb 27, 2009 at 6:52 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
I'm leaning towards option 3, but I wonder if anyone sees a better
solution.
This is my first patch. I hope it's not stupid.
We ran into a little issue today where permission/ownership on
pg_hba.conf was accidentally changed to something that the postgres user
could not read. When a SIGHUP was issued, the postmaster quit. That was
kind of a bummer.
From the comment in
Hi all,
It looks like the behavior of regclass is not consistent when table
names are quoted. The name is returned without the quotes if the name is
lower case with eventual trailing numbers, otherwise it is returned with
quotes.
See some examples here:
tpch=# CREATE VIEW test AS SELECT *
Emmanuel Cecchet m...@asterdata.com writes:
It looks like the behavior of regclass is not consistent when table
names are quoted. The name is returned without the quotes if the name is
lower case with eventual trailing numbers, otherwise it is returned with
quotes.
It's intentional that it
Selena Deckelmann sel...@endpoint.com writes:
From the comment in hba.c, it appears that the desired behavior is to
have the system ignore the failure,
I'm not sure how you could possibly read that comment that way.
It might be sane to distinguish initial load from reload, but I think
the
On Tuesday 03 March 2009 03:22:30 Simon Riggs wrote:
On Mon, 2009-03-02 at 21:11 -0500, Robert Treat wrote:
On Wednesday 25 February 2009 16:43:54 Simon Riggs wrote:
On Wed, 2009-02-25 at 13:33 -0800, Josh Berkus wrote:
You raised that as an annoyance previously because it means that
Tom Lane wrote:
Selena Deckelmann sel...@endpoint.com writes:
From the comment in hba.c, it appears that the desired behavior is to
have the system ignore the failure,
I'm not sure how you could possibly read that comment that way.
Right. Sorry, poor choice of words. I meant don't die on
21 matches
Mail list logo
