ou folks feel about adding a dtrace probe to look for this? I
haven't exactly worked out where/how this would be put, but it would allow
for easily tracking these via dtrace if we had one.
--
Robert Treat
Conjecture: http://www.xzilla.net
Consulting: http://www.omniti.com
--
Sent via pgsql-
distributions.
>
We actually have such a database on pgfoundry already
(http://pgfoundry.org/frs/download.php/1719/pagila-0.10.1.zip), which i think
devrim may have packaged into an rpm; it wouldn't hurt to add it to the win32
installer, but would you feel better if it were a con
bear in mind that the reordering hook is guaranteed to
> alter only the order
> of the "CREATE TABLE" fields. (The original and the modified dump
> will differ only in that;
> even in the case of dropped columns and inherited tables). The only
> possible troubling scena
quire being in the public
schema (which I have learned the hard way). It's probably possible to make
them work in different schemas, but just changing the install schema will
break them right now (i think intarray is an example of one)
--
Robert Treat
Conjecture: http://www.xzilla.net
Cons
On Monday 27 October 2008 12:12:18 Simon Riggs wrote:
> On Mon, 2008-10-27 at 11:42 -0400, Robert Treat wrote:
> > On Monday 20 October 2008 05:25:29 Simon Riggs wrote:
> > > I'm looking to implement the following functions for Hot Standby, to
> > > allow th
equired.
>
> What else do we need?
>
Is it possible to give the master/slave knowledge about each other?
--
Robert Treat
Conjecture: http://www.xzilla.net
Consulting: http://www.omniti.net
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
to stay in contrib, and that we ought to accept
patches improving it.
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
gh I still wouldn't mind seeing some size specific
information, similar to what vacuum verbose emits.. eg.
INFO: "my_users_mods": removed 790 row versions in 4 pages
INFO: "my_users_mods": found 790 removable, 308 nonremovable row versions in
6 pages
--
Robert Tre
you, I'd bet
they'd much rather see time spent in turning that off rather than
checksumming everything else. (just guessing)
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
management than api
management, but might be helpful. (note, getddl is still pretty rough around
the edges).
(1) http://phppgadmin.sourceforge.net/
(2) https://labs.omniti.com/trac/pgsoltools/wiki/getddl
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} Post
experience running it atop solaris... just
in case you guys ever do want to do a migration or something ;-)
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
les;
since pg_tables is presented as a more user-friendly option to something like
pg_class this might be something more widely used, plus we don't have the
easy way out of just telling them to use the oid instead like we do with
pg_class.
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
--
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 24 September 2008 03:27:44 Simon Riggs wrote:
> On Wed, 2008-09-24 at 00:30 -0400, Robert Treat wrote:
> > here are some scattered thoughts i had while reading it :
>
> Thanks for your comments.
>
> It is very detailed, so further feedback is going to be very b
come i'm sure, but fading out... thanks again for the work so far
Simon.
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
any way to make that happen? Is my SIGSTOP idea dangerous?
If Heikis solution applies, it's better (see also vacuum_freeze_min_age) , but
if its too late for that, you can go into single user mode, which will
prevent autovacuum; it's a bit more heavy handed though.
--
Robert Treat
On Friday 19 September 2008 14:05:36 David E. Wheeler wrote:
> On Sep 18, 2008, at 18:43, Robert Treat wrote:
> >>* Google Code
> >
> > does not offer mailing lists
>
> I get mail for the test-more project there. It's through Google
> Groups, which is
and get into the project directory service. What we really want is
to make it easy for people to find postgresql related projects, regardless of
where they are.
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
hange anything should be fine to call)
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
fig file correctly before restarting,
I do not want you anywhere near any instance of a production system"
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
each setting is from (and possibly edit it).
>
If I have read this patch right, anything commented out (aka all of our
default values) will emit null in these fields... right? Trying to decide
just how helpful this will actually be for tool writers.
--
Robert Treat
Build A Brighter LAMP :: Linux A
those directories, but not create
directies in those locations. In that scenario, the DBA couldn't create the
directories if he wanted, so allowing the behavior to use an existing
directory would be helpful.
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
--
are not dumped with
the other installation wide settings. Meaning that pg_dumpall -g has no
bearing on the alter database commands being set, you actually have to
dumpall the entire data set to get those lines.
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
--
On Wednesday 20 August 2008 02:22:26 Jaime Casanova wrote:
> On Tue, Aug 19, 2008 at 9:40 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> > Robert Treat <[EMAIL PROTECTED]> writes:
> >> I'd still like to see us adopt the proposal from some time ago where
> >>
f that, hiding options seems
about the worst choice we could make. If people really don't like large conf
files, it is far easier to delete entries than it is to add them... Greg
Mullane had it right, and Greg Smith was not too far off the mark either.
--
Robert Treat
Build A Brighter LAMP
gue they'll be turning this off?
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
d for functions returning
> > "record"
> >
> > There's no longer any very good reason for built-in SRFs to not define
> > their own output record type.
>
> TODO updated:
>
> * Fix all set-returning system functions so they support a wildcard
>
a iphone to the
phppgadmin project, I'd be happy to spend some time making this work
better. :-)
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://
tion that way. Ideally this
could be done as PGC_SIGHUP, and a change to the location would move the
file "on-the-fly" as they say. (There might be practical limitation to making
that work, but it would certainly be simpler for admins, imho)
--
Robert Treat
Build A Brighter LAMP :: Li
On Tuesday 05 August 2008 04:36:24 Magnus Hagander wrote:
> Robert Treat wrote:
> > On Monday 04 August 2008 15:38:35 Josh Berkus wrote:
> >> Post-mortem things we've learned about the commitfest are:
> >>
> >> 1) It's hard to get anything do
who wants to be CF Manager for September? I'm willing to do it
> again, but maybe someone else should get a turn.
>
Why stop now when you've got the momentum? :-)
Seriously though, I thought we were supposed to have 2 people working as CF
Managers for each CF... is
On Monday 04 August 2008 15:56:25 daveg wrote:
> On Mon, Aug 04, 2008 at 02:35:07PM -0400, Robert Treat wrote:
> > On Monday 04 August 2008 03:50:40 daveg wrote:
> >
> > That's great for you, I am talking in the scope of a general solution.
> > (Note I'd also
On Monday 04 August 2008 16:49:43 Simon Riggs wrote:
> On Mon, 2008-08-04 at 14:35 -0400, Robert Treat wrote:
> > On Monday 04 August 2008 03:50:40 daveg wrote:
> >
> > And you'll note, I specifically said that a crude tool is better than
> > nothing. But your compl
On Monday 04 August 2008 03:50:40 daveg wrote:
> On Sun, Aug 03, 2008 at 10:57:55PM -0400, Robert Treat wrote:
> > ISTR that what ended up killing the enthusiasm for this was that most
> > people realized that this GUC was just a poor tool to take a stab at
> > solving oth
> immediately after planner executes, so you can implement this yourself,
> plus some other possibilities.
>
I still think it is worth revisiting what problems people are trying to solve,
and see if there are better tools they can be given to solve them. Barring
that, I suppose a cru
> to try to restart it?
>
Certainly there isn't any reason to allow a reload of a file that is just
going to break things when the first connection happens. For that matter,
why would we ever not want to parse it at HUP time rather than connect time?
--
Robert Treat
Build A Brighte
ase-
> > insensitively? (See the "TODO" tests.)
> >
> > * Should there be any other casts? To and from name, perhaps?
>
AIUI, your propsing the following:
select 'x'::citext = 'X'::citext;
?column?
--
t
(1 row)
select 'x'
rts --- I was hoping for a link that advances when the
> commit fest is done so I could make it a permanent tab in Firefox.
This is what I had proposed/changed, but see up thread where Tom disagreed
with this idea.
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware}
On Saturday 05 July 2008 18:07:46 Robert Treat wrote:
> On Thursday 03 July 2008 15:12:08 Joshua D. Drake wrote:
> > On Thu, 2008-07-03 at 20:06 +0100, Dave Page wrote:
> > > On Thu, Jul 3, 2008 at 8:02 PM, Marko Kreen <[EMAIL PROTECTED]> wrote:
> > > > On
ng got 95% of the patches reviewed and the
> other 5% in progress.
>
I think people are still working there way through the process, but it's
starting to sound like submitting a patch involves two steps from now on;
email to the list, and add your patch to the next commitfest page. Does
ying to find your way around within the wiki itself well, maybe I will
get some time to fix that in the next couple of days.
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
inherently insecure. If that is more
than just a philosphical opinion, I wonder if there should be additional
hurdles in place to enable this on that platform. Note that isn't an
objection from me, though I'm curious if any of the Sun guys want to chime in
on this.
--
Robert Trea
iginal
patch from Robert Lor. It is supposed to build on OSX and Solaris. I'll be
updating the July commitfest entry to point to this patch, case anyone wants
to review it.
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
Index: src/backend/access/trans
for people to start volunteering to review stuff! I'll start
> round-robin after a few days. So put your names on the stuff you know
> you can review now.
>
Note that Robert Lor has an updated patch for the dtrace probes that we have
seen over here @ omniti, but I don't think he h
suggesting is that we take the safety off, because it
> > interferes with your golf game.
>
> https://www.redhat.com/archives/fedora-devel-list/2008-June/msg01501.html
>
> So is that a "golf club gun"?
>
Careful what you wish for
http://www.totallyabsurd.com/12g
les (whose C functions or similar may have changed), and
then load the dump into the database. In those case you still might want the
database settings to be dumped, even though you are creating the database
manually. (Now, one might argue that you could still dump with --create and
ignore t
DATABASE commands I need to dump the schema for
> the entire cluster. Is that really desired behaviour?
>
Certainly not desired by a number of people I have talked to, but I don't have
much hope in seeing the behavoir change... perhaps someday if we get around
to merging pg_dump and pg_dumpal
elp me out
>
> The function executed by the trigger will be executed as a single
> transaction. If any part fails, they all fail.
>
Well, wrapping the bits of table2 in a beginexception block would allow
him to do what he wants.
--
Robert Treat
Build A Brighter LAMP :: Linux A
t;
I think there are other places this might manifest itself besides
pg_stat_activity... I'm struggling to come up with something other than our
custom dtrace prob... ah, well, this will also control the size of statement
written into the logfile right? So we might want to take that into account.
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ile module support is still vaporware.
However, I am looking forward to your patch. :-)
BTW, I am suspecting part of your support will be giving pg_dump -m and -M
flags to control dumping or ignoring of specific modules?
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
contribmodule, makes things like this much easier to work around. (And yes,
I've volunteered to patch the contribs with this if we ever decide to make it
the default setup)
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
--
Sent via pgsql-hackers mailin
STM somewhere between the description and the experience pieces, you have
plenty of ways to list your contributors. Also, don't forget we allow
contributors to list companies next to thier names if they so desire.
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} Postg
On Sunday 15 June 2008 22:31:59 ITAGAKI Takahiro wrote:
> Robert Treat <[EMAIL PROTECTED]> wrote:
> > On Friday 13 June 2008 12:58:22 Josh Berkus wrote:
> > > I can see how this would be useful, but I can also see that it could be
> > > a huge performance burden w
s type of information is to quantize dtrace
results over a specific period of time. Much nicer than doing the whole
logging/analyze piece.
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make ch
fore saving when editing via
> > >> pgAdmin or similar.
> > >
> > > Should this be a TODO?
> >
> > Yes please.
>
> Added to TODO:
>
> * Add pg_ctl option to do a syntax check of postgresql.conf
>
ISTM we need something that can run inside the
On Thursday 12 June 2008 21:11:57 Tom Lane wrote:
> Robert Treat <[EMAIL PROTECTED]> writes:
> >>> looking in my freshly installed 8.3.3, I see this in the
> >>> postgresql.conf #client_encoding = sql_ascii# actually,
> >>> defaults to da
On Thursday 12 June 2008 17:38:26 Tom Lane wrote:
> Robert Treat <[EMAIL PROTECTED]> writes:
> > looking in my freshly installed 8.3.3, I see this in the postgresql.conf
> > #client_encoding = sql_ascii# actually,
will
be in, but since it does know what encoding template0 & friends will be in,
and most databases are copied from those (including encoding), wouldn't a
better default be to set it the encoding of template0?
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} Postgr
ou can make that
an "out of the critical path" operation.
if you extend this to a more general "create constraint concurrently" (to
handle normal constraint, not null constraints, etc...), it would certainly
be a big win, and i think most would see it as a reasonable compromise.
On Sunday 08 June 2008 20:12:15 Tom Lane wrote:
> Robert Treat <[EMAIL PROTECTED]> writes:
> > and i'm sure no one is against that idea, but you're never going to be
> > able to match the performance of just avoiding the check.
>
> We'll never be a
On Sunday 08 June 2008 19:07:21 Gregory Stark wrote:
> "Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> > On Fri, 2008-06-06 at 20:19 -0400, Tom Lane wrote:
> >> Robert Treat <[EMAIL PROTECTED]> writes:
> >>
> >> Actually, the reason it
no one is against that idea, but you're never going to be able to
match the performance of just avoiding the check.
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
s whole proposal would be a major footgun which would definitely be
> > abused, IMNSHO.
>
> OK, understood. Two negatives is enough to sink it.
>
Heh, I would have argued that the idea should go the other way and just make
this part of the normal syntax. Oracle DBA's have bee
On Friday 06 June 2008 14:32:27 Robert Lor wrote:
> Robert Treat wrote:
> > certainly by the time 8.4 ships, these should work with freebsd I'd
> > think. ideally we would need to confirm this by release time, certainly
> > getting a bsd buildfarm member to compile with
l settings that no
> PostgreSQL tool can really help with.
yep. seems it might be possible to just compare the shared_buffer setting
with the kernel parameters before making the change though... not sure in
which way you would slant the output though.
--
Robert Treat
Build A Brighter LAM
in the
website (rahter than anchoring on parameter family). It might be enough to
just populate the search bot with every guc anchored to family though...
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
--
Sent via pgsql-hackers mailing list (p
a perl script to poll pgsql_tmp and
print out anytime something showed up... you could probably find that in the
archives if you look around.
of course to me this sounds like an excellent idea for a dtrace probe ;-)
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreS
d way wont work (ie. your shared buffer
restart scenario). I think most of the user base would like to approach
administration from that point-of-view, and as of yet I haven't seen a
technical reason why that world view is wrong, only philosphical ones.
--
Robert Treat
Build A Brighter LA
the
current pg_settings, all the normal sql tools can still help... ie.
pg_dump -t if you want to check something into svn.
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
--
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 04 June 2008 15:48:47 Andrew Dunstan wrote:
> simply remove all the comment lines from your
> config file.
+1. That would clear up a lot of confusion on it's own.
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
--
Sent via pgsql-hack
having a set of these available is a large boon for dtrace users, but do you
see that as something that needs to be distriubuted with the core? I'd lean
towards reviving the dtrace project on pgfoundry, but it might be worth
expanding the dynamic tracing chapter to include more examples and
On Tuesday 03 June 2008 01:17:43 Tom Lane wrote:
> Robert Treat <[EMAIL PROTECTED]> writes:
> > Anyone see any issues with this?
> I'm a bit worried about breaking diff-equality of matching dumps,
If you are calling pg_dump with different flags, it seems likely your
?
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
need a serious re-write due to new needs from the hot standby feature. I
think going either way carries some risk.
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ddresses failover needs, where as read-only slaves
address both failover and scaling issues. (Note I say address, not solve).
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
of the arguments for
including windows support in a single release because we already had a work
port/patch set to go from.
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ld also be easier to implement on some level; we have already solved the
asynchronus wal shipping problem, so we would just need to solve the
read-only bits. For synchronus hot standby, you have to solve both the
synchronus shipping and the read-only bits. Seems like more work with less
upside that
to submit the patch set for 8.4,
just hadn't gotten around to it. As we've started to see some 3rd party
uptake of the set, it might be better to get something in sooner rather than
later, so yes, we'd be happy to see the patch set adopted upstream.
--
Robert Treat
Database Archi
s. But I like idea, so you can set dynamically SQLSTATE and other
> params - because you can write own wrapper for RAISE statement. It's
> can be usable for centralized exception management. I can do it in C,
> but there are lot of users, that could use only plpgsql.
>
I think no
e latest restart point? Just because a WAL
file has been processed doesn't mean it can be deleted.
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
I'm
> really not happy with the idea of magic preprocessing.
>
> I guess this is commonly used with timestamp fields so why not
> include a receipe to the docs under examples for timestamp which
> shows how to create and use a trigger?
>
I have a generic version of this
tem, and
then have that be blindly overridden by any random pg_dump user seems a bit
unfair. pg_dump is not only used as a backup tool, it is also used as a
general user tool (for example, pgadmin calls pg_dump if you want to see a
tables schema). imho pg_dump should not set it by default,
run your query, and then issue another set to
put those weightings back to the defaults, which seems like an excessive
amount of overhead. As much as people like to turn their nose to in-line
query hints, the manifestation of deficiencies in the planner always
manifiest themselves at the quer
On Thursday 24 April 2008 23:40, Tom Lane wrote:
> Robert Treat <[EMAIL PROTECTED]> writes:
> > Perhaps a better option would be to implement Merge per spec, and then
> > implement a "replace into" command for the oltp scenario. This way you
> > keep the s
a better option would be to implement Merge per spec, and then
implement a "replace into" command for the oltp scenario. This way you keep
the spec behavior for the spec syntax, and have a clearly non-spec command
for non-spec behavior.
--
Robert Treat
Build A Brighter LAMP :: Linu
on".
This would provide even more help for newbies, and encourage people to learn
about the .psqlrc file. :-)
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Friday 18 April 2008 00:24, Joshua D. Drake wrote:
> On Fri, 18 Apr 2008 00:21:58 -0400
>
> Robert Treat <[EMAIL PROTECTED]> wrote:
> > > We could just do:
> > >
> > > psql 8.1.10 - postgresql server version 8.1.10
> > >
> &
for psql help, \q to quit
>
> postgres=#
I think it's getting overlooked because most people don't deal with it, but I
really think we need to keep the SSL info as is. Actually I think we ought
to keep the whole thing and just add the no-splash option for advanced users,
but b
ed, so I propose that we
> return a NOTICE statement with this information.
>
How do you handle deletes? IE. If I merge two tables and I end up with no
updates or inserts but 100 deletes, is the number of affected rows 0 ?
> * The way MERGE is specified, the internals design seems to fal
> will lag.
>
> I have seen it twice today. That is not a good sign.
>
I agree, let's just bite the bullet and rename it to Postgres.
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} Postgre
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Thursday 27 March 2008 17:11, Tom Lane wrote:
> Robert Treat <[EMAIL PROTECTED]> writes:
> > On Sunday 16 March 2008 22:18, Tom Lane wrote:
> >> Fix TransactionIdIsCurrentTransactionId() to use binary search instead
> >> of linear search when checking child-tr
really have an issue with the naming
system, theres no reason they can't rename the binaries themselves to match
thier own naming standards since they control their own packages. I use
Solaris and this wouldn't bother me at all.
--
Robert Treat
Build A Brighter LAMP ::
f
needed (lmk what your looking for) but it certainly looks like the issue
discussed here:
http://archives.postgresql.org/pgsql-performance/2008-03/msg00191.php
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
--
Sent via pgsql-hackers mailing list (pgsql-hackers
On Tuesday 26 February 2008 12:20, Andrew Dunstan wrote:
> Robert Treat wrote:
> > There are a lot of people who have a database provider of some sort who
> > creates a database for them, giving them ownership of that specific
> > database, with pg_hba.conf specifying conne
of these
arrangements preclude (for valid reasons or not) the installation of any
contrib modules or installation of any procedural languages. It is these
users that 3rd party application developers (ie. mediawiki types) are trying
to accommodate. They would like to be able to take advantage of plpgsq
Hmm I don't think I've ever seen one like this, but thinking about it I
suppose I could see the argument and way to do it... but yes, I think you'd
get an error that the file was read-only, so the behavior would be similar to
trying to edit it on the box as postgres user.
--
er possible objection is that it would allow any superuser to
> set things that currently require direct access to the config files, so
> that would be a major change in security arrangements.
>
If you are superuser, you can write a C function (or just install adminpacks
functions) and
e interested to see what Mark Miekle says after looking at all the
> systems.
>
Switching from CVS to SVN is like switching from myisam to innodb; yeah, it's
an improvement, but you're still working with something fundementally broken.
Oooh...burnhiss :-P
--
Robert Treat
t;
Would a pre-requisite for any new SCM to be anointed as *the* new SCM that the
buildfarm can be reconfigured to run with it? Unless there is an SCM2CVS
option available I suppose... how many SCM's support such a thing?
--
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 Wednesday 06 February 2008 13:56, Alvaro Herrera wrote:
> Robert Treat wrote:
> > it looks as if the indexes on pg_class have become corrupt. (ie. reindex
> > claimes duplicate rows, which do not show up when doing count()
> > manipulations on the data). As it turns ou
ntially letting pg_resetxlog do a lookup)...
thoughts?
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 6: explain analyze is your friend
101 - 200 of 848 matches
Mail list logo
