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
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
>> mov
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
"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 w
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 fin
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-namespa
> 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 withi
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 aroun
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
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
--
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
"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 repla
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 h
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 us
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,
b
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 nu
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 pool
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 advantage
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
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 dat
[ 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
-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 abo
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
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
pgI
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 r
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 proces
> - 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
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 u
> >> 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 proble
>> 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+
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, i
31 matches
Mail list logo
