John Hansen said:
On Sun, 2004-06-20 at 08:04, Dave Page wrote:
although it says it's clearing the contents of the directory, in
actual fact it leaves the directory structure in place, thus a
subsequent initdb will not run without a manual clearup.
Hm. The rmtree() function in
-Original Message-
From: John Hansen [mailto:[EMAIL PROTECTED]
Sent: Sun 6/20/2004 2:27 AM
To: Dave Page
Cc: Tom Lane; PostgreSQL-development; [EMAIL PROTECTED]
Subject: Re: [HACKERS] Cannot initdb in cvs tip
you could of course rmdir /s /q $PGDATA mkdir $PGDATA if the purpose
is
In checkpoint and background writer, we flush out dirty buffer pages one
page one time. Is it possible to do in a batch mode? That is, try to find
out the continous page(same tblNode, relNode, adjacent blockNum), then write
them together?
To find out continous pages, most cases can be handled by
Hi,
While tracking down a query with a JDBC prepared statement, I
noticed, that the statement actually wasn't prepared but sent to the
server as 'normal' Statement. In my case, this led to a very slow query
since the normal statement does not propagate the correct type -- in my
case I queried an
Attached is a patch implementing this functionality.
I've modified make_new_heap() as well as swap_relfilenodes() to not assume
that tablespaces remain the same from old to new heap. I thought it better
to go down this road than introduce a lot of duplicate code.
I have tried your patches
Attached is a patch implementing this functionality.
I've modified make_new_heap() as well as swap_relfilenodes() to not assume
that tablespaces remain the same from old to new heap. I thought it better
to go down this road than introduce a lot of duplicate code.
I have tried your
Qingqing Zhou [EMAIL PROTECTED] writes:
In checkpoint and background writer, we flush out dirty buffer pages one
page one time. Is it possible to do in a batch mode? That is, try to find
out the continous page(same tblNode, relNode, adjacent blockNum), then write
them together?
What for? The
Hi all.
Since yesterday postgres 7.2.1 (in debian 3.0r1) tell me this error when I
vacuumdb my database.
Why?
Suddenly a lot of data of the same db are disappered.
Only the data of the last pg_restore are again in the db.
Can I recover the lost data?
Mauro
In fact i want this kind of view , because my views are forms with a
jdbc selection like
create view toto (integer,integer) as SELECT a,b FROM executeJDBC(jdbc
connection,jdbc uri, 'select a,b from toto');
Where the view toto is filled by the function executeJDBC (jdbc driver,
Tom Lane wrote:
Shachar Shemesh [EMAIL PROTECTED] writes:
I have defined a datatype called varcharci, shamelessly yanking the
input, output, recv and send functions from varchar. This means (as far
as I understand things) that this type is binary compatible with varchar.
Use text, not
Shachar Shemesh [EMAIL PROTECTED] writes:
Tom Lane wrote:
Yes, it can cast to varchar, but that doesn't help because there are no
varchar operators ;-). To resolve the operator, it has to promote both
sides to text, and you didn't offer a cast to text.
I don't get it.
When we look to see
On Sun, 20 Jun 2004, Tatsuo Ishii wrote:
Attached is a patch implementing this functionality.
I've modified make_new_heap() as well as swap_relfilenodes() to not assume
that tablespaces remain the same from old to new heap. I thought it better
to go down this road than introduce a
OK, looks like the error below is a Win32 thing. The patch attached
#ifdef'd out the permissions check on the private key file as it won't
work under Windows anyway (a similar check in postmaster.c has has
already been ifdef'd out for the same reason).
Incidently, the consts are also used in
On Mon, 21 Jun 2004, Tatsuo Ishii wrote:
On Sun, 20 Jun 2004, Tatsuo Ishii wrote:
Attached is a patch implementing this functionality.
I've modified make_new_heap() as well as swap_relfilenodes() to not assume
that tablespaces remain the same from old to new heap. I
On Sun, 20 Jun 2004, Tatsuo Ishii wrote:
Attached is a patch implementing this functionality.
I've modified make_new_heap() as well as swap_relfilenodes() to not assume
that tablespaces remain the same from old to new heap. I thought it better
to go down this road than
Also I think we need to enhance ALTER INDEX to assign new table spaces
for indexes. Assigning different tables spaces for tables and indexes
are essential to gain more I/O speed IMO.
I thought about this. ALTER INDEX doesn't exist yet and I figured that,
unlike the case of tables, its
On Sun, 2004-06-20 at 17:15, Tatsuo Ishii wrote:
Also I think we need to enhance ALTER INDEX to assign new table spaces
for indexes. Assigning different tables spaces for tables and indexes
are essential to gain more I/O speed IMO.
I thought about this. ALTER INDEX doesn't exist yet
Gavin Sherry [EMAIL PROTECTED] writes:
On Mon, 21 Jun 2004, Tatsuo Ishii wrote:
Also I think we need to enhance ALTER INDEX to assign new table spaces
for indexes. Assigning different tables spaces for tables and indexes
are essential to gain more I/O speed IMO.
I thought about this. ALTER
On Sun, 20 Jun 2004, Tom Lane wrote:
Gavin Sherry [EMAIL PROTECTED] writes:
On Mon, 21 Jun 2004, Tatsuo Ishii wrote:
Also I think we need to enhance ALTER INDEX to assign new table spaces
for indexes. Assigning different tables spaces for tables and indexes
are essential to gain more I/O
Gavin Sherry [EMAIL PROTECTED] writes:
But I did implement it as a tuple at a time thing. I reused the code from
rebuild_relation()...
What did you have in mind?
Something about like
for (b = 0; b RelationGetNumberOfBlocks(src); b++)
{
smgrread(src, b, buf);
On Sun, 20 Jun 2004, Tom Lane wrote:
Gavin Sherry [EMAIL PROTECTED] writes:
But I did implement it as a tuple at a time thing. I reused the code from
rebuild_relation()...
What did you have in mind?
Something about like
for (b = 0; b RelationGetNumberOfBlocks(src); b++)
On Mon, 21 Jun 2004, Tom Lane wrote:
Gavin Sherry [EMAIL PROTECTED] writes:
On Sun, 20 Jun 2004, Tom Lane wrote:
Maybe you have to dump each block into WAL as you copy it.
That would be kinda ugly ... though in point of fact less of a WAL load
than writing individual tuples ...
Should
Gavin Sherry [EMAIL PROTECTED] writes:
On Sun, 20 Jun 2004, Tom Lane wrote:
Maybe you have to dump each block into WAL as you copy it.
That would be kinda ugly ... though in point of fact less of a WAL load
than writing individual tuples ...
Should I use the WAL-enabled case of
Gavin Sherry [EMAIL PROTECTED] writes:
On Mon, 21 Jun 2004, Tatsuo Ishii wrote:
First of all I would like to ask you if you intend to leave indexes in
the old tables space or not.
Yes, that is intentional.
There's a related issue: what about the table's TOAST table (if any)
and the index on
Because I am traveling, I will no longer be reviewing and applying
patches until I return on July 3. Tom will take over most of this duty.
I will check things once I get back to be sure everything got in just so
Tom can relax knowing someone will make sure nothing was missed.
Also, I have
25 matches
Mail list logo
