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 a
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
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
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 nonstan
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
> >co
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 th
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 c
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
>mis
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 in
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
> 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 t
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,
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 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 templa
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 wh
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_
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
Curt Sampson wrote:
> 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 older copie
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
OK, can we better document that GUC client_encoding is broken, then fix
in 7.4?
---
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Yep. Tatsuo, you should apply the patch to fix the problem. Shame this
> >
mlw <[EMAIL PROTECTED]> wrote:
> I am an old fashion UNIX guy, capability without enforcing policy!
> Adding an ability is different than enforcing a policy.
You can push this too far, though. Every capability that
you add still complicates testing and documentation, even if
very difficult t
mlw <[EMAIL PROTECTED]> writes:
> I would really like to push back this whole discussion to adding the
> ability the flexibility to configure PostgreSQ as opposed to determining
> a specific configuration strategy.
> Adding the ability is easy. Let the distros determine their strategy.
> Trying
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
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
/etc/postg
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 would not be acceptable. (Unless those really aren't
I think so - Gavin? As far as I'm aware there's not really anything else
on the open source circuit. There is often a MySQL rep there as well
apparently.
Chris
On Fri, 14 Feb 2003, Bruce Momjian wrote:
>
> Is Linux.conf.au the event PostgreSQL should use for coverage in
> Australia next year?
You can just turn it on in one second in your postgresql.conf file...
Chris
On Fri, 14 Feb 2003, Kevin Brown wrote:
>
> One of the functions of the DBA is to monitor what people are doing to
> the database. My experience is that "ps" is often sorely lacking in
> this regard: its output is somew
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 nee
On Thu, 13 Feb 2003, Tom Lane wrote:
> "Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> > What I mean is say you have an enterprise server doing heaps of transactions
> > with lots of work. If you have scads of RAM, could you just shove up
> > wal_buffers really high and assume it will imp
On Fri, 14 Feb 2003, Bruce Momjian wrote:
> Is there a TODO here, like "Allow recovery from corrupt pg_control via
> WAL"?
Isn't that already in section 12.2.1 of the documentation?
Using pg_control to get the checkpoint position speeds up the
recovery process, but to handle possible c
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 y
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 save
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
33 matches
Mail list logo
