be necessary.
> >
> > We have that (might be new for 7.4, I forget).
>
> Yes, new for 7.4: log_min_error_statement.
>
Actually it is in 7.3 as well
7.4 does have some new options though, including log_min_messages (or is
that the same as server_min_messages in 7.3?), lo
of potential
> index mismatches either.
>
In all this discussion of NOTICE vs. WARNING, can someone remind me the
logic for INFO? I can't seem to recall the differentiator there either.
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
-
ething even though they are arn't really doing anything:
=> alter table test set without oids;
ALTER TABLE
=> alter table test set without oids;
ALTER TABLE
=> alter table test set without oids;
ALTER TABLE
I think popping a notice that the table is already without oids could be
http://developer.postgresql.org/ftpsite/binary/v7.3.4/RPMS/
Robert Treat
On Thu, 2003-08-28 at 11:18, Marie G. Tuite wrote:
> Same issue - are there rpms anywhere for 7.3.4?
>
> Thanks.
>
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTE
quote-less quoting
:-)
Robert Treat
On Mon, 2003-09-15 at 02:38, Andrew Dunstan wrote:
>
> - Original Message -
> From: "Tom Lane" <[EMAIL PROTECTED]>
>
>
> > Hannu Krosing <[EMAIL PROTECTED]> writes:
> > > Tom Lane kirjuta
mmitted mode. The first seems like the
easier to implement, though I think some don't feel it is an elegant
solution. The second would be more powerful, but exactly how to
implement it seems mysterious (the one good explanation I heard required
nested transactions). Personally I would love to
gether so that the long running query
actually ends but another query fires up between the time you lookup the
long running query and the time you issue the kill...). maybe
transaction id as well as pid for arguments?
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} Postgr
Cause no one thought of it? I've gone ahead and submitted something, in
the future don't hesitate to submit news items you think are of
importance to the community.
Robert Treat
On Tue, 2003-09-23 at 14:11, Neil Conway wrote:
> Is there a reason why there haven't been any 7.4
`/usr/local/src/postgresql-7.4beta3/src/pl/plperl'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/usr/local/src/postgresql-7.4beta3/src/pl'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/usr/local/src/postgresql-7.4beta3/src'
make: *** [all] Error 2
any ideas?
need any
e do so either by their own choosing or because
the proposed implementation is not quite "ready for prime time" enough
to be included.
oh.. and i'm not forgetting plphp, but it has both licensing issues and
isn't ready for prime time.
Robert Treat
--
Build A Brighter Lamp :: Lin
On Thu, 2003-09-25 at 13:26, Bruce Momjian wrote:
> scott.marlowe wrote:
> > On 25 Sep 2003, Robert Treat wrote:
> >
> > > oh.. and i'm not forgetting plphp, but it has both licensing issues and
> > > isn't ready for prime time.
> >
> > I t
>> > Can you think of any others?
>
> -- Incorrect estimate for result of DISTINCT or GROUP BY.
Yeah, that one is bad. I also ran into one the other day where the planner
did not seem to understand the distinctness of a columns values across table
p
---
2
1
(2 rows)
pagila=# select staff_id from staff order by picture;
staff_id
------
1
2
(2 rows)
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 1:
le we are still in beta. Is there a backwards compatability
issue for older systems? (Not that this doesn't get worse if we release yet
another release with it)
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)-
ople are
> looking for outlines.
>
> A
Unfortunately the techdocs system won't support a url like the one above,
rather you'll end up with something more like the following
http://www.postgresql.org/docs/techdocs.54 which is the "GUI Tools Guide"
(which is linked
gt; Perhaps even allowing all of the \set commands to be case-insensitive
> may be a good idea?
\typo
;-)
--
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
On Thursday 02 November 2006 17:48, Tom Lane wrote:
> Robert Treat <[EMAIL PROTECTED]> writes:
> > pagila=# select to_date('3232098', 'MM/DD/');
> > to_date
> > ---
> > 4568-06-26 BC
> > (1 row)
>
> to_date&#x
I've adjusted the links on the website to match what's
actually up there, but it might be a good idea to remove the beta2 directory
from http://www.postgresql.org/ftp/source/ lest someone gets confused about
where to look for the most recent beta.
--
Robert Treat
Build A Brighter LAMP
write NULL for the
> element value. (Any upper- or lower-case variant of NULL will do.) If
> you want an actual string value "NULL", you must put double quotes
> around it. Note that if you use the ARRAY construct you should just use
> a bareword NULL instead.
This is not ter
hat seems problematic is the
indexed, frequently updated timestamp field.
--
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
On Sunday 12 November 2006 16:23, Simon Riggs wrote:
> On Sun, 2006-11-12 at 13:01 -0500, Robert Treat wrote:
> > On Friday 10 November 2006 08:53, Simon Riggs wrote:
> > > On Fri, 2006-11-10 at 12:32 +0100, Zeugswetter Andreas ADI SD wrote:
> > > > 4. although at f
would like to see this
functionality because it helps me with phppgadmin, then I would lean toward
#1 (for a number of reasons really)
Personally I think I'd rather see the whole thing pulled, renamed to its own
schema, and toss in a version function and a kill backend function and let
rk to finish it. If someone wanted to try and complete that work I
don't think anyone would stand against it.
--
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
of entries with schema and table names (rather than vacrelid) since otherwise
it is too much pita to keep things straight. My intent is also to add
controls at the table level (where we'll know the vacrelid anyway) though it
will probably be put off until there is more demand for it.
--
ose.
The current terminology of live and dead is already used in many places in the
documentation and in userspace; mostly around the need for maintainance of
dead tuples within tables, reindex cleaning up dead pages, and even in the
vacuum commands output (n dead tuples ca
m history. GUC variables that change
> > > transaction-boundary semantics are a bad idea, period: see autocommit.
> >
> > Nod. Let's get this TODO removed.
>
> OK, removed.
I thought this was needed for spec compliance? If we have no plans to even
attempt to su
indicate alpha quality, under heavy
> > development.
> >
> > I don't find the reasons too compelling - but they are points to
> > consider.
>
> 5) GNUTLS does not run well under all of our supported platforms.
>
given options like --enable-dtrace and --with-libedit-pre
person
or entity to whom this message was originally addressed.
Please delete this e-mail, if it is not meant for you.
---
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
---(end of broadcast
ne of our
systems, and the only method that seems workable is using PITR with weekly
filesystem snapshots as the base and then copying the xlogs offline for
re-play. It's still tricky to get right, but it seems to work.
--
Robert Treat
Database Architect
OmniTI Computer Consulting, Inc.
cording to thier numbers, we currently
cover about 40% of the code base.
http://developer.spikesource.com/info/search.php?c=POSTGRESQL&view=details
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)
irc (I don't think it has been updated at all in the
8.x series, so my memory is pretty fuzzy on this), so if I could avoid
changing it I would...
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)
s a "you know what would be sweet" moment.
> >
> > The dreaded words from a developers mouth to every manager in the world.
>
> Yea, I just instinctively hit "delete" when I saw that phrase.
Too bad... I know oracle can do what he wants... possibly
erns of the tables
involved. I suspect that isn't that uncommon really. I've often thought that
being able to set guc variables to a specific tablespace (like you can do for
users) would allow for a lot of flexibility in tuning queries that go across
different tablespaces.
--
Robert
at perform
is this behavior by design? if so why would you design it that way? :-)
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 6: explain analyze is your friend
On Tuesday 20 February 2007 12:50, Tom Lane wrote:
> Robert Treat <[EMAIL PROTECTED]> writes:
> > pagila=# create or replace function test() returns bool as $$ begin set
> > statement_timeout = 3000; perform pg_sleep(4) ; return true; end $$
> > language p
not going to be moving the datafiles on disk
anyway,so pg_migrator's behavior shouldnt change terribly. If your doing
pg_dump based upgrade, presumably pg_dump could write it's create statements
with the columns in attstorpos order and set attnum = attstorpos, preserving
the physical la
becomes chatter. Can you come up with an idea of what information DBA's need
to know? Would it be better to hide all of this logging behind a guc that
can be turned on or off (log_bgwriter_activity)? Maybe you could just
reinsterment it as dtrace probes so a seperate stand-alone process cou
ures-at-once is what the community wants, that's fine,
> no worries. I'll just pull my own personal hat out of the ring until
> someone comes along who's interested in implementing them both at the
> same time.
>
Are you that opposed to working on the display portions as well? You'll be a
hero to thousands of mysql users if you do it.
--
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
bit by this today and, afaict the best solution for the status quo would
be to change the install schema to something like tsearch2, which would then
allow for much easier dump and restore handling.
--
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
e) and allows you to pick which
column you want to merge in (repo, change1, or change2 for example). It's a
nice attempt at doing it on the command line, but the graphical version is so
much better it's worth it to work out remote X and use that instead :-)
--
Robert Treat
Build A
On Monday 26 February 2007 14:57, Andrew Dunstan wrote:
> Robert Treat wrote:
> > FWIW ClearCase also offers a command line version of its merge tool,
> > where it shows three columns (a la diff --side-by-side) and allows you to
> > pick which column you want to merge in (repo
> We have the opportunity to
> wait and see what will emerge in the SCMS competition, and IMHO that's
> what we should do. There are many more-pressing things for us to spend
> time on right now than an SCMS conversion.
>
100% Agreed.
--
Robert Treat
Build A Brighter LA
ubmit the application. If you get buy in / agreement from multiple
community members on a project now, it can only help your chances in the SoC
process. (Picking items from the TODO list is a good way to start if you need
ideas)
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} Po
l, at least I
> didn't see it.
>
Sergey, could you do a little research on what behavior other databases that
support user quotes exhibit? This might help folks judge whether any
proposed solution for postgres will be above or below potential users
expectations.
--
t; Yeah. Including recovery. Maybe we could do something that would work in
> cooperation with FS quotas - I have no idea what though.
>
I've actually run postgresql systems out of disk space both on data partitions
and wal partitions and never suffered corruption. Certainly I don't
gt;
> Of course not, but that isn't the point. The point is, *we told you so*,
> *you chose not to listen* and here it is documented.
>
As long as we're pretending that were doing this right, we ought to add the
notice as part of the list signup message that is sent out to an
to ignore writing wal logs for the table, much like
it does for temp tables now. One cavaet would be you would probably need to
forbid such a table from being the parent side of a FK relationship, but
otherwise this should be fairly safe even for replay since alter table needs
an exclusive
is would be better.
>
ISTM you're trading appending the master table for appending the DUMP
partition, which afaict would give you no gain.
--
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 joining column's datatypes do not
match
ion will avoid that.
>
> I have seen examples in some other databases wherein a partition specifies
> a range of "someval - MAXINT" for instance, to catch such cases.
>
> That again means that the onus is on the partition creator most of the
> times..
*shrug*... we
features.
So is this actually going to be improved in a core tsearch? system tables
are not dumped by default, so that seems easier, until you consider that your
custom tsearch install will then be lost on upgrade... oops!
--
Robert Treat
Build A Brighter LAMP :: Linux Apache
s going to solve that type of problem, but maybe
I am overlooking something?
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
8.3, seems, API to index AM will be changed - will anybody
> except pghackers see that? New opclass layout, new opfamily table - users
> don't that changes at all.
If I have configured my tsearch install for spanish (spanish
dictionary/stemmers/synonyms/etc...) aren't I going to lose
free - you just set up the cron
> job(s) or equivalent.
>
Dave,
wasn't someone just trying to donate a machine to us for the website but we
weren't sure what to do with it? One that could do VM's? Seems we could use
that for some buildfarm
On Monday 26 June 2006 03:28, Dave Page wrote:
> > -Original Message-
> > From: Robert Treat [mailto:[EMAIL PROTECTED]
> > Sent: 24 June 2006 20:50
> > To: pgsql-hackers@postgresql.org
> > Cc: Andrew Dunstan; Tom Lane; Dave Page
> > Subject: Re: Any
r not going to find it in the contrib modules in
some small corner of the the ftp archive, but they might have a chance of
finding it on pgfoundry.
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 6: explain analyze is your friend
e projects if you nuke them, but I like giving people
options... your call though.
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an a
the most visible place...
All I am saying is that it couldn't hurt to put the information out there...
we're not hurting for disk space and none of this stuff appears inherently
wrong, just outdated, but it might still prove useful for some people.
--
Robert Treat
Build A
nd it. Putting it on foundry gives it a
chance at finding an active maintainer... leaving it in the archives of CVS
will guarantee you don't get one. Since most people seem comfortable with
that, so be it.
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
it's the same question. If *you* want to be the maintainer, I'll
> put it on pgfoundry. Otherwise, you're asking me to be responsible for
> the code because you don't want to throw it away.
>
I really don't see how this will actually cause you any extra e
I believe it was Lukas who mentioned elsewhere, this is not a vendor nuetral
project. I actually am already working on a adding a list of os/package
options to the download page based on other feedback, are people comfortable
allowing mammothpostgresql to go on that list? (I wouldn't be
vacuum I almost always use vacuum verbose, just so I have an
> idea of what is going on.
>
+1
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, p
n't actually map to any real world
value. Unless of course we wanted to add MV for "magic value", but then
people would want to use that for everything ;-D
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)-
orking on that?
>
> I don't recall that anyone expressly agreed to do so; I'll see if I
> can, this week...
A META-FAQ Style document on techdocs would be nice... we could then link to
that from the pg faq.
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware}
php/etc...). This solution would solve that problem for us, so I would
lean toward including it. I would be interested in hearing from actual users
who really need the subselect version though, but right now my thinking is
that group is a small minority of who would benefi
We'd like to fix that, but it's not fixed yet
> AFAIK.
>
Josh, can you clarify this statement for me? Using work mem of higher than
256MB is common practice in certain cases (db restore for example). Are you
speaking in a high volume OLTP sense, or something beyond this?
--
Ro
e note... has the on-disk format changed for this release? I don't
recall seeing anything that changed it, but could have easily missed
something.
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)-
ead out 2 years apart, but people could get
new features / imporvements each year if they wanted to. It sounds like a
good idea in theory, but would take some real world wrangling to achieve it.
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
-
surely have people who are interested in
participating.
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
anner is not smart enough (with a mix of wanting hints)
vacuum leads to unpredictable performance
Of that list, they could probably all be turned into nice marketing points
(though #4 is pretty nebulous), though I don't see any of them getting
resolved anytime soon.
--
Robert Treat
Build A
Is there a way to determine which datatypes take a length argument (eg.
varchar, time, etc...) by looking in the system catalogs? pg_type doesnt seem
to have the info... or is there a single place in the back end code that
contains this info?
--
Robert Treat
Build A Brighter LAMP
On Wednesday 09 August 2006 10:53, Martijn van Oosterhout wrote:
> On Wed, Aug 09, 2006 at 10:44:22AM -0400, Robert Treat wrote:
> > Is there a way to determine which datatypes take a length argument (eg.
> > varchar, time, etc...) by looking in the system catalogs? pg_type doesnt
&
add this as a
TODO with the following wording: blah blah blah" likely suffice?
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an a
> That's what I was thinking. Glad someone else replied. ;-)
> >
> > If you're looking for votes, +1. I'll gladly take a subset of the
> > SQL standard UPDATE table SET (...) = (...) over having nothing.
>
> +1 here, too. :)
>
+1
--
Robert Treat
Buil
reduce the
> amount of noise. The other systems that have been mentioned have by
> design little or no barrier of entry, which doesn't seem to be what we
> want.
I'm not sure I follow this, since currently anyone can email the bugs list or
use the bugs -> email form f
the other way, it seems
the guy who actually codes something offers a better solution than
handwaving... people have also had plenty of time to come up with a
replacement if that's what they really wanted.
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
-
ne vs. gui thing, but I suspect there
are some other tricks people have to make emails more manageable (anyone
combine all pg mail to one folder?)
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)-
ware in the repository. I do have time to
> package all related stuff.
>
Any chance at getting some of the non-core pl langs in ?
--
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
e patches that need review, they can't
figure out who is reviewing what, or they don't think anyone is paying
attention when they do review something, then I think we have a serious
problem and we certainly need to change processes. What I think you'll find
is that they are all
#x27;t require patch submitters/committers
to update the release notes when they do the patch. I know Bruce says that
it's not a problem for him to do it, but it sure would help out some of the
other folks.
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} Postg
g? (Yes, this does require some of the other folks to step
up... responses to your original email with "I will commit to finishing this
item this week" would probably be enough)
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 6: explain analyze is your friend
ever show up. We've already set on-disk bit-map
indexes straight on this and I think giving you special treatment sets a bad
tone for the project. At this point I think we have to cut the release notes
from this release... maybe they can be added back in for 8.3.
>;^)
--
Robert
"no changes to file formats" on this extra-quick
release? Otherwise I have to agree with Joshua, I'll be recommending against
upgrading to 8.2 on any significantly sized databases.
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
r to have auto-vacuum on than to do nothing, so why not give
our users a better starting position if we can? Otherwise why are we doing
things like attempting to auto-set options in the conf file based on system
specs?
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware}
Of
course my angle is making the upgrade from 8.2->8.3 as painless as
possible... if we can avoid a dump/reload cycle then people are less likely
to have to choose between 8.2 and 8.3, which would make everyone happy I
imagine.
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middlew
heory, but it seems logical, and should be
easy enough to reproduce with a simple LOOP ... END LOOP in plpgsql.
--
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
n't see the doc patch, and outside of
installation.sgml there doesn't seem to be anything either. Robert, are you
still on the hook for these? Also should installation.sgml mention the
issueswith building 32 vs 64 bit binaries and/or the issue with static
functions?
--
Robert Treat
Bu
at when your dealing with queries that have run times in multiples of
hours (and the corresponding hour long index builds) EXPLAIN ANALYZE just
isn't an option. Anything that can be done to wheedle down your choices
before you have to run EXPLAIN ANALYZE is a bonus.
--
Robert Treat
B
f a patch already in
progress I'm CC'ing him so he can clarify but I'd hold off till you spoke
with him... and we should probably update the TODO once he speaks up as well.
--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 8: explain analyze is your friend
no one objects, lmk.
--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
On Sunday 20 March 2005 13:24, Tom Lane wrote:
> Robert Treat <[EMAIL PROTECTED]> writes:
> > know that it doesn't match reality at this point. We could have someone
> > update it and then generate it out of cvs onto the website, but it really
> > seems like the k
in the order of PHP,
PostgreSQL,plPHP which is the same for all of the other pl's.
You don't need postgresql installed before php any more than you need it
installed for perl (although you do need postgresql installed to compile some
of the perl & php db interfaces, but th
On Mon, 2005-04-04 at 16:17, Tom Lane wrote:
> Robert Treat <[EMAIL PROTECTED]> writes:
> > On Monday 04 April 2005 12:01, Tom Lane wrote:
> >> Peter has pointed out that the problem of circular dependencies is a
> >> showstopper for integrating plPHP.
>
>
On Mon, 2005-04-04 at 17:03, Alvaro Herrera wrote:
> On Mon, Apr 04, 2005 at 04:48:50PM -0400, Robert Treat wrote:
>
> > If by "stripped down" you mean without postgresql database support then
> > I'll grant you that, but it is no different than other any o
On Mon, 2005-04-04 at 17:00, Doug McNaught wrote:
> Robert Treat <[EMAIL PROTECTED]> writes:
>
> > If by "stripped down" you mean without postgresql database support then
> > I'll grant you that, but it is no different than other any other pl
> > wh
re the particular record type is
> implied by the set of output parameters. See my previous proposal.
>
While it is useless in this example, istm it only makes things more
confusing to require return in some cases but not in others. Is there
some technical advantage to dropping it?
R
uld do a
> bulk update of pg_cast as part of database creation.
>
> Thoughts?
One potential ugly way to do it would be to use the magical "last system oid"
as a differentiator between those created by pg and those created by the
user. It would be different for every version so
und release time and integrated in the relevant changes; I've also
submitted a patch or two based on suggestions that have come across
since we got the new system in place. If you're interested in moderating
the comments and have time to write patches for new suggestions I'm sure
mos
pints waiting for you
from a great many postgresql users if you can eliminate this problem with the
work you're doing on shared row locks.
--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP
There is a fairly lengthy discussion going on right now on the bizgres
mailing list about this topic, if your interested in helping out you
might want to join that list.
Robert Treat
On Tue, 2005-04-26 at 05:43, [EMAIL PROTECTED] wrote:
> Ok!
> The Links your posted are great and i guess
27;t see a good reason to treat this setting different
from all others and explicitly forbid this use from people, especially
when I can imagine people coming from other dbs where this behavior is
more common who might in fact expect it to work this way.
Robert Treat
--
Build A Brighter Lamp :: Linu
401 - 500 of 848 matches
Mail list logo
