general, we should be less worried about the age of a bug vs
our expectations that users are likely to hit that bug now, which does
seem high based on the above numbers.
In the meantime, it's certainly worth warning users, providing help on
how to determine if this is a likely proble
Given the overhead from a development standpoint is low, whats the
better user experience: delay removal for as long as possible (~10
years) to narrow the likely of people being affected, or make such
changes as visible as possible (~6+ years) so that people have clear
expectations / lines of demarca
ly offer an R = 1, W = 1 or 2, and N = all. And it's
worse than that, because we have golden nodes.
This isn't to say there isn't a lot of confusion around the issue.
Designing, implementing, and configuring different guarantees in the
presence of node failures is a non-trivial problem. Sti
ost something.
That said, if anyone else has come up with a method, I'd be interested
in looking at it.
Robert Treat
play: xzilla.net
work: omniti.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
x27;s better for
postgres dedicated tools, but I think you're going to really make it
harder for people if you eliminate the trigger file method for coming
out of recovery.
Robert Treat
play: xzilla.net
work: omniti.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Tue, Jan 24, 2012 at 3:02 AM, wrote:
>> * Robert Treat:
>>
>>> Would it be unfair to assert that people who want checksums but aren't
>>> willing to pay the cost of running a filesystem that provides
>>> checksums aren't going to be willing to
that's cheap enough that you should probably just do it more. We're
probably a lot more agressive on our vacuum / analyze scale settings
than some people (we cut the defaults in half as a matter of course),
and I come from the "don't limit stuff" camp too, but by and large
what we do works, even if it's more black magic than people would
like. :-)
Robert Treat
conjecture: xzilla.net
consulting: omniti.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
to assert that people who want checksums but aren't
willing to pay the cost of running a filesystem that provides
checksums aren't going to be willing to make the cost/benefit trade
off that will be asked for? Yes, it is unfair of course, but it's
interesting how small the camp of th
27;ll happily update all of the tools and samples I deal with to support this
> change. Most of the ones I can think of will be simplified; they're already
> parsing query_text and extracting the implicit state. Just operating on an
> explicit one instead will be simpler and more r
Thanks in advance.
Robert Treat
conjecture: xzilla.net
consulting: omniti.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Tue, Nov 8, 2011 at 7:19 PM, Greg Smith wrote:
> On 11/08/2011 05:07 PM, Robert Treat wrote:
>>
>> It's already easy to get "good enough" numbers based on user space
>> tools with very little overhead, so I think it's more important that
>> th
pment that adds a ring
> buffer for example.
It's already easy to get "good enough" numbers based on user space
tools with very little overhead, so I think it's more important that
the server side tool be accurate rather than fast. Of course, if we
can get both, that's a
be interesting to see rows for autovacuum or
replication processes showing up in pg_stat_activity with a
corresponding state (autovacuum, walreciever?) and the "query" field
showing what they are working on, at the risk that we'd need to build
more complex parsing into the various
endent.
>
If they aren't I don't think we need both columns. +1 for leaving them
independent though.
Robert Treat
play: xzilla.net
work: omniti.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
your solution", and I already confirmed back to you
> that would be possible.
>
"It's possible to run a replica without having a recovery.conf file"
is not the same thing as "If someone makes a recovery.conf file, it
won't break my operations". AIUI, you are not su
tools are actually parsing that field. Most that I see just dump
>> whatever is in current_query to the user. I would imaging that, so long as
>> the server obeyed pgstat_track_activity_size most tools would behave nicely.
>
> Really? I'd assume every single monitoring tool
On Tue, Nov 1, 2011 at 2:34 PM, Simon Riggs wrote:
> On Tue, Nov 1, 2011 at 6:12 PM, Robert Treat wrote:
>> On Tue, Nov 1, 2011 at 1:34 PM, Simon Riggs wrote:
>>> On Tue, Nov 1, 2011 at 5:11 PM, Joshua Berkus wrote:
>>>
>>>> So, we have four potential pat
se tool providers you are trying to
help, as they will be forced to support the behavior *both ways*. I'd
much rather see some type of switch which turns on the old behavior
for those who really want it, because while you can teach the new
behavior, if you can't prevent the old behavior,
plish more advanced awl management
goals. So far the biggest criticism we've gotten is that it wasn't
written in python, for some of you that might be a plus though ;-)
Robert Treat
play: xzilla.net
work: omniti.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
s of a riak fdw he hasn't
listed yet... guess I should go pester him).
Robert Treat
conjecture: xzilla.net
consulting: omniti.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Sun, May 1, 2011 at 1:14 PM, Kevin Grittner
wrote:
> Robert Treat wrote:
>> Tom Lane wrote:
>
>>> CF #1: June 1-30
>>> CF #2: August 1-31
>>> CF #3: October 1-31
>>> CF #4 (one week shortened CF): December 1-7
&g
full CF#5, but we wouldn't let anything new come into CF#5.
This way when we get the 100 patch pile up in CF#4, there's no
expectation that those patches will be committed, just that they can
be sanity checked for the 9.2 release.
Robert Treat
play: xzilla.net
work: omnit
On Fri, Mar 4, 2011 at 2:03 AM, Magnus Hagander wrote:
> On Fri, Mar 4, 2011 at 04:00, Robert Treat wrote:
>> I have a server where I wanted to do some reporting on a standby, and
>> wanted to set the max standby delay to 1 hour. upon doing that, i get
>> this in the logs:
&
rs than in microseconds.
OTOH, maybe it's a bug? The default resolution is in milliseconds, and
you can't set it to anything less than that (afaict). I asked on irc
and the consensus seemed to be that the internal representation is
off, are we missing something?
Robert Treat
play: xzilla.
about how he's trying to solve this internal to
the database.
Robert Treat
play: xzilla.net
work: omniti.com
hiring: l42.org/Lg
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Mon, Feb 28, 2011 at 3:42 AM, Magnus Hagander wrote:
> On Mon, Feb 28, 2011 at 06:21, Tom Lane wrote:
>> Robert Treat writes:
>>> Did anything ever come of this discussion?
>>
>> I think it's a TODO --- nothing done about it as yet, AFAIR.
>>
>&g
;
It generates an error because the ALTER ROLE fails with the role not
existing, which causes pg_upgrade to bail out (it's in the on error
stop part).
ISTM this fails in general, so not blaming pg_upgrade; I think there
should probably be a fix in pg_dumpall to create all roles first
before
use case for user level tracing support. Add a probe
around these bits, and you can capture the information when you need
it.
Robert Treat
http://www.xzilla.net
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Thu, Dec 30, 2010 at 3:36 PM, Simon Riggs wrote:
>
> On Thu, 2010-12-30 at 15:07 -0500, Robert Treat wrote:
> > > If more than one standby server specifies synchronous_replication,
> > then
> > > whichever standby replies first will release waiting commits.
>
&
i to create
his own version, I've both enjoyed reading this thread and seeing this wheel
reinvented yet again, and wholeheartedly +1 the idea of building this
directly into pg_dump. (The only thing better would be to make everything
thing sql callable, but that's a problem for another day).
Robert Treat
http://www.xzilla.net
covery or in standby mode.
> hot_standby_feedback (boolean)
>Specifies whether or not a hot standby will send feedback to the
>primary about queries currently executing on the standby. This
>parameter can be used to eliminate query cancels caused by
>cleanup records, though it can cause database bloat on the
>primary for some workloads. The default value is off. This
>parameter can only be set at server start. It only has effect if
>hot_standby is enabled.
>
>
i was expecting this section to mention the synchronous_replication (bool)
somewhere, to control if the standby will participate synchronously or
asynch; granted it's the same config as listed in 18.5.5 right? Just that
the heading of that section specifically targets the primary.
HTH, looks pretty good at first glance.
Robert Treat
http://www.xzilla.net
ostgres's memory
settings
arc being zfs's adaptive replacement cache, so basically giving the server a
second, very large level of memory to work with, and then configuring
postgres to make use of it. It wasn't terribly obvious to me why this ended
up outperforming the initial idea of putting everything on ssd, but my
impression was that the more you could force postgres into making decisions
as if it was dealing with fast storage rather than slow storage, the better
off you'd be (and that random_page_cost is not so wholly inclusive enough to
do this for you).
Robert Treat
http://www.xzilla.net
ld is actually reporting something different in
this context, so I am hoping someone can help clarify it for me?
Robert Treat
http://www.xzilla.net
. In the case where you say CONSTRAINT it'd be a bit plausible
> > to write something like
> >
> > ALTER TABLE table_name ADD CONSTRAINT con_name PRIMARY KEY USING EXISTING
> INDEX;
> >
> > (implying that the index to use is named con_name) but I don't know
> > what to do if you want to leave off the "CONSTRAINT name" clause.
>
> Because this seems plain weird.
>
>
+1
Robert Treat
play: http://www.xzilla.net
work: http://www.omniti.com/is/hiring
it
would be optional with the new syntax as well... Also, I'm not wedded to the
idea of keeping the column list, but if you are arguing to make it super
consistent, then I think you need to include it.
Robert Treat
play: http://www.xzilla.net
work: http://www.omniti.com/is/hiring
something rather limiting. On the
whole the customers we are talking with are far more concerned about things
like managing failover scenarios when you have multiple slaves, and it's the
lack of capabilities around those kinds of things that hurt postgres
adoption much more than it being hard to set up.
Robert Treat
play: http://www.xzilla.net
work: http://omniti.com/is/hiring
exist, I'll start a wiki page on it, but thought
I'd ask first.
--
Robert Treat
Play: http://www.xzilla.net
Work: http://omniti.com/is/hiring
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ooking forward to another interesting year with GSoC,
and hoping you'll join in.
--
Robert Treat
Conjecture: http://www.xzilla.net
Consulting: http://www.omniti.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Saturday 23 January 2010 16:19:11 Andrew Dunstan wrote:
> Robert Treat wrote:
> > I'm not saying there aren't
> > downsides, but having a name the community can unify on is a definite
> > plus, and imho that name has to be Postgres.
>
> Translation: &quo
PostgreSQL instead of
reverting to plain Postgres was the single worst mistake this project ever
made." I think I would have to agree, and I can't see this issue ever going
away as long as we stick with PostgreSQL. I'm not saying there aren't
downsides, but having a name
guess is that we won't get
them into core for 8.5, but that we might be able to provide some additional
facilities after the fact as we get more of these systems deployed.
--
Robert Treat
Conjecture: http://www.xzilla.net
Consulting: http://www.omniti.com
--
Sent via pgsql-hackers
to
retrieve the information. The ideal api is that I can find the information out
via result of some SELECT query; view, table ,function doesn't matter, as long
as I can select it out. Bonus points for being able to get information from
the hot standby.
--
Robert Treat
Conjecture: http://www.x
(line
~1065) in "postmaster.c"
[30] main(argc = ???, argv = ???) (optimized), at 0x688336 (line ~188) in
"main.c"
Both of those systems run Solaris, though one was compiled with gcc, the other
with SunStudio. I can probably dig up more info if needed.
Oh, seems it might be related
On Sunday 10 January 2010 01:38:07 Tom Lane wrote:
> Robert Treat writes:
> > ... I don't see much sense in worrying about it now; the 2 weeks between
> > end of CF and Beta are when we need to be cut-throat. Given that this
> > time the "must-have" feature
s you are most worried about will have taken care of
themselves (one way or the other)
But I don't see much sense in worrying about it now; the 2 weeks between end
of CF and Beta are when we need to be cut-throat. Given that this time the
"must-have" feature is already in th
ot
cause of the failure has been addressed and a correctly designed test
executed.
I will wait a day for your confirmation and/or other's comments.
Looks good from my end, thanks Simon.
Robert Treat
http://www.omniti.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org
On Jan 7, 2010, at 5:18 PM, Simon Riggs wrote:
On Thu, 2010-01-07 at 16:56 -0500, Robert Treat wrote:
Not much more to send really.
No problem. I can see what causes it, nothing more required, thanks.
What I don't fully understand yet is why the error hasn't shown itself
before,
On Jan 7, 2010, at 4:15 PM, Simon Riggs wrote:
On Thu, 2010-01-07 at 14:41 -0500, Robert Treat wrote:
Doing some testing with 8.5alpha3, my standby crashed this morning
whilst
doing some testing. Seems I have a core file, so thought I would
send a report.
Version: PostgreSQL 8.5alpha3
ork under Linux, but that we
need DatabasePath to not be null in the above.
FWIW, the SQL I was running on the master did involve two create database
commands back to back.
LMK if you have any questions.
--
Robert Treat
Conjecture: http://www.xzilla.net
Consulting: http://www.omniti.com
--
Se
;t have spent this
> > much time talking about it if I didn't believe that to be true. On my
> > side, in addition to helping coordinate everyone pushing in the same
> > direction, I'll also continue trying to shake out some sponsorship
> > funding for additional wo
e, that would save
me some trouble. Thanks in advance.
--
Robert Treat
Conjecture: http://www.xzilla.net
Consulting: http://www.omniti.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
istr cases where I couldn't startup regular postgres but could in
stand-alone mode that had system indexes disabled...I could be misremembering
that so that the postmaster would start, I just couldn't connect unless in
stand-alone. In any case this does seem less than ideal, but if ther
;
> > I'm also not sure what you would think that it's not self-explanatory,
> > since it looks pretty self explanatory to me.
>
> It's impossible to know that this is commitfest 2009-07.
>
commitfest.postgresql.org/2009/07 ?
That, or any similar scheme, seem
core. I don't see much reason to include it in
> core: its not an SQL standard datatype, it complicates catalog entries
> and most people don't need or want it.
>
That's too bad. I'd much rather see someone implement something closer to
Oracle's number type.
--
ompile for Solaris. I think it might have still had issues actually
dumping data, but it did do a good job at finding corrupted xlogs. istr Theo
submitted a patch, but I think the author had abandoned it. Personally I'd
love to see it moved into postgresql proper (and get the cleaning/
On Wednesday 29 April 2009 14:03:14 Dimitri Fontaine wrote:
> Hi,
>
> On Tuesday 28 April 2009 20:43:38 Robert Treat wrote:
> > We had started down the path of making a function to read deleted tuples
> > from a table for a DR scenario we were involved with once. The idea was
or most people, if you told them that they could do create
table as select * from viewdeletedttuples(...) t(...) after doing a
mis-placed delete/update, at the cost of having to sift through extra data,
they would make that trade in a heartbeat.
--
Robert Treat
Conjecture: http://www.xzilla.n
point no one seemed to raise. I
used to recommend people set this to 0 pretty regularly, since most web shops
don't even know what prepared transactions are, let alone use them. I got
less agressive about this after a few people reported to me that they had run
out of lock slots on thier s
> > ORDER BY random()
> > > )
> > > FROM foo;
> > > ERROR: ORDER/GROUP BY expression not found in targetlist
> >
> > Fixed.
>
> Thanks! :)
>
Yes, thanks!
--
Robert Treat
Conjecture: http://www.xzilla.net
Consulting: http://www.omniti.c
haven't run into that case yet; in the work I've been doing in
8.4, the above is how I've been wanting it to work, and swapping to \df* to
see system hasn't been much of an issue.
BTW, I often do \df *.sin when looking for a function I'm not sure of where it
live
reSQL in conjunction with an
> external log rotation tool.
>
Hey! We were just complaining about this behavior the other day at $dayjob. We
were considering hacking our build to make it stop doing this ourselves, but
decided to use syslog in the end. Nice to see this "feature" di
x27;ve been talking about this magical "proper module facility" for a few
releases now... are we still opposed to putting contrib modules in thier own
schema? People who took my advice and did that for tsearch were mighty happy
when 8.2 broke at the C level, and when 8.3 broke all
m guessing they will start helping, and eventually
Bruce will join in. Outside of that I think we're wasting our time on this.
--
Robert Treat
Conjecture: http://www.xzilla.net
Consulting: http://www.omniti.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
take a fresh look at your list of twenty things and see what can be
delegated out to others.
--
Robert Treat
Conjecture: http://www.xzilla.net
Consulting: http://www.omniti.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://w
S
>
> ... or similar; I'd need to find an existing keyword which works.
>
> I think this bypasses a lot of the issues which Tom raises, but I'd want
> to think about the various permutations some more.
>
How bad of an idea would it be to split set session authorization t
On Tuesday 03 March 2009 03:22:30 Simon Riggs wrote:
> On Mon, 2009-03-02 at 21:11 -0500, Robert Treat wrote:
> > On Wednesday 25 February 2009 16:43:54 Simon Riggs wrote:
> > > On Wed, 2009-02-25 at 13:33 -0800, Josh Berkus wrote:
> > > > > You raised that as a
if you have it wrong until you fire up the standby (ie. you
can't tell at the time you make your base backup), right ?
--
Robert Treat
Conjecture: http://www.xzilla.net
Consulting: http://www.omniti.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
l, but I'm
wondering if there might be other performanace implications that I'm not
aware of? Anyone ever run with 6 figure fsm relations (not just pages)
before?
--
Robert Treat
Conjecture: http://www.xzilla.net
Consulting: http://www.omniti.com
--
Sent via pgsql-hackers mailing
autovacuum table
really gone in 8.4, or just deprecated?
--
Robert Treat
Conjecture: http://www.xzilla.net
Consulting: http://www.omniti.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
d to run pg_resetxlog to set the
> WAL position and XID counter anyway, and it can set the OID counter too.
>
+1 for doing this, otherwise we need some strong warnings in the migrator docs
about this case imho.
--
Robert Treat
Conjecture: http://www.xzilla.net
Consulting: http://www.omniti.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ng to pg_dump, I think keeping
consistency with that in pg_restore would be a bonus. (I still see people get
confused because -d work differently between those two apps)
Possibly -w might work, which could expand to --workers, which glosses over
the thread/process difference, is also be availa
stly wondering about
probe name or location). TIA
--
Robert Treat
Conjecture: http://www.xzilla.net
Consulting: http://www.omniti.com
diff --git a/src/backend/postmaster/postmaster.c b/src/backend/postmaster/postmaster.c
index 3380b80..ddf23d8 100644
--- a/src/backend/postmaster/postmaster.c
+
On Friday 06 February 2009 10:43:30 Bruce Momjian wrote:
> Bruce Momjian wrote:
> > Robert Treat wrote:
> > > I know that the fedora tzdata-2009a packages have the Argentian changes
> > > (as well as some others depending on version of fedora), but I'm not
&
I am inclined to think
they aren't in there, but can someone confirm for our release announcement if
8.3.6 et al have Argentinian timezone updates? (Or any other updates we
should mention) TIA
Robert Treat
-- Forwarded Message --
Subject: Re: [pgsql-slavestothewww] New News
ne), keep the patch queue pretty manageable (right up untill the end, when
we stopped the cycle), and also delivered us some really big features along
the way.
--
Robert Treat
Conjecture: http://www.xzilla.net
Consulting: http://www.omniti.com
--
Sent via pgsql-hackers mailing list (pgsql-h
mplications on a number of levels for users
and developers.
--
Robert Treat
Conjecture: http://www.xzilla.net
Consulting: http://www.omniti.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
we can improve things for the people working on
the next release, well, I think that's a good idea too, and I dont see how
doing nothing is going to help.
--
Robert Treat
Conjecture: http://www.xzilla.net
Consulting: http://www.omniti.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wednesday 28 January 2009 20:12:40 Bruce Momjian wrote:
> Robert Treat wrote:
> > The revisionism was that of "remarkable failure". That was our shortest
> > release cycle in the modern era. And it didn't have the advantage of the
> > commitfest process.
&
On Wednesday 28 January 2009 12:35:42 Tom Lane wrote:
> Robert Treat writes:
> > On Wednesday 28 January 2009 08:55:56 Magnus Hagander wrote:
> >> We're still going to have to pay the full cost of doing a release every
> >> time. With beta/rc management, releas
right now, and that's with more dev
cycles than I'm talking about for 8.5. And I think most people (aka not the
patch authors :-) would have been willing to push the stuff we're dealing
with now if they knew the next release would be closer to 6 months than 14
months.
--
Robe
On Tuesday 27 January 2009 21:07:48 Tom Lane wrote:
> Robert Treat writes:
> > The more I think about it, the more I feel that where we failed for 8.3
> > was not having a short 8.4 cycle lined up, which would give more freedom
> > to bump patches to the next release.
&g
On Tuesday 27 January 2009 19:04:49 Tom Lane wrote:
> Robert Treat writes:
> > On Tuesday 27 January 2009 10:34:59 Joshua D. Drake wrote:
> >> We have tried the short release cycle before, it was called 8.2. It
> >> fails, remarkably.
> >
> > I think this
On Tuesday 27 January 2009 18:51:01 Tom Lane wrote:
> Robert Treat writes:
> > Now I am starting to think that we cannot prevent large patches from
> > showing up at the end of a cycle no matter what, and the only way to
> > really "solve" that problem is to lesson
elease 8.5, open 8.6
December - first commitfest for 8.6
Jan 2010 - second dev cycle
Feb - final commitfest
March - 8.6 beta
April - 8.6 rc
May 2010 - release 8.6
--
Robert Treat
Conjecture: http://www.xzilla.net
Consulting: http://www.omniti.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
talked to several oracle and db2 shops that want a standby
for reporting that has relatively easy setup/maintenance (handling ddl is a
big part of this) and the HS feature your working on will give them something
as good as what they are getting now. So yeah, HS appeals to future users as
well.
release (ie. require binary or data file level compatability with 8.4
for the 8.5 release, and remove that restriction for 8.6) to lesson the
upgrade path. (alternativly, a working IPU plan could make that less of an
issue)
--
Robert Treat
Conjecture: http://www.xzilla.net
Consulting: http://www.omniti.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wednesday 21 January 2009 20:21:41 Bruce Momjian wrote:
> Alvaro Herrera wrote:
> > Robert Treat wrote:
> > > On Thursday 08 May 2008 00:27:10 Tino Wildenhain wrote:
> > > > David Fetter wrote:
> >
> > Ref: http://archives.postgresql.org/pgsql-ha
or patch, which supplied a --no-stats flag.
>
> This is a documentation only patch, not tied to a recent code change.
s/varriable/variable/g
also, I forget which way is proper, but you're inconsistent with your closing
tags for in that paragraph (using both )
--
Robert Treat
Conject
this get into the main source tree to make it easier for future testing. (For
example, one hurdle on Solaris, I had to get a different version of patch to
handle Simon's diff... ugh!)
--
Robert Treat
Conjecture: http://www.xzilla.net
Consulting: http://www.omniti.com
--
Sent via pgsql
nk the correct resolution to the question is to ask legal. Yes?
>
> So I can get three different answers? It is not a priority for me.
>
Nor does it need to be... copyright for organizations runs ~ 100 years, so a
year here or there is unlikely to make much difference to any of us. (T
bench on a master with pg_bench select test on slave isn't that
bad of a scenario to match the above; it might be a little too much activity
on the master, but has anyone else run such a test?
--
Robert Treat
Conjecture: http://www.xzilla.net
Consulting: http://www.omniti.com
--
Sent via
cancel
query for replay, and pause replay for queries, are probably enough for a
first go around (especially if you can get the query canceling to work only
when changes are made to the specific database in question)
--
Robert Treat
Conjecture: http://www.xzilla.net
Consulting: http://www.om
ost, although the standby can fall very
> much behind, and it can take a while to catch up.
>
I was thinking the condition Simon was concerned about was that on a very busy
slave with wal delay, you could theoretically fill up the disks and destroy
the slave. With query cancel, you might be a
ill have, since I think most of thier DDL can be
done online. (This might require some extra modules / high end version of
Oracle, please consult your local Oracle wizard for more details)
--
Robert Treat
Conjecture: http://www.xzilla.net
Consulting: http://www.omniti.com
--
Sent via pgsql-hack
that will end is still undetermined. In other words, if you have a
patch for 8.4 that is already submitted but not committed, keep hacking!
--
Robert Treat
Conjecture: http://www.xzilla.net
Consulting: http://www.omniti.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.or
On Monday 28 January 2008 05:37:03 Florian Weimer wrote:
> * Robert Treat:
> > Note we've been using Theo's plperl bytea patch on one of our
> > production servers for some time; if anyone wants access to that
> > lmk.
>
> I'm interested. Could you post
uence.)
>
It feels like noise to me; showing indexes/triggers/constraints affect how you
interact with a table, but whether a sequence is owned or not doesn't make a
significant difference. Given we don't list other dependencies
(views/functions/etc...) I'm not e
in c. I'm not sure there
should be any, but maybe someone with more experience in this area might have
ideas on what to watch out for?
--
Robert Treat
Conjecture: http://www.xzilla.net
Consulting: http://www.omniti.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ewhat underwhelming.
>
The one thing this test seems to overlook is at what point do we see
diminshing returns from increasing dst. I think the way to do this would be
to plot dst setting vs. query time; Robert, do you think you could modify
your test to measure prepare time and the
rs on *each* target.
>
This would amount to statement level triggers firing multiple times per
statement wouldn't it? That behavior might be rather surprising for folks. I
guess the alternative is to have it fire only on the parent in an inheritance
stack. I'm not sure that's much
1 - 100 of 848 matches
Mail list logo
