On Sun, 06 Jan 2008 02:47:17 -0500
Tom Lane [EMAIL PROTECTED] wrote:
Ivan Sergio Borgonovo [EMAIL PROTECTED] writes:
But when I switch to
select into _BasketID1,_BasketID2 _BasketID1,_BasketID2 from
testA(); nothing get back from testB().
I think you've forgotten that plpgsql variables
2008/1/5, Tom Lane [EMAIL PROTECTED]:
Clodoaldo [EMAIL PROTECTED] writes:
How did you get 8.3-beta4?
I built from the source rpm, which i installed in my machine. There is
something I forgot to mention. I created a patch to change
XLOG_SEG_SIZE and built with it:
-#define XLOG_SEG_SIZE
I'm the owner of a database and when i issue an analyze command on it,
the pg tables are skipped with the message that only the owner can
analyze them:
$ psql fahstats -U cpn
Welcome to psql 8.3beta4, the PostgreSQL interactive terminal.
Type: \copyright for distribution terms
\h for
Clodoaldo wrote:
I'm the owner of a database and when i issue an analyze command on it,
the pg tables are skipped with the message that only the owner can
analyze them:
$ psql fahstats -U cpn
Welcome to psql 8.3beta4, the PostgreSQL interactive terminal.
Type: \copyright for distribution
2008/1/6, Magnus Hagander [EMAIL PROTECTED]:
Clodoaldo wrote:
I'm the owner of a database and when i issue an analyze command on it,
the pg tables are skipped with the message that only the owner can
analyze them:
$ psql fahstats -U cpn
Welcome to psql 8.3beta4, the PostgreSQL
On Jan 5, 2008 5:38 AM, Ed L. [EMAIL PROTECTED] wrote:
We need some advice on how to handle some large table autovacuum
issues. One of our 8.1.2 autovacuums is launching a DB-wide
vacuum on our 270GB database to prevent xid wrap-around, but is
getting hung-up and/or bogged down for hours on
On Jan 6, 2008 5:06 AM, Clodoaldo [EMAIL PROTECTED] wrote:
Then I rebuilt and reinstalled postgresql with the xlog_seg_size set
to the default 16MB and did initdb. Now the time is 7,642 sec.
I'm lost. It looks like 1GB xlog_seg_size is indeed faster than 16MB
but again it is slower than the
2008/1/6, Scott Marlowe [EMAIL PROTECTED]:
On Jan 6, 2008 5:06 AM, Clodoaldo [EMAIL PROTECTED] wrote:
Then I rebuilt and reinstalled postgresql with the xlog_seg_size set
to the default 16MB and did initdb. Now the time is 7,642 sec.
I'm lost. It looks like 1GB xlog_seg_size is indeed
I decided to play a bit with 8.3-b4. I did a fresh install from source,
fresh initdb, and created a single test table (about 700K rows) to play
with in-core FTS:
Welcome to psql 8.3beta4, the PostgreSQL interactive terminal.
hannes= \d fts
Table public.fts
Column |
Hannes Dorbath [EMAIL PROTECTED] writes:
hannes= CREATE INDEX CONCURRENTLY ts_fts_tsv ON public.fts USING gin
(tsv);
ERROR: item pointer (0,1) alreadt exists
I was able to reproduce that error a few times, but not always. It seems
it only happens with CONCURRENTLY.
After creating a
Hi.
It can be referred to from the page by which we were renewed.
http://npgsql.projects.postgresql.org/
I want it to be useful for you.
P.S)
[EMAIL PROTECTED] is the place of best discussion.
Regards,
Hiroshi Saito
- Original Message -
From: Cesar Alvarez [EMAIL PROTECTED]
Good
On Jan 6, 2008 1:46 PM, Clodoaldo [EMAIL PROTECTED] wrote:
2008/1/6, Scott Marlowe [EMAIL PROTECTED]:
On Jan 6, 2008 5:06 AM, Clodoaldo [EMAIL PROTECTED] wrote:
Then I rebuilt and reinstalled postgresql with the xlog_seg_size set
to the default 16MB and did initdb. Now the time is
Andrew Sullivan wrote:
On Fri, Jan 04, 2008 at 06:11:40PM -0300, Alvaro Herrera wrote:
swooping elephants must be an interesting sight. If pigs can fly ...
Is this what you had in mind?
http://www.amoeba.com/dynamic-images/blog/dumbo.gif
Hmm, something like that, but Dumbo does not look
On Fri, 2007-11-30 at 09:33 -0500, Andrew Sullivan wrote:
On Fri, Nov 30, 2007 at 01:22:31PM -, Greg Sabino Mullane wrote:
or a scapegoat. Please don't perpetuate this urban myth. No companies are
suing Oracle and Microsoft because of their products, and companies have
no expectation
I recently resized a virtual machine hosting an instance of
PostGreSQL. After the resize and the required reboot, PostGreSQL
seem to be acting a little odd.
As a local user, I can connect to my databases. but my Java
applications can now longer connect to the database. (I get the
Eric D. Nielsen [EMAIL PROTECTED] writes:
I've confirmed from the commandline using
psql -h hostname -p port -U username database
psql: could not connect to server: Connection refused
That's not a Postgres problem. You do not have network-level
connectivity --- I'm betting you forgot to
I'm sorry for my delayed response. Tomasz, thanks for your email.
At 2:38 PM +0100 1/3/08, Tomasz Ostrowski wrote:
On Tue, 01 Jan 2008, Chuck wrote:
I'm not sure how to make sure automatic updates are turned on as
Tometzky recommended. Is that a yum setting?
You need to install and
17 matches
Mail list logo
