Tom Lane wrote:
> Magnus Hagander writes:
>> On Thu, May 13, 2010 at 5:06 PM, Bruce Momjian 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 to the bottom of the SGM
On Fri, May 14, 2010 at 7:32 AM, Kevin Grittner
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
wult...@gmail.com
--
[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 post,
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 nice
Tom Lane 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__
NetBSD: __NetBSD_
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
> dev
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 (de
Giles Lean wrote:
>
> Tom Lane 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:
>
> F
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 an
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: FailedAs
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
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 (pgsql-hackers@postgresql.org)
T
On Fri, May 14, 2010 at 11:50 PM, 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.
>
> --
> Rob Wultsch
"They" w
Simon Riggs 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 attempt to measure clock sk
On Sat, 2010-05-15 at 11:45 -0400, Tom Lane wrote:
> Simon Riggs 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
> min
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 b
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
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
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
> >> lastM
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 relation
On Fri, May 14, 2010 at 5:23 PM, Tom Lane wrote:
> Robert Haas 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 immediately upon reaching cons
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 w
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
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
> > h
On Sat, May 15, 2010 at 7:46 PM, David Fetter 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:
>>
>> https://commitfest.postgresql.org/ac
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 writes:
> On Sat, May 15, 2010 at 7:46 PM, David Fetter 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 the patch - any volunteers? One
Michael Renner 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 matching pages [2]. The stra
On 16.05.2010 02:16, Tom Lane wrote:
Michael Renner 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
Tom Lane wrote:
> Robert Haas writes:
> > On Sat, May 15, 2010 at 7:46 PM, David Fetter 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 th
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 p
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 rele
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 for
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 i
Andrew Dunstan 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 is that p
On Sat, May 15, 2010 at 8:51 PM, Tom Lane 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 backpatch this? if
Tom Lane wrote:
Andrew Dunstan 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 encounte
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 valid
Jaime Casanova writes:
> On Sat, May 15, 2010 at 8:51 PM, Tom Lane 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 pl
On Sat, May 15, 2010 at 10:16 PM, Tom Lane wrote:
> Jaime Casanova writes:
>> On Sat, May 15, 2010 at 8:51 PM, Tom Lane 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
Jaime Casanova writes:
> On Sat, May 15, 2010 at 10:16 PM, Tom Lane wrote:
>> Jaime Casanova writes:
>>> On Sat, May 15, 2010 at 8:51 PM, Tom Lane 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
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 wrote:
> Jaime Casanova writes:
>> On Sat, May 15, 2010 at 10:16 PM, Tom Lane wrote:
>>> Jaime Casanova writes:
On Sat, May 15, 2010 at 8:51 PM, Tom Lane wrote:
Is it reasonable to fix this now, and if so should I bump catversion
or lea
Tom Lane wrote:
> So I think that labeling textanycat/anytextcat as immutable was a
> thinko, and we instead ought to label them volatile so that the planner
> can inline them no matter what the behavior of the underlying text cast
> is.
That feels backwards, having to label functions as more vola
46 matches
Mail list logo