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 the time to run
tune manually will turn it off as to not have
Josh Berkus said:
How about we take this discussion to the Performance List, where it belongs?
I believe the design and addition of code that collects and outputs the usage patterns
of the database (statistics) belongs here.
If we take the approach to providing information to tune PostgreSQL
Hannu Krosing [EMAIL PROTECTED] wrote:
could we just not lock (for more than just to ensure atomic writes) the
page but instead increment a page version on each write to detect
changes?
Sounds like Index MVCC..., very nice. ;-)
(Of course I have no clue about feasibility, just liked the idea)
Tom Lane wrote:
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
On Fri, 14 Feb 2003 14:12:50 +0800, Christopher Kings-Lynne
[EMAIL PROTECTED] wrote:
Here's a stab at some extra conf files. Feel free to shoot them down.
No intent to shoot anything down, just random thoughts:
effective_cache_size = 2 (~ 160 MB) should be more adequate for a
256 MB machine
Manfred Koizar said:
effective_cache_size = 2 (~ 160 MB) should be more adequate for a
256 MB machine than the extremely conservative default of 1000. I
admit that the effect of this change is hard to benchmark. A way too
low (or too high) setting may lead the planner to wrong
In reference to determining what port postgres or any program is listening on
On my Redhat Linux machines
netstat --inet -nlp
when run as root
produces a nice list of all programs listening on the network with IP and port
number the process is listening on, the name of the process and the pid.
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 anything
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_ctl
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 an
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 configuration
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 user
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 we
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
unsubscribe
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
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
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
listen to.
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 since DJB is a class-A
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 valid
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:
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 postmaster.
You
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 to use it, then
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:
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 backing
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
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 translate
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 entry
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 no
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 an apache
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 not
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 that
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, and
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 the time
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
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 of sites, and it is a
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 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
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.
/usr
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
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
(
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
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 getting the
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 Complete
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
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
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
other
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? What do
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
been
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 in
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, the more
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;
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 to using
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
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 to
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
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
* 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 procedure will
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 in the
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 passed
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 install
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 180
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 */
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
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); /* lock
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 their
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
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 backups.
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
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 navigates to
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
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.
Okay with
On Jue 13 Feb 2003 16:38, 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
On Thu, 13 Feb 2003 19:24:13 -0500, Patrick Macdonald
[EMAIL PROTECTED] wrote:
I know Oracle and DB2 have incremental backup in their arsenal (and iirc,
SQL Server has something called differential backup). Whatever the name,
it's a win at the enterprise level.
A differential backup copies only
Kevin Brown wrote:
Tom Lane wrote:
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?
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 valid reason they would
It is under each database directory, per-database.
---
Sailesh Krishnamurthy wrote:
Quick question for the group
I'm assuming that the PG_TEMP_FILES_DIR for BufFile temps is
automatically under the PGDATA directory.
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 working on
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, plus
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 be
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
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
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 compromise
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 either to
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.
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
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 simply
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
a löeaf
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. I don't
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 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 PGDATA environment variable?
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 folks from
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 and IPv6
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 PGDATA
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 not
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:
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.
Tom
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 read as
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 we
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.
! if
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 Source
1 - 100 of 103 matches
Mail list logo
