On Fri, 14 Feb 2003, Kevin Brown wrote:
Oracle has something they call rollback segments which I assume are
separate bits of data that have enough information to reverse changes
that were made to the database during a transaction, and I figured
PITR would (or could) apply particular saved
No, not really - I can do some more testing with pgbench to see what
happens though...I'll do it on monday
Chris
On Fri, 14 Feb 2003, Tom Lane wrote:
Manfred Koizar [EMAIL PROTECTED] writes:
In postgresql.conf.sample-writeheavy you have:
commit_delay = 1
Is this still needed with
Martin Coxall wrote:
On Thu, 2003-02-13 at 20:28, Steve Crawford wrote:
I don't see why we can't keep everyone happy and let the users choose the
setup they want. To wit, make the following, probably simple, changes:
1) Have postgresql default to using /etc/postgresql.conf
Curt Sampson [EMAIL PROTECTED] writes:
Oracle9i has a new feature called a flashback query, which uses the
information in the rollback segements to let you query the database
in a previous state. (I.e., select such and such from this table as
of two hours ago.) Postgres could do this using the
Kevin,
Hi. I was looking into PITR for PostgreSQL myself about a year back but
life intervened. I am an Oracle DBA so may be able to help you with an
understanding of how Oracle does this.
You wrote:
Oracle has something they call rollback segments which I assume are
separate bits of data
I have been playing around with psql's tab-completion.c and have
something approaching a sane solution for tab expansion of
schema names. As this seems to fall under the todo item Allow psql to do
table completion for SELECT * FROM schema_part and table completion for
SELECT * FROM schema_name I
On Sat, 2003-02-15 at 18:53, Ian Barwick wrote:
I have been playing around with psql's tab-completion.c and have
something approaching a sane solution for tab expansion of
schema names. As this seems to fall under the todo item Allow psql to do
table completion for SELECT * FROM schema_part
On Sunday 16 February 2003 01:10, Rod Taylor wrote:
I've been debating a mechanism which could build tab completion tables
based on the documentation for a while now -- and was going to give it a
try next week. If it works, that file would essentially disappear.
OK, will hold off and see what
On Friday 14 February 2003 11:02, Shridhar Daithankar wrote:
Especially the whole discussion of PGDATA stuff fails to register as
significant IMO. Right now, I can do things the way I want to do and I
guess it is pretty much same with everyone else. Is it last topic left to
improve?
If it
On Sun, Feb 16, 2003 at 01:34:34AM +0100, Ian Barwick wrote:
On Sunday 16 February 2003 01:10, Rod Taylor wrote:
I've been debating a mechanism which could build tab completion tables
based on the documentation for a while now -- and was going to give it a
try next week. If it works, that
On Sat, 2003-02-15 at 19:49, Ross J. Reedstrom wrote:
On Sun, Feb 16, 2003 at 01:34:34AM +0100, Ian Barwick wrote:
On Sunday 16 February 2003 01:10, Rod Taylor wrote:
I've been debating a mechanism which could build tab completion tables
based on the documentation for a while now -- and
Tom Lane wrote:
Currently, I don't need to do anything more than set PGDATA or say -D
to initdb in order to set up the data directory wherever I like. I also
don't need to worry about whether I'm selecting the wrong config file.
So in your case, what's the advantage of having initdb write
Curt Sampson [EMAIL PROTECTED] writes:
... But there's really no need for all fifty of those,
if you don't mind not being able to restore to any time before the
current time.
Which, of course, is exactly the point of PITR designs.
When you know that your assistant trainee DBA deleted most of
On Sat, 15 Feb 2003, Tom Lane wrote:
Curt Sampson [EMAIL PROTECTED] writes:
... But there's really no need for all fifty of those,
if you don't mind not being able to restore to any time before the
current time.
Which, of course, is exactly the point of PITR designs.
When you know that
On Friday 14 February 2003 15:10, Tom Lane wrote:
I don't see why we don't just let initdb install suggested config files
into the new $PGDATA directory, same as it ever did.
Ok, let me take another tack.
Just exactly why does initdb need to drop any config files anywhere? We
provide
OK, can we better document that GUC client_encoding is broken, then fix
in 7.4?
Actually the problem can be divided into two parts:
1) backend does not process GUC client_encoding.
2) libpq does not ask the backend's client_encoding, instead it asks
datanbase encoding when it starts up
Lamar Owen [EMAIL PROTECTED] writes:
Just exactly why does initdb need to drop any config files anywhere?
Because we'd like it to edit the correct datadir into the config file,
to take just the most obvious example. There has also been a great deal
of discussion recently about other things
Tatsuo Ishii [EMAIL PROTECTED] writes:
Actually the problem can be divided into two parts:
1) backend does not process GUC client_encoding.
2) libpq does not ask the backend's client_encoding, instead it asks
datanbase encoding when it starts up the connection. This is just a
mistake.
On Saturday 15 February 2003 20:19, Tom Lane wrote:
Lamar Owen [EMAIL PROTECTED] writes:
Just exactly why does initdb need to drop any config files anywhere?
Because we'd like it to edit the correct datadir into the config file,
to take just the most obvious example.
Shouldn't we be
Lamar Owen [EMAIL PROTECTED] writes:
On Saturday 15 February 2003 20:19, Tom Lane wrote:
Lamar Owen [EMAIL PROTECTED] writes:
Just exactly why does initdb need to drop any config files anywhere?
Because we'd like it to edit the correct datadir into the config file,
to take just the most
On Saturday 15 February 2003 09:48 am, mlw wrote:
Robert Treat wrote:
Seems like some are saying one of the problems with the current system
is it doesn't follow FHS or LSB. If those are valid reasons to change
the system, it seems like a change which doesn't actually address those
concerns
On Saturday 15 February 2003 21:06, Tom Lane wrote:
Lamar Owen [EMAIL PROTECTED] writes:
Shouldn't we be consistent and have initdb use the datadir set in the
config file, which could be supplied by a ./configure switch?
That'd mean there is no way to perform an initdb into a nonstandard
Lamar Owen [EMAIL PROTECTED] writes:
I realize that from a packager's point of view, the separate initdb step
is not very useful. But it is from my point of view.
Would you mind elucidating which point of view is yours?
Primarily, one that wants to have multiple postmasters running, of the
On Sunday 16 February 2003 00:16, Tom Lane wrote:
Lamar Owen [EMAIL PROTECTED] writes:
Would you mind elucidating which point of view is yours?
Primarily, one that wants to have multiple postmasters running, of the
same or different versions; including test and temporary installations
that
24 matches
Mail list logo
