ld be shared with
others through that mechanism.
And any tests which prove to be particularly useful could make their
way into the PG distribution if people here wish.
Of course, like anything else this could be a bad (or perhaps redundant)
idea. :-)
--
Kevin Brown
included in the suite without worrying about the impact it
would have on people running the tests.
--
Kevin Brown [EMAIL PROTECTED]
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
s to use it for our own marketing
purposes! Have it cite, for each test, which part of the SQL spec it's
testing and what the result should be.
--
Kevin Brown [EMAIL PROTECTED]
---(end of broadcast)---
ng for a completely new
platform. That's much different than doing another release for the same
platform set.
The testing that needs to be done for the Win32 release has to be done
separately *anyway*, so there's nothing lost by releasing the Win32 port
separately.
--
Kevin Brown
Tom Lane wrote:
> Kevin Brown <[EMAIL PROTECTED]> writes:
> > But if both of these paragraphs are simultaneously true, then why put
> > *anything* in contrib?
>
> Don't say that too loudly, or Marc may take it upon himself to make it
> happen ;-).
Well, I hope
ing lucid and upfront about everything
than hiding things just because they might be dangerous.
That said, all sorts of warnings and such should be in that bit of
documentation in postgresql.conf.sample, so that it's made abundantly
clear that this particular option is not one to be messing with
Tom Lane wrote:
> Kevin Brown <[EMAIL PROTECTED]> writes:
> > When a heavy INSERT or UPDATE load on a table is occurring (lots of
> > quick INSERTs or UPDATEs within a single transaction), a VACUUM
> > ANALYZE (or just straight VACUUM) has a really good chance (10% or so
retty much a universal thing that has been around a long time
while this option hasn't. Cluelessness about the use of a rather
esoteric option doesn't necessarily imply total cluelessness. :-)
--
Kevin Brown [EMAIL PROTECTED]
---
Tom Lane wrote:
> Kevin Brown <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> Basically, one should only turn this variable on after giving up on the
> >> possibility of getting any data out of the broken page itself. It would
> >> be folly to
with foreign keys?
I don't suppose a VACUUM is happening at the same time? I've found
that 7.2.4 likes to give deadlocks during inserts into a table when
it's being VACUUMed (haven't tried it on 7.3.2 yet).
--
Kevin Brown [EMAI
o queries through
the parser. But the upside is that you take that hit only if you need
the information. And if you plan to issue a particular query a lot,
you can issue the above command once and you're done.
I have no idea how hard this would be to im
IMHO, but that implies that perhaps a
paragraph that talks about dealing with damaged pages (and which
references this option) should be placed into the administrator's
guide.
--
Kevin Brown [EMAIL PROTECTED]
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
quot;score" of
the entry, but the maximum number of such bindings can never outweigh
an additional binary coercible argument. That relative weighting may
be too extreme, but would definitely serve to handle the example
problem you provided.
--
Kevin Brown
rned on as a normal setting.
This statement should *definitely* go into the documentation for the
option, then...
--
Kevin Brown [EMAIL PROTECTED]
---(end of broadcast)---
TIP 2: you can get off
Tom Lane wrote:
> Kevin Brown <[EMAIL PROTECTED]> writes:
> > When a heavy INSERT or UPDATE load on a table is occurring (lots of
> > quick INSERTs or UPDATEs within a single transaction), a VACUUM
> > ANALYZE (or just straight VACUUM) has a really good chance (10% or so
s, at least on 7.2.x. :-(
I'll be happy to supply the Perl script I'm using to do the inserts,
if that'll help people track this down...
--
Kevin Brown [EMAIL PROTECTED]
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
ackend sends status message showing DateStyle = bar
> SELECT ...
> -- reported dates will use DateStyle bar
> ROLLBACK;
> -- backend sends status message showing DateStyle = foo
Yes...whenever the watched variable changes from the perspective of
the c
owledgeable administrator (one of my pet
peeves is software that doesn't tell you why something failed, only
that it did).
--
Kevin Brown [EMAIL PROTECTED]
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
ch.
>
My 2 cents:
Use "split" and "merge". Avoids the "join" issue and avoids the
"implode/explode" issue too. :-)
--
Kevin Brown [EMAIL PROTECTED]
---(end of broadcast)--
less what other database vendors have done in response
to these underspecified issues is probably a sensible course of action
when there's no other obviously better answer.
--
Kevin Brown [EMAIL PROTECTED]
---(end of broadcas
Bruce Momjian wrote:
> Kevin Brown wrote:
> > Bruce Momjian wrote:
> > > The idea of using this on Unix is tempting, but Tatsuo is using a
> > > threaded backend, so it is a little easier to do. However, it would
> > > probably be pretty easy to write a
s true, and is something I hadn't actually thought of. So it
sounds like some testing would be in order.
Unfortunately I know of no system call which will take an array of
file descriptors (or file names! May as well go for the gold when
wishing for something :-) and sync them all to disk in the
ial search and replace. :-)
--
Kevin Brown [EMAIL PROTECTED]
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Tom Lane wrote:
> Kevin Brown <[EMAIL PROTECTED]> writes:
> >>> It would also be handy if users could see their own queries while the
> >>> rest remain blank.
> >>
> >> Seems reasonable offhand ...
>
> > Here's the patch to make th
Tom Lane wrote:
> Kevin Brown <[EMAIL PROTECTED]> writes:
[...]
> > It would also be handy if users could see their own queries while the
> > rest remain blank. That would require changing
> > pg_stat_get_backend_activity() so that it returns a value if the user
>
se me in the
least if the compiled definition is stored in a table already and
thus can be rolled back).
- Alternatively, recompilation could be made a manual thing,
e.g. ALTER FUNCTION blah RECOMPILE. It would still be a win for
this to be transaction-capable.
--
Kevin Brown
powerfail testing on various Unix platforms then it's reasonably
likely that the problem you're experiencing on the Windows side is
with the underlying Windows platform and not with your code.
--
Kevin Brown [EMAIL PROTECTED]
be pretty much anything).
The program will stop on the statement immediately following the one
that scribbled on the area you're watching when the condition you
specify is met. Note, though, that the condition is tested *after*
the modification happens.
--
Kevin Brown
f accomplishing what either syntax does. Is there
anything in the current draft that addresses this?
--
Kevin Brown [EMAIL PROTECTED]
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
-specific configuration
information.
I'm not sure that's quite what you had in mind, though. :-)
--
Kevin Brown [EMAIL PROTECTED]
---(end of broadcast)---
TIP 3: if posting/reading through U
power interruptions?
--
Kevin Brown [EMAIL PROTECTED]
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
t's true, but even if he has 4 billion rows it drops the
probability of a duplicate down to something like one in 4 billion, so
it's probably a safe enough bet. His application doesn't require
absolute uniqueness, fortunately, so md5 works well enough in this
cas
;$@"
Then just look for /tmp/ipcrm.out.* files and examine their contents.
(I think I got the arguments to ps right. It's been so long since
I've had to mess with a SysVr4 style system that I'm not sure
anymore. If it's a BSD-style ps then the arguments should be -auxww
mlw wrote:
> symlinks suck. Sorry Tom, but they are *BAD* in a production
> server.
Well, at least they're better than hard links. ;-)
--
Kevin Brown [EMAIL PROTECTED]
---(end of broadcast)--
Tom Lane wrote:
> Kevin Brown <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> Kevin Brown <[EMAIL PROTECTED]> writes:
> >>> Would it make more sense to enable stats_command_string by default?
> >>
> >> I'd vote against it.
ator would want to
retain. Which suggests that we should consider writing to a file
using a slightly different name (e.g., postgresql.conf.initdb), at
least in the event that a config file already exists in the target
directory.
Not sure what the overall right thing t
Tom Lane wrote:
> Kevin Brown <[EMAIL PROTECTED]> writes:
> > Would it make more sense to enable stats_command_string by default?
>
> I'd vote against it. If we turn it on by default, people are paying
> for a feature they may not even know exists. Once they find o
really good reason that
most DBAs would want it disabled? My sense is that there isn't, but I
don't know, which is why I'm asking.
--
Kevin Brown [EMAIL PROTECTED]
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
le for your purposes, but
having it do so automatically seems to violate the principle of least
surprise.
--
Kevin Brown [EMAIL PROTECTED]
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
t that, but yeah it's
probably simpler to rollback the whole database.
It would still be a useful feature, but I don't know that it's worth
the upfront performance cost of having to save off rollback segments.
If you did have such a feature you'd want to be able to control
whe
ng looked up. Are there any
pitfalls to implementing that?
--
Kevin Brown [EMAIL PROTECTED]
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
ing to keep
the ps output clean, but it's not clear to me that it should
necessarily apply to pg_ctl.
But you guys might have a different perspective on that. :-)
--
Kevin Brown [EMAIL PROTECTED]
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
h the
appropriate error message). But it doesn't sound like that's what
we're talking about when we talk about PITR...
I wouldn't expect the O* docs to be particularly revealing about
how the database manages PITR at the file level, but if it does, would
you happen to know whe
y fixing pg_ctl to use explicit command line directives when
invoking postmaster -- no changes to postmaster needed. PGCONFIG
would be no different in that regard.
Sorry if I seem a big gung-ho on the administrator point of view, but
as a system administrator myself I understand and feel their pain.
are stored versus the main data store, effects on performance, etc.
Thanks, and sorry for the newbie question. :-(
--
Kevin Brown [EMAIL PROTECTED]
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
ong way towards
eliminating most of the situations I described.
A warning in the documentation about the consequences of using PGDATA
might not be a bad idea, either...
--
Kevin Brown [EMAIL PROTECTED]
---(end of broadcast)--
able for ps
to not show any arguments to postmaster in some circumstances (I have
no idea what those would be), but why in the world would you want that
to be the *default*? Why would we want the default behavior to make
things harder on administrators and not easier?
--
Kevin Brown
tmaster when
invoking it...
--
Kevin Brown [EMAIL PROTECTED]
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
e.
This way, people who start the database using the standard tools we
supply will know exactly what's going on when they get a "ps" listing.
--
Kevin Brown [EMAIL PROTECTED]
---(end of broadcast)-
anyway. Takes care of the majority of the "visibility"
problem and leaves PGDATA intact. Thoughts?
--
Kevin Brown [EMAIL PROTECTED]
---(end of broadcast)---
TIP 2: you can get off all lists
Bruce Momjian wrote:
> I just set PGDATA in my login and I don't have to deal with it
> again.
Hmm...you don't use pg_ctl to start/stop/whatever the database? You
invoke the postmaster directly (I can easily see that you would, just
asking if you do)?
ble. You'd want to make the error message
that's produced when no data directory is specified depend on the same
#ifdef variable, of course.
Then the group would get to fight it out over whether the configure
default should be "enable" or "disable". :-)
--
uot;PGDATA");" line from
postmaster.c.
--
Kevin Brown [EMAIL PROTECTED]
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Tom Lane wrote:
> Kevin Brown <[EMAIL PROTECTED]> writes:
> > I agree with your assessment for the most part, except for PGDATA.
> > There's no good reason I can think of for the postmaster to look at
> > it.
>
> The other side of that coin is, what'
le little 'pm.sh'
script that simply does a "postmaster -D $PGDATA", which will save
them typing even over just doing a "postmaster" from the command line.
--
Kevin Brown [EMAIL PROTECTED]
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
in the cases where people
don't have to touch the default config. :-)
--
Kevin Brown [EMAIL PROTECTED]
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
sh the WAL data to disk (for everyone).
What happens when the only transaction running emits more WAL log data
than wal_buffers can handle? A flush happens when the WAL buffers
fill up (that's what I'd expect)? Didn't find much in the
documentation about
or WAL,
> etc.
> Low-Impact server = current defaults, more or less.
Okay, but there should probably be one more, called "Benchmark". The
real problem is what values to use for it. :-)
--
Kevin Brown [EMAIL PROTECTED]
-
#x27;m certainly interested in hearing the reasoning behind them.
But from the point of view of maintaining a widely deployed package
like PostgreSQL, the conventions the distributions and sysadmins use
matter a great deal, whether or not you happen to agree with those
conventions.
--
Kevin Brown [EMAIL PROTECTED]
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
ile. Obviously files like PG_VERSION are associated with
the data and not with the config, so they get treated
appropriately.
The above addresses *everyone's* concerns that I've seen thus far, I
think. Thoughts?
--
Kevin Brown [EMAIL PR
o see a GUC variable added to the config file
that tells the postmaster where to look for the data, the above will
at least simplify the postmaster's code (since the logic for dealing
with $PGDATA can be eliminated) while eliminating some of the trouble
administrato
weren't even running a native version of
PostgreSQL, I think the results were surprisingly *good*.
But yes, we really do want to be the fastest. :-)
--
Kevin Brown [EMAIL PROTECTED]
---(end of broadcast)
a break towards existing standards, and there are good
reasons for doing it, benefits to be had by adhering to those
standards.
The way we currently handle configuration files is fine for research
and development use -- the environment from which PostgreSQL spran
ram to process the logs and put them into a PostgreSQL database,
you'd have problems with the transactions of the log processor landing
in the logs as well, at least if all transactions were logged. The
logging process would have to filter out its own transactions, which
might not be all tha
Tom Lane wrote:
> Kevin Brown <[EMAIL PROTECTED]> writes:
> > I assume $PGDATA was around long before GUC?
>
> Yes, it was. But I have not yet seen an argument here that justifies
> why $SOMECONFIGDIRECTORY/postgresql.conf is better than
> $PGDATA/postgresql.conf.
do so by using multiple config file directories. When
consistency is required, he can easily use symlinks to point to master
config files where appropriate.
I assume $PGDATA was around long before GUC?
--
Kevin Brown [EMAIL PROTECTED]
--
d objects) on many systems.
Perhaps that's what he meant?
--
Kevin Brown [EMAIL PROTECTED]
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
t would be useful to deny access to
certain system tables, like pg_user? Would doing so automatically
prevent any users who were under such restrictions from doing anything
useful? If such a thing is possible and potentially useful, then it's
another reason for the function
data via UDP
despite explicitly being told to mount via TCP, that's something else.
It might be useful to verify via netstat that an actual TCP connection
to the NFS server is being established and used.
Makes me wonder if this might be a problem at the NFS protocol
layer...
--
Kevin Bro
types that define a min() and max() but which *do not* define "<"
and ">"? I can't think of such types myself but can imagine that some
esoteric data types might qualify. For the purposes of optimizing the
common case, however, such esoteric types could easily be ign
Kurt Roeckx wrote:
> On Sat, Feb 01, 2003 at 08:15:17AM -0800, Kevin Brown wrote:
> > Kurt Roeckx wrote:
> > > [SIO] [Option Start] If _POSIX_SYNCHRONIZED_IO is defined, the
> > > fsync() function shall force all currently queued I/O operations
> >
Tom Lane wrote:
> Kevin Brown <[EMAIL PROTECTED]> writes:
> > So if we wanted to make use of mandatory locks, we'd have to refrain
> > from using flock().
>
> We have no need for mandatory locks; the advisory style will do fine.
> This is true because we have
if aggregate functions
aren't responsible for retrieving the values they're supposed to base
their computations on, or if it's not possible to get the system to
refrain from prefetching data for the aggregate function until the
function asks for it.
--
Kevin Brown
sing flock()
will *not* invoke the mandatory lock semantics even if on a file
marked for it, so I guess flock() isn't implemented on top of fcntl()
in Linux.
So if we wanted to make use of mandatory locks, we'd have to refrain
from using flock().
--
Kevin Brown
file, do an fsync(), and have the kernel actually
write all the buffers associated with that file to disk could be, I
think, a significant performance win compared with the "flush
everything known to the kernel" approach we take now, at least on
systems that do something
essions are dead wrong...
--
Kevin Brown [EMAIL PROTECTED]
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
t. Would
it be more useful in that case to return an error indication? Would
it be more useful to simply lock the entire file? If no underlying
file locking mechanism is available, it seems obvious to me that the
function would have to always return an er
Tom Lane wrote:
> Kevin Brown <[EMAIL PROTECTED]> writes:
> >> I think it's best to leave well enough alone. The tarball ships with
> >> working bison output files anyway, so all of this really only matters
> >> to people trying to build 7.2.* from a CVS
Kurt Roeckx wrote:
> On Thu, Jan 30, 2003 at 02:39:59PM -0800, Kevin Brown wrote:
> >
> > With this I agree, but before you start thinking that Windows is the
> > only OS that qualifies, consider this: I've run the "pull the plug"
> > test under early Lin
reputation in the *Unix*
community? The answer, I think, is no.
And that *is* relevant to us, because our concern is about the
reputation of PostgreSQL, and what will happen to it if we release a
native Windows port to the world.
Of course, you could argue that Oracle and IBM didn't
Tom Lane wrote:
> Kevin Brown <[EMAIL PROTECTED]> writes:
> > I'm attaching a patch for 7.2.4's parser/gram.y that fixes all of
> > bison 1.75's complaints.
>
> But parser/gram.y is not the only .y file in the distribution. To call
> ourselves
u pause about declaring
*Linux* an industrial-strength solution?
My point: if you're going to hold *one* OS to a given standard, you
should hold *all* of them to that same standard.
--
Kevin Brown [EMAIL PROTECTED]
---(end of broad
what'll probably be our last dot-release for 7.2
> is not the time to drop a new bison into its toolchain.
Ooops. Last patch wasn't done using CVS diff. This one is, in case
it matters...
--
Kevin Brown [EMAIL PROTECTED]
Index: gram.y
=
fix in the 7.2.4 release, as long as
we include a warning in the release notes that we haven't done any
real testing with a build against bison 1.75 (or later).
--
Kevin Brown [EMAIL PROTECTED]
--- gram.y.orig Wed Jan 29 22:39:31
line: put tons of disclaimers about the likely reliability of
the Windows port in the documentation if you'd like, but don't let
these concerns prevent any action with respect to doing a proper
Windows port.
--
Kevin Brown [EMAIL PROTECTED]
being that the transaction commands are issued in the dump, as
long as it's a behavior that can be turned off.
--
Kevin Brown [EMAIL PROTECTED]
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
Tom Lane wrote:
> Kevin Brown <[EMAIL PROTECTED]> writes:
> > One question I have is: in the event of a crash, why not simply replay
> > all the transactions found in the WAL? Is the startup time of the
> > database that badly affected if pg_control is ignored?
>
experience on both platforms. Since I don't have any real
experience doing development under Windows, I'm not one to really say.
But I thought you should at least know what you're up against.
I do agree that being able to build and debug PostgreSQL using
whichever tools are most
Kevin, a.k.a. "Mr. Obvious" :-)
--
Kevin Brown [EMAIL PROTECTED]
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
Tom Lane wrote:
> Kevin Brown <[EMAIL PROTECTED]> writes:
> > So the backends have to keep a common list of all the files they
> > touch. Admittedly, that could be a problem if it means using a bunch
> > of shared memory, and it may have additional performance implic
ing process until I simply got
fed up, hit the "stop" button, and told my browser to ignore all
images from the server the ads were coming from.
I have no problem with ads being put there, but they should load at
least as fast as the rest of the site. They do so currently, but not
always,
, so it's probably a safe bet to fsync() any ancestor
directories that matter as well as the file even if the system is
running on top of a journalled filesystem. Since all the files in
question probably reside in the same set of directories, the directory
fsync()s can be deferred until the v
gt; Try the EXECUTE; if it fails, run the PREPARE and then rerun the
> EXECUTE.
Erm...won't the failed EXECUTE boot you out of the middle of a
transaction? The documentation doesn't make it clear what happens in
that case, and I don't have 7.3.x
one of this matters, of course, because the SQL spec calls for a
completely different behavior.
My question is: *why* does it call for such a completely different
behavior? Does anyone here have any insight into that?
--
Kevin Brown [EMAIL PROTECTED]
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
t, then does anyone here know why the spec
calls for something different?
--
Kevin Brown [EMAIL PROTECTED]
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
concerns are probably more justified if you're worried about
the change causing some little-used code to suddenly start seeing a
lot of usage...
--
Kevin Brown [EMAIL PROTECTED]
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
dot
would increase the load on Slashdot's MySQL server, thus making it
slower and illustrating the point that they should be using PostgreSQL
instead. [ ducks ]
:-)
--
Kevin Brown [EMAIL PROTECTED]
---(end of broadcast)--
[EMAIL PROTECTED] wrote:
> Kevin Brown wrote:
> > Simply saying "MySQL has better marketing" isn't enough. It's too
> > simple an answer and obscures some issues that should probably be
> > addressed.
>
> I think it /is/ a significant factor, the
er. Change the API and you have to do something to make
it clear that the API has changed. Same deal with a protocol.
I don't know if what I'm saying here makes much sense to you, but I
hope it helps...
--
Kevin Brown [EMAIL PROTECTED
of MySQL and PostgreSQL are the same, while the
prices of PostgreSQL and Oracle are vastly different.
That's not to say that going after the Oracle market shouldn't be done
(quite the opposite, provided it's done honestly), only that *not*
going after the MySQL market is folly.
--
Kevin Brown [EMAIL PROTECTED]
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
101 - 200 of 215 matches
Mail list logo
