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
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
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
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
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
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
. 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
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
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
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
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
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.
>
&
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
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
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
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
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 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
;
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
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
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
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.
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:
&
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
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
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
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
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
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,
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
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
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
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
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
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
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
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
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
mentor it.
>
> > Which is not clear to me (yet), if it would required collecting enough
> > information through implementing a sort of 'VACUUM SUMMARY'[3].
>
> I would think this is a separate project from the maintenance window
> change proper.
IF the OP want's the pr
to me (though it may make
it easier for people getting in on the ground floor)
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 6: explain analyze is your friend
ave to break it up into partitions later, this
will raise a number of red flags.
> And in
> most cases it's being sequence-generated or something equally reliable so
> the constraints are really just there as a backstop; you're not depending
> on them for correctnes
ing statements due to server load and locking and
all of the above commands can certainly fall into that area. If people feel
strongly that the command line programs need a way to circumvent it, add
a --ignore-statement-timeout option or similar mechanism.
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
_damaged_pages as well (which is not on 8.0 AFAIR).
Um, can I get a pointer to that thread? I can't imagine why we
would actually want to automatically destroy our data without oversight from
a DBA... I must be reading that wrong.
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {
On Tuesday 17 April 2007 20:54, Tom Lane wrote:
> Robert Treat <[EMAIL PROTECTED]> writes:
> > I'm with Joshua on this one. Statement_timeout is often used as a means
> > for protection from long running statements due to server load and
> > locking and all of the a
On Wednesday 18 April 2007 11:30, Alvaro Herrera wrote:
> Robert Treat wrote:
> > On Tuesday 17 April 2007 20:54, Tom Lane wrote:
> > > I'm not excited about the other ones but I can see the argument for
> > > making pg_dump force the timeout to 0.
> >
> &
any mention of it in the docs.
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at
http://www.postgresql.org/about/donate
nformation. Documentation is a little more
permanent, and at least offers a record of agreement at a specific point in
time.
> As for inclusion in the docs I beleive we're still waiting for your
> patch...
>
We'll see :-)
--
Robert Treat
Build A Brig
ow_level to effect whether the last ANALYZE / VACUUM is recorded.
> (Plus, the optimization is not even enabled with the default
> postgresql.conf settings.)
>
+1
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)-
tch tracker), plus
> people putting in the effort to make sure it stays a valid source
> of up-to-date info. Without the latter it won't really be useful.
>
Maybe you just need to have a 1 week clock skew when reading pgsql-bugs?
--
Robert Treat
Build A Brighter LAMP :: Linux Ap
rg over to
> > pgfoundry so that ppl can't go *to* gborg's web site ... we can also
> > make the
> > CVS 'read-only', so that developers can't update the CVS there, but
> > ppl can
> > still download the code ...
> >
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
en when they
find out that they have now illegally included code that is licensed via some
other license.
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
for some patches,
so as unfortunate as it is, I think at some point you have to just suck it up
and call it day. all imho.
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
t the syntax, why
> were they not ALL expressed when the proposal was originally laid on the
> table?
> I haven't studied the proposed syntaxes in detail,
>
lol... just thought this was ironic. :-)
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} P
the dev
> version of the docs at
> http://developer.postgresql.org/pgdocs/postgres/rsync.html - although
> frankly it would be better to import the information rather than just
> refer to the buildfarm HOWTO.
>
And really should probably be written up into FAQ section or a full on guide
iles (maybe the files timestamp is older than postmaster start; though not
sure how you measure that), then I think this would be enough to give them a
way out. Of course maybe that level of smarts could be put into drop
tablespace itself?
--
Robert Treat
Build A Brighter LAMP ::
On Tuesday 29 May 2007 20:06, Jaime Casanova wrote:
> On 5/27/07, Robert Treat <[EMAIL PROTECTED]> wrote:
> > On Friday 25 May 2007 12:39, Jaime Casanova wrote:
> > > On 5/25/07, Tom Lane <[EMAIL PROTECTED]> wrote:
> > > > Bernd Helmle <[EMAIL PROTE
ld be result of rather complex select involving several tables.
>
Is there some reason for this restriction in the standard? I might be in
favor of "extending" the standard to allow this case if not.
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware}
for reasons that escape me
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 6: explain analyze is your friend
eone to suggest you move to an OS
> that supports dtrace.
>
You know that's what I was thinking :-)
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at
http://www.postgresql.org/about/donate
tool for
8.1->8.2. Unfortunately until the PGDG decides that in-place upgrade is a
constraint their willing to place on development, I see them a good
chicken/egg away from making it a continually usefull tool.
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} Postgre
ow been over a year since I first complained about the stable snapshots in
our ftp directory being outdated
(http://www.postgresql.org/ftp/stable_snapshot/), if no one is going to fix
that, can we remove them?
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
ts of this as three people (or four?) have hit it in the last week, all
doing seperate things. Coincidence, or sign of impending doom? :-)
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
tables.
>
> I'm happy to come up with a patch, but I figure there should be
> consensus first...
I generally recommend to try autovacuum first, augmented by
vacuum/analyze/reindex if you find trouble. I wont say there aren't
workloads that autvacuum wont handle, but in most cases
t; postmaster log?
>
> Even if it were just you and me. From my perspective, thats enough.
Well, Tom doesn't look at the log files, so I guess your idea is shot...
:-)
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
---(end of broadc
ance though.
> >
> > merlin
>
> I have an experience with writing ODBC driver for PostgreSQL
> (https://projects.commandprompt.com/public/odbcng/). I would be happy to
> help community to improve .NET data provider.
>
That would be nice. Of course none of this seems relevant
documentation,
> or just discussing the best ways to do things)
>
I'm not sure it is entirely inappropriate to discuss some of these items
on -hackers, if we're talking about general solutions to admin and/or gui
interfaceing problems (even the hacky non-core style solutions might
n
> and perl are all reversible.
>
Hmm I wonder if you could wire plphp through something like Zend Gaurd?
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
ent writers might
have caused potential issues by that point.
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
(and candies and nuts), that I fear will
lead to more confusion for end users, and make development more difficult in
the future as we forced to try and live with backwards compatability.
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
g, or is it floating around on someone's TODO
list? If it needs to be I could take a whack at it (though perhaps things are
still to in flux to worry about this yet?)
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)-
On Sunday 02 September 2007 10:29, Tom Lane wrote:
> Robert Treat <[EMAIL PROTECTED]> writes:
> > postgres=# \dF
> > Did not find any relation named "F".
>
> Works for me. When did you last recompile psql?
>
Blah I compiled last night, using th
should produce nothing more than a configure
warning. I looked at a handful of other machines configured for xml and they
all seemed right, but maybe someone can do a more thorough search in the db?
Or maybe there is a way to capture configure warnings?
--
Robert Treat
Build A Brighter LAMP :: L
On Wednesday 05 September 2007 00:06, Tom Lane wrote:
> Robert Treat <[EMAIL PROTECTED]> writes:
> > I get the following error during make (configure runs fine)
> >
> > /usr/include/netdb.h:560: error: syntax error before =E2=80=98[=E2=80=99
> > to= ken
>
>
; deliberately break any code that's depending on the transaction column.
> Any such code is unlikely to be prepared for the column containing nulls.
>
I don't buy this argument really only so far as the column can already be
null, so apps already need a way to deal with
On Wednesday 05 September 2007 18:40, Tom Lane wrote:
> Robert Treat <[EMAIL PROTECTED]> writes:
> > I'm trying to decide how reasonable the use case is. We have transactions
> > that run several hours long, often touching a number of tables, and I've
> > used
On Wednesday 05 September 2007 12:01, Tom Lane wrote:
> Robert Treat <[EMAIL PROTECTED]> writes:
> > On Wednesday 05 September 2007 00:06, Tom Lane wrote:
> >> BTW, on re-reading that, it seems a tad surprising to get an error right
> >> there --- if postgres_
Just wondering if it is already in 8.3 with a new name, or if not if there are
plans to add it? TIA
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 1: if posting/reading through Usenet
y overflowed-subxids proc)
> saving us from going through the slow answer path. So on reflection
> I can't see how this isn't a win. I'll clean it up and apply it.
>
Just curious, but does this apply to subtransactions that are the result of
plpgsql try...exception blocks?
sation and GNU
> > Website Localisation.
>
> Translations are handled through the pgtranslation project, see
> http://pgtranslation.projects.postgresql.org/contributing.html to get
> started.
I believe both the pgAdmin III and phpPgAdmin projects (and probably others)
would also
> Hope they aren't there at,
> http://pgtranslation.projects.postgresql.org/status.html
>
> what's the relevant link?
PgAdminIII
http://pgadmin.org/translation/
phpPgAdmin
http://phppgadmin.cvs.sourceforge.net/phppgadmin/webdb/TRANSLATORS?revision=1.13
--
Robert Treat
Bui
an simplify port to
> 8.3 with some small wrapper like my wrapper.
thank goodness I've switched to putting tsearch in it's own schema, so I can
easily seperate it with pg_dump.
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 6: explain analyze is your friend
ntrib, moving things either to core or to pgFoundry. Adding yet
> another important feature that's "just in contrib" is making things
> worse, not better.
> IMHO, of course ;-)
>
+1. I felt the same way about pg_standby, which would have been far more
accessible for 8.
tml or DocBook?
>
> Current form of F.A.Q. is little bit obsolette.
>
The FAQ's *are* managed in html, though we also keep a spare copy as plain
text for historical reasons. See doc/src/FAQ/
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
---
dry.
Putting it on pgfoundry would automatically put it in the ftp tree
(ftp://ftp.postgresql.org/pub/projects/pgFoundry). If it was to go on
pgfoundry (which I'd recommend) I'd suggest removing it from 8.3 contrib
before we release (cause having it in both places is really going
On Wednesday 10 October 2007 10:57, Andrew Dunstan wrote:
> Robert Treat wrote:
> > On Wednesday 10 October 2007 02:09, Simon Riggs wrote:
> >> On Wed, 2007-10-10 at 01:14 -0300, Euler Taveira de Oliveira wrote:
> >>> Simon Riggs wrote:
> >>>> I would
was talk that the txid contrib module could be folded into core should
we do an initdb post beta; has that idea been revisted now that we have?
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
gt; (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/access/gin/gi
>nxlog.c?r1=1.5.2.1&r2=1.5.2.2)
>
Not to put any pressure, but this fix had me wondering if we might see an
8.2.6 before 8.3 is out?
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} Postgr
>
you might also consider creating a tablespace on tmpfs or ramfs or something
like pramfs
> FYI, Postgres is know to be used successfully on some *extremely* heavy
> websites, without using tables pinned in memory.
>
+1
--
Robert Treat
Build A Brighter LAMP :: Linux A
In a lot of common scenarios, NOTICEs
> aren't going to be seen by the actual person entering the query anyway,
> because there are layers of software between him and the DB. All they
> will accomplish is to bloat some logs somewhere.
>
> Comments?
I would lean toward #1 since it seems to be closest to the behavior from
previous releases.
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 6: explain analyze is your friend
more
update after 8.3 is akin to giving a 1 month EOL notice; not friendly at all
imo. Set it for July 2008 and I think you have given plenty of notice (and
given the lack of back patches, should be too much of a burden in that time
either)
--
Robert Treat
Build A Brighter LAMP :: Linux Apache
of the open
source platforms; it was something specific to the postgresql core project
though; ie. something likely discussed on the postgresql mailing lists, or
involving the central project.
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
ormation. Furthermore it seems inactive people is removed
> eventually, which doesn't happen with release notes.
Unless it's been changed, I added the "past contributors" section just for the
purpose of giving a historical credit and ongoing thanks for past
contribution.
When timestamptzs are converted to timestamp, there is no time adjust, you
simply lose the tz offset information:
pagila=# select now(), now()::timestamp;
-[ RECORD 1 ]--
now | 2007-12-09 11:25:52.923612-05
now | 2007-12-09 11:25:52.923612
If you store without timezone, you lose the origina
email, but in any case is there some reason it can't print out the proper
user name (maybe some encoding issue?)
3) as far back as I can remember, -u has been deprecated, so if we dont want
to revert to it (see 1) maybe it should just be removed entirely?
--
Robert Treat
Build A Br
the person to contact if you had questions/comments/patches/etc...
about a specific contrib module. I wonder if people would still get the same
level of help if those names are removed and they have to go to the regular
mailing lists for help (which contrib authors may not follow).
--
Robert Tr
0661
timezone | 2007-12-09 15:25:19.240661-05
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your j
On Sunday 09 December 2007 13:33, Tom Lane wrote:
> Robert Treat <[EMAIL PROTECTED]> writes:
> > 1) I don't recall why -u was ever deprecated (and honestly postgresql is
> > the only program I know which uses -U rather than -u) but maybe we should
> > revert
On Monday 10 December 2007 10:16, Tom Lane wrote:
> Further down the road, those whose notion of "intuitive" was formed
> by mysql might lobby to have -u become an alternate spelling for -U,
crontab, truss, sudo, ps, strace, top, etc...
--
Robert Treat
Build A Brighter LAMP
tm how this feature would be managed is as important
as the bits under the hood. Or at least we have to believe there will be
some practical way to manage this, which as of yet I am skeptical.
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
different table spaces. That could be considered
> an approach to range partitioning. But then, that would be the
> partitioning, and not SVM or Segment Exclusion. To me, both of SVM and
> SE look much more like an optimization for certain special cases and
> don't have much to do with
1 - 100 of 848 matches
Mail list logo
