On Mon, 2006-03-27 at 12:14 +0900, OKADA Satoshi wrote:
Our aim is giving database recovery chances to a database administrator
at PostgreSQL startup time when there is possibility of data loss of
losing log files.
There is no possibility of data loss because of loss of a single log
file, if
I for one am still struggling with Kerberos on Windows, and
it would be a great help for me to know where to get
libraries and headers from.
The pginstaller README might help you - it contains the steps used to
build it for the installer...
One of my problems is that it needs VC++ to
I for one am still struggling with Kerberos on Windows,
and it would
be a great help for me to know where to get libraries and headers
from.
The pginstaller README might help you - it contains the
steps used to
build it for the installer...
One of my problems is that it
Martijn,
I tried a Socket approach. Using the new IO stuff that arrived with Java 1.4 (SocketChannel
etc.), the performance is really good. Especially on Linux where an SMP machine show a 1 to
1.5 ratio between one process doing ping-pong between two threads and two processes doing
ping-pong
- Postgres intrinsic log-shipping replication (we have one to contribute)
Are you saying you have a working WAL-shipping based portable (means
working well on all platforms) replication already done ? Cause I was
looking into implementing just this one :-)
Do you have some details how it works
On Mon, Mar 27, 2006 at 10:57:21AM +0200, Thomas Hallgren wrote:
Martijn,
I tried a Socket approach. Using the new IO stuff that arrived with Java
1.4 (SocketChannel etc.), the performance is really good. Especially on
Linux where an SMP machine show a 1 to 1.5 ratio between one process
Martijn van Oosterhout wrote:
On Mon, Mar 27, 2006 at 10:57:21AM +0200, Thomas Hallgren wrote:
Martijn,
I tried a Socket approach. Using the new IO stuff that arrived with Java
1.4 (SocketChannel etc.), the performance is really good. Especially on
Linux where an SMP machine show a 1 to 1.5
A thread on -general
(http://archives.postgresql.org/pgsql-general/2006-03/msg01023.php)
recently ended in the idea that the pgAdmin 'adminpack' be included as
an 'official' PostgreSQL contrib module. Currently the code is an add-on
available from the pgAdmin website, unless you run the Windows
Am Montag, 27. März 2006 15:12 schrieb Dave Page:
So, how would people feel about including this as
a contrib module in the future, until(/if) equivalent functionality
becomes available in -core in some form?
Right now you have got plenty of time to get it in shape for inclusion in
core, so
-Original Message-
From: Peter Eisentraut [mailto:[EMAIL PROTECTED]
Sent: Mon 3/27/2006 3:00 PM
To: pgsql-hackers@postgresql.org
Cc: Dave Page
Subject: Re: [HACKERS] Remote administration contrib module
Am Montag, 27. März 2006 15:12 schrieb Dave Page:
So, how would people feel
[ redirecting to a more appropriate mailing list ]
Alex bahdushka [EMAIL PROTECTED] writes:
LOG: REDO @ D/19176610; LSN D/19176644: prev D/191765E8; xid 81148979: Heap
- clean: rel 1663/16386/16559898; blk 0
LOG: REDO @ D/19176644; LSN D/191766A4: prev D/19176610; xid 81148979: Heap
-
Simon Riggs [EMAIL PROTECTED] writes:
On Mon, 2006-03-27 at 12:14 +0900, OKADA Satoshi wrote:
Our aim is giving database recovery chances to a database administrator
at PostgreSQL startup time when there is possibility of data loss of
losing log files.
There is no possibility of data loss
Thomas Hallgren [EMAIL PROTECTED] writes:
The real downside is that a call from SQL to PL/Java using the current
in-process approach is really fast. It takes about 5 micro secs on my
2.8GHz i386 box. The overhead of an IPC-call on that box is about 18
micro secs on Linux and 64 micro secs on
Tom Lane wrote:
It's only that much difference? Given all the other advantages of
separating the JVM from the backends, I'd say you should gladly pay
that price.
If I'm right, and the most common scenario is clients using connection pools, then it's very
likely that you don't get any
Thomas Hallgren [EMAIL PROTECTED] writes:
Tom Lane wrote:
It's only that much difference? Given all the other advantages of
separating the JVM from the backends, I'd say you should gladly pay
that price.
If I'm right, and the most common scenario is clients using connection pools,
then
elein [EMAIL PROTECTED] writes:
But I like the idea of centralizing the check in the input/output
functions. It seems clearer and cleaner.
I remembered the problem with doing it that way: an input function can't
enforce a domain NOTNULL constraint, because it won't even get invoked
for a null
See $SUBJECT. It seems to me this is a bad idea for much the same
reasons that we recently decided default index operator classes should
not be namespace-specific:
http://archives.postgresql.org/pgsql-hackers/2006-02/msg00284.php
I don't mind having encoding conversions be named within schemas,
Tom Lane wrote:
Thomas Hallgren [EMAIL PROTECTED] writes:
Tom Lane wrote:
It's only that much difference? Given all the other advantages of
separating the JVM from the backends, I'd say you should gladly pay
that price.
If I'm right, and the most common scenario is clients
Hello
Current EXECUTE statemtn doesn't support other way for parametrisation than
concating strings. It works well but it's little bit unreadable. Oracle's
statement EXECUTE has positional replacement feature. It works similar our
RAISE statement (when position holder is %). EXECUTE position
Pavel Stehule [EMAIL PROTECTED] writes:
Current EXECUTE statemtn doesn't support other way for parametrisation than
concating strings. It works well but it's little bit unreadable. Oracle's
statement EXECUTE has positional replacement feature.
...
There are some problems about replacing
Tom Lane [EMAIL PROTECTED] writes:
I think what's happened here is that VACUUM FULL moved the only tuple
off page 1 of the relation, then truncated off page 1, and now
heap_update_redo is panicking because it can't find page 1 to replay the
move. Curious that we've not seen a case like this
Greg Stark [EMAIL PROTECTED] writes:
This sounds familiar
http://archives.postgresql.org/pgsql-hackers/2005-05/msg01369.php
Hm, I had totally forgotten about that todo item :-(. Time to push it
back up the priority list.
regards, tom lane
On Mon, Mar 27, 2006 at 11:41:30AM -0500, Tom Lane wrote:
elein [EMAIL PROTECTED] writes:
But I like the idea of centralizing the check in the input/output
functions. It seems clearer and cleaner.
I remembered the problem with doing it that way: an input function can't
enforce a domain
elein [EMAIL PROTECTED] writes:
On Mon, Mar 27, 2006 at 11:41:30AM -0500, Tom Lane wrote:
I remembered the problem with doing it that way: an input function can't
enforce a domain NOTNULL constraint, because it won't even get invoked
for a null input value. So there seems no way around having
See $SUBJECT. It seems to me this is a bad idea for much the same
reasons that we recently decided default index operator classes should
not be namespace-specific:
http://archives.postgresql.org/pgsql-hackers/2006-02/msg00284.php
I don't mind having encoding conversions be named within
Tatsuo Ishii [EMAIL PROTECTED] writes:
I don't mind having encoding conversions be named within schemas,
but I propose that any given encoding pair be allowed to have only
one default conversion, period, and that when we are looking for
a default conversion we find it by a non-namespace-aware
Tom Lane said:
Tatsuo Ishii [EMAIL PROTECTED] writes:
I don't mind having encoding conversions be named within schemas, but
I propose that any given encoding pair be allowed to have only one
default conversion, period, and that when we are looking for a
default conversion we find it by a
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane said:
What does it mean to have different default encoding conversions in
different schemas? Even if this had a sensible interpretation, I don't
think the existing code implements it properly.
perhaps I'm misunderstanding, but why not just
Tom Lane said:
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane said:
What does it mean to have different default encoding conversions in
different schemas? Even if this had a sensible interpretation, I
don't think the existing code implements it properly.
perhaps I'm misunderstanding,
Greg Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
I think what's happened here is that VACUUM FULL moved the only tuple
off page 1 of the relation, then truncated off page 1, and now
heap_update_redo is panicking because it can't find page 1 to replay the
move. Curious
Hi folks after discussing this on IRC today (thanks G_SabinoMullane!), I'm
still surprised by this behaviour on 8.1.3:
pyarra=# create TABLESPACE spctables location '/mnt/pg_tables/data';
CREATE TABLESPACE
pyarra=# create table foo(id int) tablespace spctables;
CREATE TABLE
pyarra=# \d foo
31 matches
Mail list logo
