>>>Bruce Momjian said:
>
> I imagined they could run pgtune anytime after install to update those
> performance parameters. It gives them a one-stop location to at least
> do minimal tuning, and as their load changes, they can run it again.
True, but to make reasonably good choice, they will
Apache explicitly supports a number of different layouts for files out of
the box (and provides support for you to roll your own very easily). From
the manual:
The second, and more flexible way to configure the install path locations
for Apache is using the config.layout file. Using this method, i
Tom Lane kirjutas R, 14.02.2003 kell 01:13:
> Hannu Krosing <[EMAIL PROTECTED]> writes:
> > But if we would allow the scans to find the same keys twice without ill
> > effects (as was suggested earlier, for using btrees to index arrays),
>
> How is returning the same data twice not an "ill effect"
On Fri, 2003-02-14 at 02:45, [EMAIL PROTECTED] wrote:
> 3.7.1 Purpose
> /etc contains configuration files and directories that are specific to the
> current system.
>
> 3.7.4 Indicates that
>
> "Host-specific configuration files for add-on application software packages
> must be installed wit
Kevin Brown <[EMAIL PROTECTED]> writes:
> I agree with your assessment for the most part, except for PGDATA.
> There's no good reason I can think of for the postmaster to look at
> it.
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
On Fri, 2003-02-14 at 02:49, Tom Lane wrote:
> Oliver Elphick <[EMAIL PROTECTED]> writes:
> > I'm not entirely sure why SE Linux has a problem, seeing that postgres
> > needs read-write access to all the files in $PGDATA, but assuming the
> > need is verified, I could do this by moving the pid file
On Thu, 2003-02-13 at 22:53, Bruce Momjian wrote:
> Oliver Elphick wrote:
> > What your comments strongly suggest to me is that projects like
> > PostgreSQL and pine, along with everything else, should comply with FHS;
> > then there will be no confusion because everyone will be following the
> > s
On Thu, 2003-02-13 at 23:06, mlw wrote:
>
> Bruce Momjian wrote:
> > Can non-root write to /var/run?
> >
> >
> Shouldn't be able too
But it should be able to write under /var/run/postgresql, which the
distribution will set up with the correct permissions.
--
Oliver Elphick
Laurette Cisneros <[EMAIL PROTECTED]> writes:
> This is the error in the pgsql log:
> 2003-02-13 16:21:42 [8843] ERROR: Index external_signstops_pkey is not a
> btree
This says that one of two fields that should never change, in fixed
positions in the first block of a btree index, didn't have t
OK,
Here's a stab at some extra conf files. Feel free to shoot them down.
If we can come up with at least _some_ alternative files that we can put
somewhere for them to see when postgres is installed, then at least people
can see what variables will affect what...
I didn't see the point of a 'w
Tom Lane wrote:
> I don't see any great value in a separate postgresql.conf parameter for
> each secondary config file; that just means clutter to me, especially
> if we add more such files in future. I am also distinctly not in favor
> of eliminating the PGDATA environment variable; that reads to
Bruce Momjian wrote:
> We could prevent the postmaster from starting unless they run pg_tune or
> if they have modified postgresql.conf from the default. Of course,
> that's pretty drastic.
If you're going to do that, then you may as well make the defaults
something that will perform reasonably w
Quick question for the group
I'm assuming that the PG_TEMP_FILES_DIR for BufFile temps is
automatically under the PGDATA directory. Is that correct ?
--
Pip-pip
Sailesh
http://www.cs.berkeley.edu/~sailesh
---(end of broadcast)---
TIP 1: subscrib
"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 improve performance?
There is no such thing as i
HEY PEOPLE!
How about we take this discussion to the Performance List, where it belongs?
--
Josh Berkus
Aglio Database Solutions
San Francisco
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Kevin Brown <[EMAIL PROTECTED]> writes:
> What happens when the only transaction running emits more WAL log data
> than wal_buffers can handle? A flush happens when the WAL buffers
> fill up (that's what I'd expect)? Didn't find much in the
> documentation about it...
A write, not a flush (ie, w
This patch allows using PostgreSQL with a command line configuration
file parameter instead of the data directory.
If no configuration is specified, postmaster operates as it always has.
The configuration file is specified with the "-C" parameter, as:
postmaster -C /somepath/somefile.conf
With
Tatsuo,
> Sigh. People always complain "pgbench does not reliably producing
> repeatable numbers" or something then say "that's because pgbench's
> transaction has too much contention on the branches table". So I added
> -N option to pgbench which makes pgbench not to do any UPDATE to
> the branch
Lamar Owen <[EMAIL PROTECTED]> writes:
> Ok, if we're going this far already, tell me exactly why we have three config
> files. Why not really Unify things and fulfil the full promise of Grand
> Unified Configuration by rolling hba and ident into postgresql.conf. Is
> there a compelling reason
Tom Lane wrote:
> "Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> > I've just spent the last day and a half trying to benchmark our new database
> > installation to find a good value for wal_buffers. The quick answer - there
> > isn't, just leave it on the default of 8.
>
> I don't think
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> Here's a question then - what is the _drawback_ to having 1024 wal_buffers
> as opposed to 8?
Waste of RAM? You'd be better off leaving that 8 meg available for use
as general-purpose buffers ...
regards, tom lane
-
Josh Berkus wrote:
> > > Uh ... do we have a basis for recommending any particular sets of
> > > parameters for these different scenarios? This could be a good idea
> > > in the abstract, but I'm not sure I know enough to fill in the details.
>
> Sure.
> Mostly-Read database, few users, good ha
> "Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> > Here's a question then - what is the _drawback_ to having 1024
> wal_buffers
> > as opposed to 8?
>
> Waste of RAM? You'd be better off leaving that 8 meg available for use
> as general-purpose buffers ...
What I mean is say you have an
> I don't think this is based on a useful test for wal_buffers. The
> wal_buffers setting only has to be large enough for the maximum amount
> of WAL log data that your system emits between commits, because a commit
> (from anyone) is going to flush the WAL data to disk (for everyone).
> So a benc
Lamar Owen wrote:
> > I am now wondering if we even want pg_hba_dir and pg_ident_dir. Seems
> > we can assume they are in the same directory as postgresql.conf. That
> > leaves only data_dir as new for postgresql.conf.
>
> Ok, if we're going this far already, tell me exactly why we have three co
> I don't think this is based on a useful test for wal_buffers. The
> wal_buffers setting only has to be large enough for the maximum amount
> of WAL log data that your system emits between commits, because a commit
> (from anyone) is going to flush the WAL data to disk (for everyone).
> So a benc
On Thursday 13 February 2003 21:49, Tom Lane wrote:
> Oliver Elphick <[EMAIL PROTECTED]> writes:
> > need is verified, I could do this by moving the pid file from
> > $PGDATA/postmaster.pid to /var/run/postgresql/5432.pid and similarly for
> > other ports. This would also have the benefit of being
Oliver Elphick <[EMAIL PROTECTED]> writes:
> I'm not entirely sure why SE Linux has a problem, seeing that postgres
> needs read-write access to all the files in $PGDATA, but assuming the
> need is verified, I could do this by moving the pid file from
> $PGDATA/postmaster.pid to /var/run/postgresql
On Thursday 13 February 2003 21:13, Bruce Momjian wrote:
> Lamar Owen wrote:
> > It isn't without precedent to have a directory under /var/run. Maybe
> > /var/run/postgresql. Under this one could have a uniquely named pid
> > file.
> But how do you handle the default then, where you have postmas
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.
/usr is designed to be a filesystem that can be shared.
> On 13 Feb 2003, Oliver Elphick wrote:
>
> > What your comments strongly suggest to me is that projects like
> > PostgreSQL and pine, along with everything else, should comply with FHS;
> > then there will be no confusion because everyone will be following the
> > smae standards. Messes arise wh
> "Bruce" == Bruce Momjian <[EMAIL PROTECTED]> writes:
Bruce> Tom Lane wrote:
>> Sailesh Krishnamurthy <[EMAIL PROTECTED]> writes:
>> > Sadly, set_ps_display does not seem to have any effect in solaris
>> > x86. At least ps only reports multiple postmaster processes and
>>
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> I've just spent the last day and a half trying to benchmark our new database
> installation to find a good value for wal_buffers. The quick answer - there
> isn't, just leave it on the default of 8.
I don't think this is based on a useful te
"Ron Mayer" <[EMAIL PROTECTED]> writes:
> One thing I've been wondering, is if "sort_mem" could be
> per connection/backend-process instead of per sorting operation
> so that sort_mem could be set more aggressivelly without running out
> of memory so easily with large queries.
Not very readily.
Vince Vielhaber wrote:
> On Thu, 13 Feb 2003, Lamar Owen wrote:
>
> > On Thursday 13 February 2003 18:07, Vince Vielhaber wrote:
> > > Actually FHS says the opposite. If the distribution installs PostgreSQL
> > > then the config files belong in /etc/postgresql. If the admin does then
> > > they
Lamar Owen wrote:
> > First, a few conclusions:
>
> > We can't use /var/run because we need the postmaster to create
> > those, and it isn't root.
>
> It isn't without precedent to have a directory under /var/run. Maybe
> /var/run/postgresql. Under this one could have a uniquely named
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 and IPv6 cleanly
> working. Any ideas on how to improve it?
The major
Bruce Momjian wrote:
> I don't think separate params for each config file is good. At the
> most, I think we will specify the configuration _directory_ for all the
> config files, perhaps pgsql/etc, and have pgdata default to ../data, or
> honor $PGDATA. That might be the cleanest.
>
> Of course
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> Speculation time: do you have the IPv6 code compiled in? I don't.
>
> > I have IPv6 enabled in the binary, but not the kernel.
>
> Sure enough, the IPV6 patch had broken error handling in the non-IPV6
> path.
>
On Thursday 13 February 2003 20:09, Bruce Momjian wrote:
> Lamar Owen wrote:
> > This isn't the same environment, Bruce, that you got into back when it
> > was still Postgres95.
> So you are saying this isn't my grandma's database anymore. :-)
I actually thought of saying it that way, too. :-)
Michael Brusser wrote:
> I have Postgres 7.2.1 configured to listen on TCP/IP port.
> When the server starts up it still creates the socket file in /tmp.
> Removing this file manually does not seem to cause any problem for the
> application.
>
> Is there a way to prevent postmaster from creating t
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Speculation time: do you have the IPv6 code compiled in? I don't.
> I have IPv6 enabled in the binary, but not the kernel.
Sure enough, the IPV6 patch had broken error handling in the non-IPV6
path.
I've done a little bit of cleanup
Good evening, tonight while running my routine vacuum, the following came up on my
screen:
---8<---
NOTICE: Rel xamefiles: Uninitialized page 708135 - fixing
NOTICE: Rel xamefiles: Uninitialized page 708136 - fixing
NOTICE: Rel xamefiles: Uninitialized page 708137 - fixing
NOTICE:
Wow, there's been a lot of discussion on this issue!
While it won't address some of the issues that have been brought up,
there is one very simple thing we can do that will help sysadmins
quite a lot: eliminate the postmaster's use of $PGDATA, and force the
data directory to be specified on the c
Lamar Owen wrote:
> This isn't the same environment, Bruce, that you got into back when it was
> still Postgres95. We are in the big leagues OS-wise, and we need to act like
> it. Assuming that we are a 'userspace' program (which is a misnomer anyway,
> as _anything_ non-kernel is 'userspace')
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 the time to run
tune manually will turn it off as to not have the overhead or interrupt
I have Postgres 7.2.1 configured to listen on TCP/IP port.
When the server starts up it still creates the socket file in /tmp.
Removing this file manually does not seem to cause any problem for the
application.
Is there a way to prevent postmaster from creating this file?
Is this really safe to re
> 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 d
| Create a schema only dump with the 7.2 pg_dump.
| Create a data only dump (possibly with INSERT output) with the 7.3
| pg_dump. Assuming you haven't done anything too wacky, you should be
| able to drop your 7.2 database, reload the 7.2 schema, then load up the
| 7.3 data. As always, test
>
>
>Actually, the results are completely expected once you know what's
>exactly is going on. I found it weird that my sorts were also slowing
>down with more sort memory until Tom or Bruce or someone pointed out to
>me that my stats said my sorts were swapping.
>
>
th
Well, I wrote pgmonitor on gborg.postgresql.org, which is like top for
PostgreSQL, but is in TCL. It uses ps internally.
---
Shahbaz Chaudhary wrote:
> Sorry, I don't think I made myself clear. I don't want to query the DB
This is the second time I've seen this.
7.3.2
This particular table is empty. I'm trying to read it in a perl script.
It doesn't duplicate regularly (I have a script that creates the database
by copying table data from another databases).
This is the error in the pgsql log:
2003-02-13 16:21:42
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:
> >
> > I have absolutely no problem debating and augmenting the feature. None
> > what so ever, I am more pushing to get moment
Bruce Momjian wrote:
>
> Patrick Macdonald wrote:
>
> > Yeah, it's a different method of producing a similar outcome. However, many
> > companies do not want to be concerned with the management (and space)
> > of archived logs. Incremental backup allows them the option of performing
> > a full b
Sorry, I don't think I made myself clear. I don't want to query the DB
every few seconds to get its current status. I want to keep an open an
open connection and have immediate access to all information like I have
when I set the debug level high and see everything going on inside the
DB right on
Well, we have jdbc at jdbc.postgresql.org.
---
Shahbaz Chaudhary wrote:
> Hi All,
> I was wondering if there is a libq or libqxx type library written in
> java. Even if it is done through jni. I would like to do some
> exp
Hi All,
I was wondering if there is a libq or libqxx type library written in
java. Even if it is done through jni. I would like to do some
experiments, perhaps make a utility that reads server information such
as currently executing query, current locks, amount of disk/ram taken up
by pgsql. Bas
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> In CVS tip, I'm getting only an empty string from psql where it should
> >> print connection-failure messages.
>
> > [ it works here ]
>
> Speculation time: do you have the IPv6 code compiled in? I don't.
I hav
On Thursday 13 February 2003 18:41, Vince Vielhaber wrote:
> On Thu, 13 Feb 2003, Lamar Owen wrote:
> > PostgreSQL is as critical as PHP, Apache, or whatever other package is
> > being backended by PostgreSQL. If the package is provided by the
> > distributor, consider it part of the OS. If it is
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> In CVS tip, I'm getting only an empty string from psql where it should
>> print connection-failure messages.
> [ it works here ]
Speculation time: do you have the IPv6 code compiled in? I don't.
regards, tom
On Thu, 13 Feb 2003, Lamar Owen wrote:
> On Thursday 13 February 2003 18:07, Vince Vielhaber wrote:
> > Actually FHS says the opposite. If the distribution installs PostgreSQL
> > then the config files belong in /etc/postgresql. If the admin does then
> > they belong in /usr/local/etc/postgresql
On Thursday 13 February 2003 18:07, Vince Vielhaber wrote:
> Actually FHS says the opposite. If the distribution installs PostgreSQL
> then the config files belong in /etc/postgresql. If the admin does then
> they belong in /usr/local/etc/postgresql. FHS is out of their tree. If
> PostgreSQL or
On Thursday 13 February 2003 17:53, Bruce Momjian wrote:
> Oliver Elphick wrote:
> > What your comments strongly suggest to me is that projects like
> > PostgreSQL and pine, along with everything else, should comply with FHS;
> > then there will be no confusion because everyone will be following th
Tom Lane wrote:
> Hannu Krosing <[EMAIL PROTECTED]> writes:
> > But if we would allow the scans to find the same keys twice without ill
> > effects (as was suggested earlier, for using btrees to index arrays),
>
> How is returning the same data twice not an "ill effect"?
>
> > then we could possi
Robert Treat wrote:
On Thu, 2003-02-13 at 14:51, mlw wrote:
Robert Treat wrote:
On Thu, 2003-02-13 at 12:13, mlw wrote:
My patch only works on the PostgreSQL server code. No changes have been
made to the initialization scripts.
The patch declares three extra configura
Hannu Krosing <[EMAIL PROTECTED]> writes:
> But if we would allow the scans to find the same keys twice without ill
> effects (as was suggested earlier, for using btrees to index arrays),
How is returning the same data twice not an "ill effect"?
> then we could possibly 1) copy the key to the rig
On 13 Feb 2003, Oliver Elphick wrote:
> What your comments strongly suggest to me is that projects like
> PostgreSQL and pine, along with everything else, should comply with FHS;
> then there will be no confusion because everyone will be following the
> smae standards. Messes arise when people ig
Bradley McLean <[EMAIL PROTECTED]> writes:
> Here's a patch that fixes my issue. I have not extensively developed
> tests for it.
Patch applied, thanks!
regards, tom lane
---(end of broadcast)---
TIP 4: Don't 'kill -9' the
> Wow, I never even thought that was possible. Do other db's support that
> feature?
Isn't that basically what the current replication kits for Postgresql do
-- via triggers and log tables?
--
Rod Taylor <[EMAIL PROTECTED]>
PGP Key: http://www.rbt.ca/rbtpub.asc
signature.asc
Description: Th
Bruce Momjian wrote:
Robert Treat wrote:
IIRC the postmaster.pid file should be in /var/run according to FHS, I'm
not sure about postmaster.opts though...
Again, if we're going to make a change, let's make sure we think it
through.
Can non-root write to /var/run?
On Thu, 2003-02-13 at 15:08, mlw wrote:
> Stephan Szabo wrote:
>
> Re-read my statement and yours about the case you were mentioning. ;)
>
> Sure, putting the files in /etc lets you find them easily. However, if
>
> you're doing things like finding configuration made by someone else and
>
> sa
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.
---
Jason Hihn wrote:
> Pardon my ignor
Patrick Macdonald wrote:
> > But why would someone want incremental backups compared to PITR? The
> > backup would be mixture of INSERTS, UPDATES, and DELETES, right? Seems
> > pretty weird. :-)
>
> Yeah, it's a different method of producing a similar outcome. However, many
> companies do not
Robert Treat wrote:
> IIRC the postmaster.pid file should be in /var/run according to FHS, I'm
> not sure about postmaster.opts though...
>
> Again, if we're going to make a change, let's make sure we think it
> through.
Can non-root write to /var/run?
--
Bruce Momjian
Oliver Elphick wrote:
> What your comments strongly suggest to me is that projects like
> PostgreSQL and pine, along with everything else, should comply with FHS;
> then there will be no confusion because everyone will be following the
> smae standards. Messes arise when people ignore standards; w
On Thu, 2003-02-13 at 14:51, mlw wrote:
>
>
> Robert Treat wrote:
>
>
> On Thu, 2003-02-13 at 12:13, mlw wrote:
>
>
>
> My patch only works on the PostgreSQL server code. No changes have been
>
> made to the initialization scripts.
>
>
>
> The patch declares three extra configuration f
On Thu, 2003-02-13 at 14:43, Bruce Momjian wrote:
> Robert Treat wrote:
> > On Thu, 2003-02-13 at 12:13, mlw wrote:
> > >
> > > My patch only works on the PostgreSQL server code. No changes have been
> > > made to the initialization scripts.
> > >
> > > The patch declares three extra configuratio
On Thu, 2003-02-13 at 14:28, Bruce Momjian wrote:
> Robert Treat wrote:
> > On Thu, 2003-02-13 at 14:06, mlw wrote:
> > >
> > > I will be resubmitting my patch for the 7.3.2 tree.
> > >
> >
> > I'm no core developer, but surely this wont be included in the 7.3.x
> > branch. Any change needs to b
On Thu, 2003-02-13 at 21:21, Vince Vielhaber wrote:
> I certainly wasn't trying to provoke anything. It just seems odd to me
> that when the distribution installs a package and places it's config files
> in /etc and later the admin happens to upgrade by the instructions with
> the package, it's ac
> All I see here is an arbitrary break with our past practice. I do
> not see any net improvement.
Well, given that there's a trend to make PostgreSQL more usable, I can
say with absolute certainty, that an FAQ that I get about once a week
is (and granted only from new users) "where is the postg
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 of sites, and it is a
real pain in the ass to get t
Tom Lane kirjutas N, 13.02.2003 kell 20:10:
> "Curtis Faith" <[EMAIL PROTECTED]> writes:
> > I don't dispute their conclusions in that context and under the
> > circumstances they outline of random distribution of deletion and
> > insertion values for the index keys. [But the random-distribution
>
Peter Eisentraut wrote:
Joe Conway writes:
So I wrote a quick hack to load and initialize the library on postmaster
startup.
On glibc systems you can probably do this using the environment variable
LD_PRELOAD. I guess others have a similar mechanism.
Hmmm. I could try that. But I found dur
On Thu, 13 Feb 2003, mlw wrote:
>
>
> Christopher Browne wrote:
>
> >In the last exciting episode, [EMAIL PROTECTED] (Curt Sampson) wrote:
> >
> >>On Wed, 12 Feb 2003, Peter Bierman wrote:
> >>
> >>>What do you gain by having the postmaster config and the database
> >>>data live in different lo
On 13 Feb 2003, Oliver Elphick wrote:
> On Thu, 2003-02-13 at 18:45, Bruce Momjian wrote:
> > Oliver Elphick wrote:
> > > On Thu, 2003-02-13 at 17:52, Vince Vielhaber wrote:
> > > > Seems to me that if FHS allows such a mess, it's reason enough to avoid
> > > > compliance. Either that or those of
tom lane wrote:
> "Curtis Faith" <[EMAIL PROTECTED]> writes:
> > I don't dispute their conclusions in that context and under the
> > circumstances they outline of random distribution of deletion and
> > insertion values for the index keys. [But the random-distribution
> > assumption doesn't alwa
Peter Eisentraut wrote:
mlw writes:
AFAIK it wasn't actually done. It was more of a, "we should do something
different" argument. At one point it was talked about rewriting the
configuration system to allow "include" and other things.
The core of the problem was, and
mlw writes:
> AFAIK it wasn't actually done. It was more of a, "we should do something
> different" argument. At one point it was talked about rewriting the
> configuration system to allow "include" and other things.
The core of the problem was, and continues to be, this: If you move
postgresql.
Joe Conway writes:
> So I wrote a quick hack to load and initialize the library on postmaster
> startup.
On glibc systems you can probably do this using the environment variable
LD_PRELOAD. I guess others have a similar mechanism.
--
Peter Eisentraut [EMAIL PROTECTED]
-
> On Wed, 12 Feb 2003, Bruce Momjian wrote:
> >
> > And part of the reason is because some/most BSD's map the page tables
> > into physical RAM (kernel space) rather than use some shared page table
> > mechanism. This is good because it prevents the shared memory from
> > being swapped out (perfor
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
2) Add a setting in postgresql.conf specifying the data directory
3) Change the meaning of -D t
On 13 Feb 2003, Martin Coxall wrote:
>
> > Well, to the extent that you're serious, you understand that
> > a lot of people feel that /usr/local should be reserved for
> > stuff that's installed by the local sysadmin, and your
> > vendor/distro isn't supposed to be messing with it.
> >
> > Wh
Stephan Szabo wrote:
On Thu, 13 Feb 2003, mlw wrote:
Stephan Szabo wrote:
On Thu, 2003-02-13 at 09:23, mlw wrote:
I deal with a number of PG databases on a number of sites, and it is a
real pain in the ass to
Bruce Momjian wrote:
>
> Patrick Macdonald wrote:
> > Bruce Momjian wrote:
> > >
> > > Someone at Red Hat is working on point-in-time recovery, also known as
> > > incremental backups.
> >
> > PITR and incremental backup are different beasts. PITR deals with a backup
> > + logs. Incremental back
Bruce Momjian wrote:
Robert Treat wrote:
On Thu, 2003-02-13 at 12:13, mlw wrote:
My patch only works on the PostgreSQL server code. No changes have been
made to the initialization scripts.
The patch declares three extra configuration file parameters:
hbafile= '/e
On Thu, 13 Feb 2003, mlw wrote:
> Stephan Szabo wrote:
> >>>On Thu, 2003-02-13 at 09:23, mlw wrote:
> I deal with a number of PG databases on a number of sites, and it is a
> real pain in the ass to get to a PG box and hunt around for data
> directory so as to be able to administer th
On Thu, 2003-02-13 at 19:30, Robert Treat wrote:
> If we're going to do this, I think we need to account for all of the
> files in the directory including PG_VERSION, postmaster.opts,
Not PG_VERSION; that is intimately associated with the data itself and
ought to stay in the data directory.
--
O
Robert Treat wrote:
On Thu, 2003-02-13 at 12:13, mlw wrote:
My patch only works on the PostgreSQL server code. No changes have been
made to the initialization scripts.
The patch declares three extra configuration file parameters:
hbafile= '/etc/postgres/pg_hba.conf'
identfile='/
Robert Treat wrote:
> On Thu, 2003-02-13 at 12:13, mlw wrote:
> >
> > My patch only works on the PostgreSQL server code. No changes have been
> > made to the initialization scripts.
> >
> > The patch declares three extra configuration file parameters:
> > hbafile= '/etc/postgres/pg_hba.conf'
> >
Bruce Momjian wrote:
Well, in a sense, it trades passing one parameter, PGDATA, for another.
I see your point that we should specify configuration first, and let
everything pass from there. However, it does add extra configuration
parameters, and because you still need to specify/create pgdat
1 - 100 of 162 matches
Mail list logo
