On Sat, 15 May 2010, Jaime Casanova wrote:
On Fri, May 14, 2010 at 8:39 AM, Marc G. Fournier scra...@hub.org wrote:
And IMHO, that is as much a fault of the 'old timers' on the lists as the
newbies ... if nobody redirects / loosely enforces the mandates of the
various lists, newbies aren't
Linux has *as many if not more* ... MySQL, if memory servers, has a half
dozen or more ... etc ...
MySQL has a bunch of lists, none of which get much traffic. Honestly,
they should probably be combined.
--
Rob Wultsch
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
Tom Lane wrote:
Magnus Hagander mag...@hagander.net writes:
On Thu, May 13, 2010 at 5:06 PM, Bruce Momjian br...@momjian.us wrote:
I have added SGML comments to comment out the text that mentions EDB
Advanced Server. Is that enough? Should I remove the text from the
SGML? Should I move it
On Fri, May 14, 2010 at 7:32 AM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
Oracle, and all other MVCC databases I've read about outside of PostgreSQL,
use
an update in place with a rollback log technique.
Have you looked at PBXT (which is explicitly NOT SERIALIZABLE)?
--
Rob Wultsch
[redirected to -chat]
On Fri, 14 May 2010, Rob Wultsch wrote:
Linux has *as many if not more* ... MySQL, if memory servers, has a half
dozen or more ... etc ...
MySQL has a bunch of lists, none of which get much traffic. Honestly,
they should probably be combined.
Except, when you do
BTW, What I'd like to see as a very first patch first is to change the
current poll loops in walreceiver and walsender to, well, not poll.
That's a requirement for synchronous replication, is very useful on its
own, and requires a some design and implementation effort to get right.
It would be
Tom Lane t...@sss.pgh.pa.us wrote:
I suppose that at least some of the *BSD herd really do predefine some
of the symbols being attributed to them here, but I would like to see
something authoritative about which and what.
Documentation follows, but first the summary:
FreeBSD: __FreeBSD__
Peter Eisentraut wrote:
On l?r, 2010-05-15 at 00:23 -0400, Robert Haas wrote:
It's a commercial distribution of BSD. I remember it being pretty
nice when I used it 10+ years ago, but it sounds like it's dead now.
BSDI is the company that produced BSD/OS, which was Bruce's main
Bruce Momjian wrote:
Peter Eisentraut wrote:
On l?r, 2010-05-15 at 00:23 -0400, Robert Haas wrote:
It's a commercial distribution of BSD. I remember it being pretty
nice when I used it 10+ years ago, but it sounds like it's dead now.
BSDI is the company that produced BSD/OS,
Tom Lane wrote:
I'm not even too sure what bsdi is, but I'm suspicious of that branch
too. A search of our code finds
contrib/pg_upgrade/file.c: 248: #elif defined(freebsd) || defined(bsdi) ||
defined(__darwin__) || defined(openbsd)
src/backend/utils/misc/ps_status.c: 67: #elif
Giles Lean wrote:
Tom Lane t...@sss.pgh.pa.us wrote:
I suppose that at least some of the *BSD herd really do predefine some
of the symbols being attributed to them here, but I would like to see
something authoritative about which and what.
Documentation follows, but first the
Rob Wultsch wrote:
Have you looked at PBXT (which is explicitly NOT SERIALIZABLE)?
I hadn't heard of it; so I took a quick look based on your post. It
seems to a new engine to use with MySQL which has MVCC without a
rollback log, so it presumably uses techniques at least vaguely
similar to
Seems reasonable. Does the victim backend currently know why it has been
killed?
I don't think so.
One idea is postmaster sets a flag in the shared memory area
indicating it rceived SIGTERM before forwarding the signal to
backends.
Backend check the flag and if it's not set, it
On Thu, 2010-05-13 at 18:01 -0400, Bruce Momjian wrote:
I was able to easily crash the standby server today just by starting it
and connecting to it via psql. The master was idle. The failure was:
LOG: streaming replication successfully connected to primary
TRAP:
Patch adds a keepalive message to ensure max_standby_delay is useful.
No WAL format changes, no libpq changes. Just an additional message type
for the streaming replication protocol, sent once per main loop in
WALsender. Plus docs.
Comments?
--
Simon Riggs www.2ndQuadrant.com
diff
On Sat, May 15, 2010 at 4:09 AM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
Anything in particular you wanted me to notice about it besides that?
Nope. It was just a counter point to your previous comment.
--
Rob Wultsch
wult...@gmail.com
--
Sent via pgsql-hackers mailing list
On Fri, May 14, 2010 at 11:50 PM, Rob Wultsch wult...@gmail.com wrote:
Linux has *as many if not more* ... MySQL, if memory servers, has a half
dozen or more ... etc ...
MySQL has a bunch of lists, none of which get much traffic. Honestly,
they should probably be combined.
--
Rob Wultsch
Simon Riggs si...@2ndquadrant.com writes:
Patch adds a keepalive message to ensure max_standby_delay is useful.
The proposed placement of the keepalive-send is about the worst it could
possibly be. It needs to be done right before pq_flush to ensure
minimum transfer delay. Otherwise any
On Sat, 2010-05-15 at 11:45 -0400, Tom Lane wrote:
Simon Riggs si...@2ndquadrant.com writes:
Patch adds a keepalive message to ensure max_standby_delay is useful.
The proposed placement of the keepalive-send is about the worst it could
possibly be. It needs to be done right before pq_flush
Simon Riggs wrote:
On Sat, 2010-05-15 at 11:45 -0400, Tom Lane wrote:
I'm also extremely dubious that it's a good idea to set
recoveryLastXTime from this. Using both that and the timestamps from
the wal log flies in the face of everything I remember about control
theory. We should be doing
On Sat, 2010-05-15 at 19:30 +0300, Heikki Linnakangas wrote:
Simon Riggs wrote:
On Sat, 2010-05-15 at 11:45 -0400, Tom Lane wrote:
I'm also extremely dubious that it's a good idea to set
recoveryLastXTime from this. Using both that and the timestamps from
the wal log flies in the face of
Simon Riggs wrote:
On Sat, 2010-05-15 at 19:30 +0300, Heikki Linnakangas wrote:
Doesn't feel right to me either. If you want to expose the
keepalive-time to queries, it should be a separate field, something like
lastMasterKeepaliveTime and a pg_last_master_keepalive() function to
read it.
On Sat, 2010-05-15 at 20:05 +0300, Heikki Linnakangas wrote:
Simon Riggs wrote:
On Sat, 2010-05-15 at 19:30 +0300, Heikki Linnakangas wrote:
Doesn't feel right to me either. If you want to expose the
keepalive-time to queries, it should be a separate field, something like
On Sat, 2010-05-15 at 18:24 +0100, Simon Riggs wrote:
I will recode using that concept.
There's some behaviours that aren't helpful here:
Startup gets new pointer when it runs out of data to replay. That might
or might not include an updated keepalive timestamp, since there's no
exact
On Fri, May 14, 2010 at 5:23 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
PM_RECOVERY_CONSISTENT - PM_HOT_STANDBY
PMSIGNAL_RECOVERY_CONSISTENT - PMSIGNAL_BEGIN_HOT_STANDBY
+1. From the point of view of the postmaster, whether the state
transition happens
Simon Riggs wrote:
WALSender sleeps even when it might have more WAL to send, it doesn't
check it just unconditionally sleeps. At least WALReceiver loops until
it has no more to receive. I just can't imagine why that's useful
behaviour.
Good catch. That should be fixed.
I also note that
Heikki Linnakangas wrote:
Simon Riggs wrote:
WALSender sleeps even when it might have more WAL to send, it doesn't
check it just unconditionally sleeps. At least WALReceiver loops until
it has no more to receive. I just can't imagine why that's useful
behaviour.
Good catch. That should be
On Fri, May 14, 2010 at 04:24:43PM -0400, Bruce Momjian wrote:
Stephen Frost wrote:
-- Start of PGP signed section.
Greetings,
Toying around with FETCH_COUNT today, I discovered that it didn't do
the #1 thing I really wanted to use it for- query large tables without
having to
On Sat, May 15, 2010 at 7:46 PM, David Fetter da...@fetter.org wrote:
Anyway, this makes FETCH_COUNT alot more useful, and, in my view, the
current behaviour of completely ignoring $PAGER exiting is a bug.
Plesae add this to the next commit-fest:
While preparing a replication test setup with 9.0beta1 I noticed strange
page allocation patterns which Andrew Gierth found interesting enough to
report here.
I've written a simple tool to generate traffic on a database [1], which
did about 30 TX/inserts per second to a table. Upon inspecting
Robert Haas robertmh...@gmail.com writes:
On Sat, May 15, 2010 at 7:46 PM, David Fetter da...@fetter.org wrote:
Wouldn't this count as a bug fix?
Possibly, but changes to signal handlers are pretty global and can
sometimes have surprising side effects. I'm all in favor of someone
reviewing
Michael Renner michael.ren...@amd.co.at writes:
I've written a simple tool to generate traffic on a database [1], which
did about 30 TX/inserts per second to a table. Upon inspecting the data
in the table, I noticed the expected grouping of tuples which came from
a single backend to
On 16.05.2010 02:16, Tom Lane wrote:
Michael Rennermichael.ren...@amd.co.at writes:
I've written a simple tool to generate traffic on a database [1], which
did about 30 TX/inserts per second to a table. Upon inspecting the data
in the table, I noticed the expected grouping of tuples which came
Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
On Sat, May 15, 2010 at 7:46 PM, David Fetter da...@fetter.org wrote:
Wouldn't this count as a bug fix?
Possibly, but changes to signal handlers are pretty global and can
sometimes have surprising side effects. I'm all in favor
I noticed by accident that there are some cases where the planner fails
to inline the SQL functions that underlie the || operator for text vs
non-text cases. The reason is that these functions are marked
immutable, but their expansion involves a coercion to text that might
not be immutable. The
FYI, I test pg_upgrade by loading the old cluster's regression database
from a pg_dump output file, then after the upgrade, I dump the
regression database of the new cluster and diff the changes.
The problem I just encountered is that pg_dump uses
extra_float_digits=-3 for 9.0, while previous
Bruce Momjian wrote:
FYI, I test pg_upgrade by loading the old cluster's regression database
from a pg_dump output file, then after the upgrade, I dump the
regression database of the new cluster and diff the changes.
The problem I just encountered is that pg_dump uses
extra_float_digits=-3
Andrew Dunstan wrote:
Bruce Momjian wrote:
FYI, I test pg_upgrade by loading the old cluster's regression database
from a pg_dump output file, then after the upgrade, I dump the
regression database of the new cluster and diff the changes.
The problem I just encountered is that
Andrew Dunstan and...@dunslane.net writes:
Bruce Momjian wrote:
FYI, I test pg_upgrade by loading the old cluster's regression database
from a pg_dump output file, then after the upgrade, I dump the
regression database of the new cluster and diff the changes.
The problem I just encountered
On Sat, May 15, 2010 at 8:51 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Is it reasonable to fix this now, and if so should I bump catversion
or leave it alone? My own preference is to fix it in pg_proc.h but
not touch catversion; but you could argue that different ways.
are you planning to
Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
Bruce Momjian wrote:
FYI, I test pg_upgrade by loading the old cluster's regression database
from a pg_dump output file, then after the upgrade, I dump the
regression database of the new cluster and diff the changes.
The
Andrew Dunstan wrote:
The problem I just encountered is that pg_dump uses
extra_float_digits=-3 for 9.0, while previous releases used '2'. I had
to do hack each server version to get a dump output that would match
without rounding errors --- it did eventually work and validated.
Jaime Casanova ja...@2ndquadrant.com writes:
On Sat, May 15, 2010 at 8:51 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Is it reasonable to fix this now, and if so should I bump catversion
or leave it alone? Â My own preference is to fix it in pg_proc.h but
not touch catversion; but you could argue
On Sat, May 15, 2010 at 10:16 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Jaime Casanova ja...@2ndquadrant.com writes:
On Sat, May 15, 2010 at 8:51 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Is it reasonable to fix this now, and if so should I bump catversion
or leave it alone? My own preference is to
Jaime Casanova ja...@2ndquadrant.com writes:
On Sat, May 15, 2010 at 10:16 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Jaime Casanova ja...@2ndquadrant.com writes:
On Sat, May 15, 2010 at 8:51 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Is it reasonable to fix this now, and if so should I bump
Bruce Momjian wrote:
Maybe I have misunderstood. How exactly is the server version being
hacked here? I know it's only for testing, but it still seems to me that
lying to a program as heavily version dependant as pg_dump is in general
a bad idea.
The code in pg_dump 9.0 is:
/*
On Sat, May 15, 2010 at 10:21 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Jaime Casanova ja...@2ndquadrant.com writes:
On Sat, May 15, 2010 at 10:16 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Jaime Casanova ja...@2ndquadrant.com writes:
On Sat, May 15, 2010 at 8:51 PM, Tom Lane t...@sss.pgh.pa.us
47 matches
Mail list logo
