Couldn't you have a policy that every patch is reviewed first by someone who
wants to be an expert in that area, and then by someone who is currently an
expert. Then you have the best of both worlds. The patch is reviewed by
someone will make sure it won't cause problems, and the want to be ex
On Aug 26, 2009, at 8:17 AM, Jean-Michel Pouré wrote:
Le mercredi 26 août 2009 à 01:36 -0600, Rick Gigger a écrit :
One possible reason that replication is more critical now than it
was
a year ago is the rise in cloud computing. The ability to fire up
instances on demand is much more useful
On Aug 24, 2009, at 9:46 PM, Robert Haas wrote:
On Mon, Aug 24, 2009 at 10:15 PM, David Fetter
wrote:
On Mon, Aug 24, 2009 at 08:02:31PM -0400, Tom Lane wrote:
Josh Berkus writes:
That is a slightly alarmist. Who are we going to lose these
users to?
Drizzle. MySQL forks. CouchDB. An
On Jul 16, 2009, at 11:09 AM, Greg Stark wrote:
On Thu, Jul 16, 2009 at 4:41 PM, Heikki
Linnakangas wrote:
Rick Gigger wrote:
If you use an rsync like algorithm for doing the base backups
wouldn't
that increase the size of the database for which it would still be
practical to just re
On Jul 16, 2009, at 12:07 AM, Heikki Linnakangas wrote:
Dimitri Fontaine wrote:
Le 15 juil. 09 à 23:03, Heikki Linnakangas a écrit :
Furthermore, the counter-argument against having the primary
able to send data from the archives to some standby is that it should
still work when primary's dead,
On Jan 27, 2009, at 2:41 AM, Mark Kirkwood wrote:
Dave Page wrote:
On Mon, Jan 26, 2009 at 8:12 PM, Tom Lane wrote:
Josh Berkus writes:
So, some feedback to make this decision more difficult:
Users: care about HS more than anything else in the world.
I don't think this is correct.
On Apr 11, 2008, at 9:30 AM, Tom Lane wrote:
Gregory Stark <[EMAIL PROTECTED]> writes:
Personally I don't think we *know* what we want to do and that's
why the wiki
is a good interim tool.
Yup, that is *exactly* the point. A wiki page is a zero-setup-cost,
flexible way of experimenting wit
Yup, that is *exactly* the point. A wiki page is a zero-setup-cost,
flexible way of experimenting with tracking commit-fest issues.
A year from now, we might have enough experience to decide that some
more-rigidly-structured tool will do what we need, but we don't have
it today. We spent enough
Yup, that is *exactly* the point. A wiki page is a zero-setup-cost,
flexible way of experimenting with tracking commit-fest issues.
A year from now, we might have enough experience to decide that some
more-rigidly-structured tool will do what we need, but we don't have
it today. We spent enough
Ah, yes it was the quotes. I guess that makes me a newbie. :)
On Nov 5, 2007, at 1:53 PM, Tom Lane wrote:
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
Rick Gigger wrote:
Doesn't DROP TRIGGER require the name of the trigger? He says
they are
unnamed. How then does h
Doesn't DROP TRIGGER require the name of the trigger? He says they
are unnamed. How then does he drop them?
On Nov 5, 2007, at 6:31 AM, Tom Lane wrote:
[EMAIL PROTECTED] writes:
On Sun, 4 Nov 2007, Tom Lane wrote:
So you have a *bunch* of partially broken FK constraints in that
source
Jim Nasby wrote:
On Feb 5, 2007, at 12:53 PM, Andrew Hammond wrote:
On Jan 26, 2:38 pm, [EMAIL PROTECTED] (Tom Lane) wrote:
Rick Gigger <[EMAIL PROTECTED]> writes:
I thought that the following todo item just barely missed 8.2:
"Allow a warm standby system to also allow read-only
Gregory Stark wrote:
"Rick Gigger" <[EMAIL PROTECTED]> writes:
I thought that the following todo item just barely missed 8.2:
"Allow a warm standby system to also allow read-only statements [pitr]
This is useful for checking PITR recovery."
No, nobody worked
Andrew Hammond wrote:
On Jan 26, 2:38 pm, [EMAIL PROTECTED] (Tom Lane) wrote:
Rick Gigger <[EMAIL PROTECTED]> writes:
I thought that the following todo item just barely missed 8.2:
"Allow a warm standby system to also allow read-only statements [pitr]
No, it's a someday-wi
Tom Lane wrote:
Rick Gigger <[EMAIL PROTECTED]> writes:
I thought that the following todo item just barely missed 8.2:
"Allow a warm standby system to also allow read-only statements [pitr]
No, it's a someday-wishlist item; the work involved is not small.
Thanks,very much fo
server for reporting purposes
that could always be within minutes of the live data. I know there are
other solutions for this but if this feature is just around the corner
it would be my first choice.
Does anyone know the status of this feature?
Thanks,
Rick Gigger
Joshua D. Drake wrote:
Or
If people are going to start listing features they want here's some
things I think would be nice. I have no idea though if they would be
useful to anyone else:
1) hierarchical / recursive queries. I realize it's just been
discussed at length but since there was some question as to whether
I had a few thoughts on this issue:
The objective is to smoothly upgrade to the new version with minimal
downtime.
The different proposals as far as I can see are as follows:
Proposal A - the big one time reformatting
1) shutdown the db
2) run a command that upgrades the data directory to th
This has been a very interesting thread, if for no other reason then
to just catalog all of the changes going into 8.2. I am going to be
changing some hardware around so I need to decide if I want to a)
change the hardware now and don't bother with 8.2, b) wait to upgrade
hardware and do t
Sorry if this is the wrong place for this but as far as I can tell
there are only 2 features so far that I've seen discussed on hackers
that are looking really good to me. I'm sure all the little changes
will add up to a big win but these are the only two that would make
me feel an urgent
On Jun 22, 2006, at 2:36 PM, Mark Woodward wrote:
What you seem not to grasp at this point is a large web-farm,
about 10
or
more servers running PHP, Java, ASP, or even perl. The database is
usually
the most convenient and, aside from the particular issue we are
talking
about, best suite
On Jun 22, 2006, at 10:33 AM, Mark Woodward wrote:
Ühel kenal päeval, N, 2006-06-22 kell 09:59, kirjutas Mark
Woodward:
After a long battle with technology, [EMAIL PROTECTED] ("Mark
Woodward"), an earthling, wrote:
Clinging to sanity, [EMAIL PROTECTED] ("Mark Woodward")
mumbled
into
It
Just out of curiosity Mark, didn't you write your session daemon so
that you don't have to put sessions in postgres anymore? Or are you
just giving that as an example of a very wide, very heavily updated
table? My session tables have been an extreme case of this problem,
but no other tabl
Any comments on this? Is he referring to EnterpriseDB extensions
that
they don't make public?
I've noticed a lot of press lately is mentioning their name next to
ingres
as an alternative to MySQL, so the MySQL folks might be feeling some
Postgres heat from their direction.
I also wonder w
how? is there some kernel patch to completely to enable you to deny
access to root?
Tino Wildenhain pointed out SELinux has a feature like that.
I still dont get your problem (apart from that you can always
google for SELinux)
Why arent the other "admins" not trustworthy? And why do you
have ma
But why do they need access to the files in the file system? Why not
put them on the local box but don't give them permissions to edit the
pg_hba file? They should still be able to connect.
On Feb 9, 2006, at 5:56 PM, Q Beukes wrote:
I did consider that, but the software we use (which agai
On Feb 9, 2006, at 12:49 PM, Mark Woodward wrote:
On Thu, Feb 09, 2006 at 02:03:41PM -0500, Mark Woodward wrote:
"Mark Woodward" <[EMAIL PROTECTED]> writes:
Again, regardless of OS used, hashagg will exceed "working
memory" as
defined in postgresql.conf.
So? If you've got OOM kill enable
On Feb 9, 2006, at 11:22 AM, Stephen Frost wrote:
* Tom Lane ([EMAIL PROTECTED]) wrote:
"Mark Woodward" <[EMAIL PROTECTED]> writes:
Again, regardless of OS used, hashagg will exceed "working
memory" as
defined in postgresql.conf.
So? If you've got OOM kill enabled, it can zap a process w
On Feb 8, 2006, at 12:55 PM, Josh Berkus wrote:
Andrew,
This would be a very fine project for someone to pick up (maybe
one of the corporate supporters could sponsor someone to work on it?)
We looked at it for Greenplum but just couldn't justify putting it
near the top of the priority li
On Feb 8, 2006, at 7:00 AM, Bruce Momjian wrote:
David Fetter wrote:
On Tue, Feb 07, 2006 at 11:43:40PM -0500, Bruce Momjian wrote:
I did an audio interview today, and it is online now:
http://bsdtalk.blogspot.com/2006/02/bsdtalk015-interview-with-
postgresql.html
Great interview. You h
Rick Gigger wrote:
I was thinking the exact same thing. Except the "and just fsync()
dirty pages on commit" part. Wouldn't that actually make the
situation worse? I thought the whole point of WAL was that it was
more efficient to fsync all of the changes in one sequential wr
I was thinking the exact same thing. Except the "and just fsync()
dirty pages on commit" part. Wouldn't that actually make the
situation worse? I thought the whole point of WAL was that it was
more efficient to fsync all of the changes in one sequential write in
one file rather than fsy
On Feb 3, 2006, at 6:47 AM, Chris Campbell wrote:
On Feb 3, 2006, at 08:05, Mark Woodward wrote:
Using the "/etc/hosts" file or DNS to maintain host locations for
is a
fairly common and well known practice, but there is no such
mechanism for
"ports." The problem now becomes a code issue, n
On Jan 31, 2006, at 12:54 AM, Tino Wildenhain wrote:
Rick Gigger schrieb:
I don't see why anyone has a problem with this. I am certainly
never going to use it but if it helps someone who isn't a linux
person to use it on a project when they would have used something
else (l
I don't see why anyone has a problem with this. I am certainly never
going to use it but if it helps someone who isn't a linux person to
use it on a project when they would have used something else (like
mysql) or if it convinces someone to run postgres on linux instead of
windows because
Rick Gigger <[EMAIL PROTECTED]> writes:
2) I didn't touch the Vacuum delay, background writer or autovacuum
settings because I wasn't familiar enough with them. Are the default
values very restricting?
By default, autovacuum isn't even turned on --- you have
the system. Is there a way to signal a single backend to die
without restarting the whole db server? I looked on google, searched
the archives and in the docs and couldn't find any way to do this.
Thanks again,
Rick
On Jan 21, 2006, at 12:05 AM, Rick Gigger wrote:
Thanks very muc
ions. Once
that happens all of the web clients hang onto their bad connections
and then eventually die. Considering that I'm moving to 8.1 and am
not too familiar with applying patches am I crazy for just going with
the stock 8.1 code?
On Jan 20, 2006, at 10:36 PM, Tom Lane wro
On Jan 20, 2006, at 6:02 PM, Tom Lane wrote:
Rick Gigger <[EMAIL PROTECTED]> writes:
Postgres version 7.3.4
You realize of course that that's pretty old ...
That is right now. Right after it started up it went up to 0292.
So it was the latest file eh? I thought maybe y
=Rick Gigger <[EMAIL PROTECTED]> writes:
Postgres version 7.3.4
You realize of course that that's pretty old ...
Yes. I will be upgrading immediately.
That is right now. Right after it started up it went up to 0292.
So it was the latest file eh? I thought maybe you had s
e for 7.3.13 and build it yourself.
cheers
andrew
Rick Gigger wrote:
It is the version that shipped with fedora core 1. The version
string from psql is (PostgreSQL) 7.3.4-RH. I assume that it must
have been the first bug since I had plenty of disk space.
On Jan 20, 2006, at 5:35 PM,
It is the version that shipped with fedora core 1. The version
string from psql is (PostgreSQL) 7.3.4-RH. I assume that it must
have been the first bug since I had plenty of disk space.
On Jan 20, 2006, at 5:35 PM, Bruce Momjian wrote:
Rick Gigger wrote:
Postgres version 7.3.4
... a
right now. Right after it started up it went up to 0292.
There are a lot of files before the ones listed here right now
though. Do you need to see their names?
On Jan 20, 2006, at 3:58 PM, Tom Lane wrote:
Rick Gigger <[EMAIL PROTECTED]> writes:
I got this message:
2006-01-20 11:50:51
I got this message:
2006-01-20 11:50:51 PANIC: creation of file /var/lib/pgsql/data/
pg_clog/0292 failed: File exists
In 7.3. It caused the server to restart.
Can anyone tell me what it means?
---(end of broadcast)---
TIP 2: Don't 'kill -9' t
I would certainly like some instructions on this as well.
On Jan 3, 2006, at 8:41 PM, Zach Bagnall wrote:
On 12/26/05 11:04, Qingqing Zhou wrote:
""Gregor Zeitlinger"" <[EMAIL PROTECTED]> wrote
Also, I was wondering whether it is always safe to copy the
current WAL file, i.e. may the current
f you
use terms like "online backup" to mean both types of backup but then
use it once in a specific circumstance where only one usage is
appropriate (you are using the terms ambiguously) then users will be
confused and it will be your fault not theirs.
Just
How about:
use "Online backup" or "Hot backup" to refer to either method of back
since they are both done while the system is online or hot.
If you want to get specific refer to doing a "sql dump" etc for using
pg_dump
Then use "Incremental backup" to refer to the whole process of the
WA
ly gets me when the query plan is created
before the statistics are present to create a good plan.
Just one users 2 cents.
- Rick Gigger
On Dec 19, 2005, at 12:00 PM, Jim C. Nasby wrote:
On Sat, Dec 17, 2005 at 01:07:10PM -0500, Bruce Momjian wrote:
Jim C. Nasby wrote:
Is cardinality the
- Asynchronous master to multi-slave. We have a few of those with
Mommoth-Replicator and Slony-I being the top players. Slony-I does
need some cleanup and/or reimplementation after we have a general
pluggable replication API in place.
Is this API actually have people working on it
Just like MySql!
On Dec 5, 2005, at 10:35 PM, Jan Wieck wrote:
On 12/5/2005 8:18 PM, Gustavo Tonini wrote:
replication (master/slave, multi-master, etc) implemented inside
postgres...I would like to know what has been make in this area.
We do not plan to implement replication inside the bac
any fields not specified would
be reinitialized whereas an update would leave them in place.
It seems to me that "try to update and if that fails insert" seems to
be the best approach for not messing with existing data. I guess
"try to insert and if that fails
there is no way it would ever
do an implicit table lock on me. And it would never throw an error/
warning unless I actually did something questionable.
Does that make sense.
Rick Gigger
On Nov 16, 2005, at 7:49 AM, Tom Lane wrote:
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
We
LockShared('name');
[EMAIL PROTECTED] wrote:
This is a first pass on a simple shared memory variable system for
PostgreSQL. I would appriciate anyone interested in this functionality to
rip it apart.
It basically adds this functionality:
SetShared('name', value);
GetSharedInt('name');
SetSharedText
The link you have down there is not the one on the site. All of the
links to that file work just fine for me on the live site.
Jan Wieck wrote:
On 6/4/2004 4:47 AM, Karel Zak wrote:
On Fri, Jun 04, 2004 at 01:01:19AM -0400, Jan Wieck wrote:
Yes, Slonik's,
it't true. After nearly a year the Slony
fantastic for
anything but a very heavy load. I think there may be many people out there
who have little experience but want an RDBMS to manage their data. Those
people need something very, very easy. Look at the following that mysql
gets despite how poor of a product it is. It's very
55 matches
Mail list logo
