On Fri, 14 Feb 2003, Bruce Momjian wrote:
> OK, once we have PITR, will anyone want incremental backups?
Well, I'm not entirely clear on how PITR will work, so I may be off-base
here, but it seems to me that offering incremental backups that back
up only changed pages might not be all that big a
One of the things that I HATE about this discussion is that everyone
wants to put limits on configurability.
I am an old fashion UNIX guy, capability without enforcing policy!
Adding an ability is different than enforcing a policy. All I any to do
is add the capability of configuration in a way
On Fri, 14 Feb 2003, scott.marlowe wrote:
> Asking for everything in a directory with the name local in it to be
> shared is kind of counter intuitive to me.
Not really. If you install a particular program that doesn't come with
the OS on one machine on your site, why would you not want to instal
* Tom Lane ([EMAIL PROTECTED]) [030214 19:35]:
> Lance Thomas <[EMAIL PROTECTED]> writes:
> > Below is something that may be of interest -- a short, 7-statement script
> > that seems to drop my postgres server.
>
> It appears that the plpython trigger implementation assumes that any
> given proce
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Yep. Tatsuo, you should apply the patch to fix the problem. Shame this
> didn't make it into 7.3.2. Should we backpatch?
No. I'm not happy that we're breaking libpq for pre-7.2 servers, and
I definitely don't want to see it done in 7.3. That's way t
Lance Thomas <[EMAIL PROTECTED]> writes:
> Below is something that may be of interest -- a short, 7-statement script
> that seems to drop my postgres server.
It appears that the plpython trigger implementation assumes that any
given procedure will be used as a trigger for only one relation. The
r
Is Linux.conf.au the event PostgreSQL should use for coverage in
Australia next year?
---
Christopher Kings-Lynne wrote:
> Linux.conf.au Report
>
>
> The Linux.conf.au is an international Linux/Open Sou
Tatsuo Ishii wrote:
> > Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> > > + /* Flag to we need to initialize client encoding info */
> > > + static bool need_to_init_client_encoding = -1;
> >
> > Surely that should be int, not bool.
>
> Oops. Will fix.
>
> > > !
On Tue, 11 Feb 2003, Joe Hellerstein wrote:
> Hi all:
> I emailed Marc Fournier on this topic some weeks back, but haven't
> heard from him.
And most public apologies for that ... this past month has been a complete
nightmare all around ... we're just finishing up moving our office, and
fin
I don't want to over-engineer this. Propogating -D into postmaster
makes sense, but grabbing PGDATA doesn't to me.
---
Kevin Brown wrote:
> Bruce Momjian wrote:
> > I see your point --- pg_ctl does a PGDATA trick when passe
"Curtis Faith" <[EMAIL PROTECTED]> writes:
>> "Stored in the index"? And how will you do that portably?
> Sorry for the lack of rigorous language. I meant that there would be one
> mutex per index stored in the header or internal data structures
> associated with each index somewhere. Probably
Tom Lane wrote:
> Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> > + /* Flag to we need to initialize client encoding info */
> > + static bool need_to_init_client_encoding = -1;
>
> Surely that should be int, not bool.
>
> > ! if (!PQsendQuery(conn, "begin; select
Kevin Brown wrote:
> Bruce Momjian wrote:
> > The big question is whether PGDATA is still our driving config variable,
> > and PGCONFIG/-C is just an additional option, or whether we are moving
> > in a direction where PGCONFIG/-C is going to be the driving value, and
> > data_dir is going to be re
Kevin Brown <[EMAIL PROTECTED]> writes:
> Would it make more sense to enable stats_command_string by default?
I'd vote against it. If we turn it on by default, people are paying
for a feature they may not even know exists. Once they find out about
it and decide they want it, they can turn it on
Bruce Momjian writes:
> Tom Lane wrote:
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > So, my idea is to add a message at the end of initdb that states people
> > > should run the pgtune script before running a production server.
> >
> > Do people read what initdb has to say?
> >
> > IIRC, the
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 somewhat limited, from what I've seen, and
in any case the DBA's domain is the database itself: that's the
environment he's going t
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I think the big question is whether we want the default to install the
> configs in a separate directory, pgsql/etc, or just allow the
> specification of a separate location. Advantages of pgsql/etc are
> initdb-safe, and easier backups.
I don't see why
tom lane wrote:
> Hmmm ... that might be made to work, but it would complicate
> inserts. By the time an insert navigates to the page it
> should insert on, it might find the page is dead, and then it
> would have no easy way to get to the replacement page (unless
> you want to dedicate another
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I think the big question is whether we want the default to install the
> > configs in a separate directory, pgsql/etc, or just allow the
> > specification of a separate location. Advantages of pgsql/etc are
> > initdb-safe, and easier
Tom Lane writes:
> I would favor a setup that allows a -C *directory* (not file) to be
> specified as a postmaster parameter separately from the -D directory;
A directory is not going to satisfy people.
> I don't see any great value in a separate postgresql.conf parameter for
> each secondary co
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane writes:
>> I would favor a setup that allows a -C *directory* (not file) to be
>> specified as a postmaster parameter separately from the -D directory;
> A directory is not going to satisfy people.
Why not? Who won't it satisfy, and what's
"Curtis Faith" <[EMAIL PROTECTED]> writes:
> 4) This could easily be reordered into:
> buf = ReadBuffer(rel, blkno); /* pin next page
> */
> LockBuffer(buf, BUFFER_LOCK_UNLOCK);/* release lock on
> current page */
> LockBuffer(buf, BT_READ);
Peter Eisentraut wrote:
> Tom Lane writes:
>
> > I would favor a setup that allows a -C *directory* (not file) to be
> > specified as a postmaster parameter separately from the -D directory;
>
> A directory is not going to satisfy people.
Who is asking to put postgresql.conf, pg_hba.conf, and pg
Attached is a patch the more clearly handles autocommit in pg_dump. I
had already fixed pg_dump for doing autocommit while dumping, but didn't
handle setting autocommit on restore.
I focused on the initial script file startup, every \\connect,
pg_restore, and pg_dumpall. I think I got them all.
I previously wrote:
> 5) A mutex/spinlock that was stored in the index could be
> acquired by the scan code like this:
>
> buf = ReadBuffer(rel, blkno); /* pin next page
> */
>
> SpinLockAcquire( indexSpecificMutex );/* lock the index
> reorg mutex */
>
>
Any chance of giving them all separate TODO items? That way, we would
get more items completed; greedy request, I know. ;-)
---
Anastassia Ailamaki wrote:
> Hi everyone,
>
> > > with some frequency. We have the usual 18
On Friday 14 February 2003 6:07 am, 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 t
Bruce Momjian wrote:
> I see your point --- pg_ctl does a PGDATA trick when passed -D:
>
> -D)
> shift
> # pass environment into new postmaster
> PGDATA="$1"
> export PGDATA
>
> It should pass -D just like it was given.
Yes, exactly.
Now,
Kevin Brown wrote:
> Bruce Momjian wrote:
> > The big question is whether PGDATA is still our driving config variable,
> > and PGCONFIG/-C is just an additional option, or whether we are moving
> > in a direction where PGCONFIG/-C is going to be the driving value, and
> > data_dir is going to be re
Christopher Browne wrote:
> What PITR generally consists of is the notion that you want to recover
> to the state at a particular moment in time.
>
> In O*-nomenclature, this means that you recover as at some earlier
> moment for which you have a good backup, and then re-apply changes,
> which
On Fri, Feb 14, 2003 at 02:58:49 -0800,
Kevin Brown <[EMAIL PROTECTED]> wrote:
>
> Lest you think that this is an unlikely scenario, keep in mind that
> most startup scripts, including pg_ctl, currently start the postmaster
> without arguments and rely on PGDATA, so a shop that hasn't already
>
Michael Brusser <[EMAIL PROTECTED]> writes:
> We're trying to avoid creating any unnecessary files, especially outside
> of the product installation tree. Look at this as a policy.
> Experience shows that sooner or later some of your customers ask you:
> what is this /tmp/.s.PGSQL.xxx file is? Wha
"scott.marlowe" <[EMAIL PROTECTED]> writes:
> But this isn't the same thing at all. Apache, when built from a tar ball,
> goes into /usr/local/apache/ and ALL it's configuration files are there.
Two comments:
1) Even in that case the config files go into /usr/local/apache/conf and the
ot
On Thu, Feb 13, 2003 at 11:53:26 -0500,
mlw <[EMAIL PROTECTED]> wrote:
>
> Where, specificaly are his arguements against a configuration file
> methodology?
I don't think he is argueing against a configuration methodology, but
rather against the methodology being used in Unix distributions.
In
Bruce Momjian wrote:
> The big question is whether PGDATA is still our driving config variable,
> and PGCONFIG/-C is just an additional option, or whether we are moving
> in a direction where PGCONFIG/-C is going to be the driving value, and
> data_dir is going to be read as part of that.
I'm actu
Hi everyone,
> > with some frequency. We have the usual 180 students we get every
> > semester (yep: 180!), but this year we've instituted 2 changes:
We're looking at >100 students taking the class here every year.
> Double cool. I'm just down the road, if Natassa needs a visiting
> lecturer
A long time ago, in a galaxy far, far away, [EMAIL PROTECTED] (Kevin Brown) wrote:
> Bruce Momjian wrote:
>>
>> OK, once we have PITR, will anyone want incremental backups?
>
> None of my database references (Date's "Introduction to Database
> Systems" and Garcia-Molina's "Database Systems - The C
>Nutshell:
> "Easy to install but is horribly slow."
>
> or
>
> "Took a couple of minutes to configure and it rocks!"
Since when is it easy to install on win32?
The easiest way I know of is through Cygwin, then you have to worry about
installing the IPC service (an gettin
Hi all:
I emailed Marc Fournier on this topic some weeks back, but haven't
heard from him.
I am teaching the undergrad DB course at UC Berkeley, something I do
with some frequency. We have the usual 180 students we get every
semester (yep: 180!), but this year we've instituted 2 changes:
1)
tom lane wrote:
> How does that help? The left-moving indexscan still has no
> way to recover. It can't go back to the page it was on
> before and try to determine which entries you added there,
> because it has no reliable reference point to do so. The
> entry it previously returned might n
Here's an example:
create view master_detail
as select * from master
left join detail on (master.detail_key=detail.key);
I noticed that PostgreSQ performs join even when I execute
select some_master_fields from master_detail;
but there exists an unique index on
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > So, we add data_dir to postgresql.conf, and add -C/PGCONFIG to
> > postmaster.
>
> Wait one second. You are blithely throwing in a PGCONFIG variable
> without any detailed proposal of exactly how it will work. Does
> that override a
Hello,
My name is rong xie. I am a Student at
TU-Munich.
I have a question to Postgresql an Linux.
e.g:
for IBM DB2: I can write a test.sql
file.
--test.sql
connect to database1;
set schema xie;
select * from table1;
insert table1 value('rong','xie',22);
select * from table1;
terminate
Hello,
I've noticed one problem by upgrading from postgresql-7.3.1 to 7.3.2.
The example of this problem looks like this:
create table test (a int, b text);
create view testview as select * from test;
create or replace rule testview_ins as
on insert to testview do instead
(
ins
We're trying to avoid creating any unnecessary files, especially outside
of the product installation tree. Look at this as a policy.
Experience shows that sooner or later some of your customers ask you:
what is this /tmp/.s.PGSQL.xxx file is? What do I need it for?
Also some admins known to periodi
Hi!
Is there any way to adjust dumps from postgresql 7.3 for use by
version 7.2 and vice versa ?
Or is there a way to transport a full database via csv or in any other
kind to 7.2 and vice versa ?
We are running a couple of servers/mirrors at various locations in the
world, handling data based
On Thu, Feb 13, 2003 at 08:55:23PM -0500, Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> I've done a little bit of cleanup, but that code is still a mess...
> >> someone should rewrite these routines.
>
> > Yes, I looked at it and struggled to get both IPv4 an
On Fri, 14 Feb 2003, Curt Sampson wrote:
> On Thu, 13 Feb 2003, scott.marlowe wrote:
>
> > If I do a .tar.gz install of apache, I get /usr/local/apache/conf, which
> > is not the standard way you're listing.
>
> I'm going to stay out of this argument from now on, but this struck a sore
> point.
> I seriously doubt your ability to judge anyone's mental stability.
> I can also see that you prefer cross-platform INcompatibility. Your
> position and mindset are now crystal clear.
Come now- don't take it personally. All I said is, as someone who
wrestles daily with QMail, we should prefer t
On Fri, 2003-02-14 at 07:41, Manfred Koizar wrote:
> On Fri, 14 Feb 2003 14:24:23 +0200, Daniel Kalchev <[EMAIL PROTECTED]>
> wrote:
> >The default [cache] on BSD systems is 10% of the total RAM, so on a 256MB machine
>this
> >would be ~26MB or effective_cache_size = 32000.
>
> I was a bit too L
On Fri, 2003-02-14 at 15:35, Tom Lane wrote:
> Here's a pretty topic for a flamewar: should it be /etc/postgres/ or
> /etc/postgresql/ ?
It should be configurable!
Debian uses /etc/postgresql, if you want to stick to what quite a lot of
people are familiar with.
--
Oliver Elphick
Patrick Welche <[EMAIL PROTECTED]> writes:
> On Thu, Feb 13, 2003 at 10:25:52AM -0500, Tom Lane wrote:
>> Well, is that a bug in your wrapper? Or must we add a configure test
>> for the presence of replace_history_entry()?
> Good question. Easiest for now for me would be add a configure test.
Ok
Manfred Koizar <[EMAIL PROTECTED]> writes:
> Given that we have a mostly empty metapage per index, and the metapage
> is in memory most of the time, using it for the freelist looks almost
> like a free lunch.
No, because of locking. Every time you write-lock the metapage to add
or remove freelist
On Thu, 13 Feb 2003, mlw wrote:
>
>
> scott.marlowe wrote:
>
> >>These are not issues at all. You could put the configuration file
> >>anywhere, just as you can for any UNIX service.
> >>
> >>postmaster --config=/home/myhome/mydb.conf
> >>
> >>I deal with a number of PG databases on a number o
On Thu, 13 Feb 2003, Bruce Momjian wrote:
> To auto-tune, you would need to monitor swap usage and other stuff that
> may vary too much based on load from other systems. Only the admin
> knows how to answer some of those questions.
No, to "auto-tune" many parameters that currently require manual
"Curtis Faith" <[EMAIL PROTECTED]> writes:
> Another way this could be handled is by not merging onto one of the
> existing pages but to a brand new page, a kind of special case shadow
> index page.
Hmmm ... that might be made to work, but it would complicate inserts.
By the time an insert navigat
On Friday 14 Feb 2003 9:05 pm, you wrote:
> Martin Coxall <[EMAIL PROTECTED]> writes:
> Here's a pretty topic for a flamewar: should it be /etc/postgres/ or
> /etc/postgresql/ ?
I vote for /etc/pgsql. Keeping in line of unix philosophy of cryptic and short
names. Who wants a descriptive names any
On Thu, Feb 13, 2003 at 10:25:52AM -0500, Tom Lane wrote:
> Patrick Welche <[EMAIL PROTECTED]> writes:
> > The sad thing is that my readline wrapper for libedit doesn't wrap
> > replace_history_entry,
>
> Well, is that a bug in your wrapper? Or must we add a configure test
> for the presence of r
On Fri, 2003-02-14 at 03:00, Daniel Kalchev wrote:
> >>>Jason Hihn said:
> > Pardon my ignorance, but there's no way to auto-tune? Ship it with a thread
> > that gathers statistics and periodically re-tunes the database parameters.
> > Of course, be able to turn it off. People that actually take
On Wed, 12 Feb 2003 17:42:44 -0500, Tom Lane <[EMAIL PROTECTED]>
wrote:
>Instead of an actively maintained freelist on disk as per Alvaro Herrera's
>patch, I plan to use the FSM to remember where recyclable pages are, much
>as we do for tables.
Given that we have a mostly empty metapage per index,
Bruce Momjian <[EMAIL PROTECTED]> writes:
> My point is that folks with multiple postmasters may not want to use
> PGDATA, but for folks who have single postmasters, it makes things
> easier and less error-prone.
Actually, for multi postmasters too. I have little shell-environment
config files th
tom lane wrote:
> How does that help? The left-moving indexscan still has no
> way to recover. It can't go back to the page it was on
> before and try to determine which entries you added there,
> because it has no reliable reference point to do so. The
> entry it previously returned might
On Thu, 2003-02-13 at 19:22, Adam Haberlach wrote:
> On Thu, Feb 13, 2003 at 05:59:17PM -0500, Robert Treat wrote:
> > On Thu, 2003-02-13 at 15:08, mlw wrote:
> > > Stephan Szabo wrote:
> > >
> > > On Thu, 13 Feb 2003, mlw wrote:
> > Personally I think a postgresql installation is much more like a
Martin Coxall <[EMAIL PROTECTED]> writes:
> Partially true. The FHS specifies that the /etc top layer is for system-own3d
> stuff, but the subdirectories off it are explicitly used for user space programs
> and, well, everything. (/etc/apache, /etc/postgres, /etc/tomcat3,
> /etc/tomcat4...)
FHS or
Bruce Momjian wrote:
>
> OK, once we have PITR, will anyone want incremental backups?
None of my database references (Date's "Introduction to Database
Systems" and Garcia-Molina's "Database Systems - The Complete Book",
in particular) seem to talk about PITR at all. At least, there's no
index en
Kevin Brown <[EMAIL PROTECTED]> writes:
> I'm quite interested in knowing why there seems to be so much resistance to
> removing the "potential_DataDir = getenv("PGDATA");" line from
> postmaster.c.
Backwards compatibility. Also, you still haven't explained why
"I don't want to use PGDATA" should
Oliver Elphick <[EMAIL PROTECTED]> writes:
> On Fri, 2003-02-14 at 12:17, Bruce Momjian wrote:
>> If you want ps to display the data dir, you should use -D. Remember, it
>> is mostly important for multiple postmaster, so if you are doing that,
>> just use -D, but don't prevent single-postmaster fo
Bruce Momjian <[EMAIL PROTECTED]> writes:
> So, we add data_dir to postgresql.conf, and add -C/PGCONFIG to
> postmaster.
Wait one second. You are blithely throwing in a PGCONFIG variable
without any detailed proposal of exactly how it will work. Does
that override a PGDATA environment variable?
On Fri, 2003-02-14 at 06:52, Bruce Momjian wrote:
> OK, once we have PITR, will anyone want incremental backups?
>
> ---
>
> Martin Marques wrote:
> > On Jue 13 Feb 2003 16:38, Bruce Momjian wrote:
> > > Patrick Macdonald wro
Tom Lane wrote:
> I am happy to design an arrangement that allows you not to depend on
> PGDATA if you don't want to. But I don't see why you need to break
> my configuration procedures in order to fix yours. As I outlined last
> night, it's possible to do what you want without breaking backwards
Manfred Koizar <[EMAIL PROTECTED]> writes:
> In postgresql.conf.sample-writeheavy you have:
> commit_delay = 1
> Is this still needed with "ganged WAL writes"? Tom?
I doubt that the current options for grouped commits are worth anything
at the moment. Chris, do you have any evidence ba
On 14 Feb 2003, Martin Coxall wrote:
> On Fri, 2003-02-14 at 14:21, Vince Vielhaber wrote:
> > On 14 Feb 2003, Martin Coxall wrote:
> >
> > >
> > > > > If you are interested in reading a contrary position, you can read
> > > > > Berstein's arguments for his recommended way to install services at:
Kevin Brown <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> The other side of that coin is, what's the good reason to remove it?
>> There's a long way between "I don't want my setup to depend on PGDATA"
>> and "I don't think your setup should be allowed to depend on PGDATA".
>> If you don't want t
Bruce Momjian wrote:
> > This way, people who start the database using the standard tools we
> > supply will know exactly what's going on when they get a "ps" listing.
>
> No. If you want ps to display, don't use environment variables. Many
> don't care --- especially those with only one postmast
Added to TODO:
* Add schema option to createlang
---
Justin Clift wrote:
> Bruce Momjian wrote:
> > Is this a TODO? Not sure.
>
> Is this a mis-feature (not really a bug) that should be fixed in 7.3.2?
>
> Regar
Kevin Brown wrote:
> Bruce Momjian wrote:
> > OK, here is an updated proposal. I think we have decided:
> >
> > Moving postmaster.pid and postmaster.opts isn't worth it.
> >
> > We don't want per-file GUC variables, but assume it is in
> > the same config directory as postgresql.conf
Bruce Momjian wrote:
>
> Give it up. As long as we have -D, we will allow PGDATA. If you don't
> want to use it, don't use it.
Agreed.
I'm not sure I see how this diminishes the argument for fixing pg_ctl
so that it passes an explicit -D option to the postmaster when
invoking it...
--
Kevin
Bruce Momjian wrote:
> OK, here is an updated proposal. I think we have decided:
>
> Moving postmaster.pid and postmaster.opts isn't worth it.
>
> We don't want per-file GUC variables, but assume it is in
> the same config directory as postgresql.conf. I don't
> see any
On Fri, 2003-02-14 at 14:21, Vince Vielhaber wrote:
> On 14 Feb 2003, Martin Coxall wrote:
>
> >
> > > > If you are interested in reading a contrary position, you can read
> > > > Berstein's arguments for his recommended way to install services at:
> > > > http://cr.yp.to/unix.html
> >
> > But sin
Hannu Krosing <[EMAIL PROTECTED]> writes:
> Tom Lane kirjutas R, 14.02.2003 kell 01:13:
>> How is returning the same data twice not an "ill effect"?
> From earlier discussions I understood that there had been some work done
> on using btrees for indexing arrays by storing each separate element in
Is there a TODO here, like "Allow recovery from corrupt pg_control via
WAL"?
---
Kevin Brown wrote:
> Tom Lane wrote:
> > Kevin Brown <[EMAIL PROTECTED]> writes:
> > > One question I have is: in the event of a crash, why not
My point is that folks with multiple postmasters may not want to use
PGDATA, but for folks who have single postmasters, it makes things
easier and less error-prone.
---
Bruce Momjian wrote:
>
> Give it up. As long as we ha
Give it up. As long as we have -D, we will allow PGDATA. If you don't
want to use it, don't use it.
---
Kevin Brown wrote:
> Bruce Momjian wrote:
> > I just set PGDATA in my login and I don't have to deal with it
> > again.
On 14 Feb 2003, Martin Coxall wrote:
>
> > > If you are interested in reading a contrary position, you can read
> > > Berstein's arguments for his recommended way to install services at:
> > > http://cr.yp.to/unix.html
>
> But since DJB is a class-A monomaniac, he may not be the best person to
> l
Bruce Momjian wrote:
> I just set PGDATA in my login and I don't have to deal with it
> again.
DuhI just realized a reason you guys might care about this so
much.
It's because you want to be able to start the postmaster from within a
debugger (or profiler, or whatever), and you don't want to
unsubscribe
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
Kevin Brown wrote:
> Bruce Momjian wrote:
> > I just set PGDATA in my login and I don't have to deal with it
> > again.
>
> Hmm...you don't use pg_ctl to start/stop/whatever the database? You
> invoke the postmaster directly (I can easily see that you would, just
> asking if you do)?
I can use e
Bruce Momjian wrote:
> I just set PGDATA in my login and I don't have to deal with it
> again.
Hmm...you don't use pg_ctl to start/stop/whatever the database? You
invoke the postmaster directly (I can easily see that you would, just
asking if you do)?
--
Kevin Brown
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/postgres/postgresql.conf, if w
> Generally things that live in /etc are owned and operated by the OS.
> Postgresql, by it's definition is a userspace program, not an OS owned
> one.
Partially true. The FHS specifies that the /etc top layer is for system-own3d
stuff, but the subdirectories off it are explicitly used for use
> > If you are interested in reading a contrary position, you can read
> > Berstein's arguments for his recommended way to install services at:
> > http://cr.yp.to/unix.html
But since DJB is a class-A monomaniac, he may not be the best person to
listen to. /var/qmail/control for qmail configurati
Kevin Brown wrote:
> Bruce Momjian wrote:
> > If you want ps to display the data dir, you should use -D. Remember, it
> > is mostly important for multiple postmaster, so if you are doing that,
> > just use -D, but don't prevent single-postmaster folks from using
> > PGDATA.
>
> Perhaps the best c
Bruce Momjian wrote:
> If you want ps to display the data dir, you should use -D. Remember, it
> is mostly important for multiple postmaster, so if you are doing that,
> just use -D, but don't prevent single-postmaster folks from using
> PGDATA.
Perhaps another reasonable approach would be to put
Bruce Momjian wrote:
> If you want ps to display the data dir, you should use -D. Remember, it
> is mostly important for multiple postmaster, so if you are doing that,
> just use -D, but don't prevent single-postmaster folks from using
> PGDATA.
Perhaps the best compromise would be to change pg_c
On Vie 14 Feb 2003 09:52, Bruce Momjian wrote:
> OK, once we have PITR, will anyone want incremental backups?
I will probably not need it, but I know of people how have databases which
build dumps of more then 20GB.
They are interested in live incremental backups.
--
Porqué usar una base de dat
I am not sure if it is a good idea to be mucking with it. For backend,
we do the entire thing, so it is clear we modified something.
---
Oliver Elphick wrote:
> On Fri, 2003-02-14 at 12:17, Bruce Momjian wrote:
> > If you w
On Fri, 2003-02-14 at 12:17, Bruce Momjian wrote:
> If you want ps to display the data dir, you should use -D. Remember, it
> is mostly important for multiple postmaster, so if you are doing that,
> just use -D, but don't prevent single-postmaster folks from using
> PGDATA.
Could not the ps line
Added to TODO:
* Cache last known per-tuple offsets to speed long tuple access
---
Tom Lane wrote:
> Hannu Krosing <[EMAIL PROTECTED]> writes:
> >> i.e. for tuple with 100 cols, allocate an array of 100 pointers, p
OK, once we have PITR, will anyone want incremental backups?
---
Martin Marques wrote:
> On Jue 13 Feb 2003 16:38, Bruce Momjian wrote:
> > Patrick Macdonald wrote:
> > > Bruce Momjian wrote:
> > > > Someone at Red Hat is wo
On Fri, 14 Feb 2003 14:24:23 +0200, Daniel Kalchev <[EMAIL PROTECTED]>
wrote:
>The default [cache] on BSD systems is 10% of the total RAM, so on a 256MB machine
>this
>would be ~26MB or effective_cache_size = 32000.
I was a bit too Linux-minded, where every peace of memory not needed
for anythin
1 - 100 of 112 matches
Mail list logo
