of getting this information from the system? If
not, then I'd consider this proposed change important.
--
Kevin Brown [EMAIL PROTECTED]
---(end of broadcast)---
TIP 6: explain analyze is your friend
the maximum number of advisory locks a given backend can take at any
one time? Then it becomes the DBA's problem (and solution) if someone
manages to run the database out of shared memory through this
mechanism.
--
Kevin Brown [EMAIL PROTECTED
IBM has done here is very sensible, and is really what the other
Unixes should have done from the beginning: a library is just a
library, and what differs is how it's used.
--
Kevin Brown [EMAIL PROTECTED]
---(end of broadcast
that comes from evaluating
the constraints, not from reporting the errors afterwards.
--
Kevin Brown [EMAIL PROTECTED]
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
, but I'd have to examine the assembly to
know for sure). On the 1.5 GHz P4 system, each iteration takes 8.49
nanoseconds. And on the 2.8 GHz Xeon system, each iteration takes
5.01 nanoseconds.
That seems reasonably fast to me...
--
Kevin Brown [EMAIL
, a month (or however long you had in mind) for
this cycle. That way, the two major patches that are likely to be
dropped for this cycle stand a chance to make it into this release,
and you accomplish your goal of moving the dates a bit all at the same
time.
--
Kevin Brown
to the
influence of Pluto's gravitational field on your mood when you got out
of bed this morning.
I always wondered what affected his mood when he got out of bed this
morning. Now I know!
It's amazing the things you can learn by lurking here... :-)
--
Kevin Brown
, though, as well as how much of a performance impact the
measurements have on overall operation...
--
Kevin Brown [EMAIL PROTECTED]
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please
. The
kernel's page size is 4k, as is the default block size used by XFS.
Tracking this one down any further is going to be nigh unto
impossible, I think.
There have been a pile of fixes to XFS in 2.6.16, so I'll start using
that, at least...
Thanks for looking at this.
--
Kevin Brown
.
--
Kevin Brown [EMAIL PROTECTED]
---(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
/~kevin/postgresql
The files are bad-page-info.txt and bad-page.txt.
--
Kevin Brown [EMAIL PROTECTED]
---(end of broadcast)---
TIP 6: explain analyze is your friend
the output of pg_filedump, I'll be
happy to post it here (or email it separately). I hesitate to attach
it here because it's not clear the mailing list's spam filtering would
let it pass.
--
Kevin Brown [EMAIL PROTECTED
the issues you're concerned about?
If it's fast enough even on large tables, it would be a nice
alternative to REINDEX, I'd think.
--
Kevin Brown [EMAIL PROTECTED]
---(end of broadcast)---
TIP 3: Have you
is granted. A true deadlock won't happen
against common operations unless REINDEX promotes its lock again to
something stronger than ShareLock, and that's easy to avoid: just have
REINDEX promote directly from AccessShareLock to the strongest lock it
will ever need.
--
Kevin Brown
Tom Lane wrote:
Kevin Brown [EMAIL PROTECTED] writes:
Tom Lane wrote:
Even ignoring that, you *still* have a lock upgrade problem
in this sketch.
Hmm, well, I can see a deadlock potential for those operations that
have to acquire multiple locks simultaneously, and I suppose
Tom Lane wrote:
Kevin Brown [EMAIL PROTECTED] writes:
I guess the real question here is: is it possible to, in code,
guarantee the order of lock acquisition by any given transaction?
Yes, but not in our code :-(. This is largely determined by what the
application does.
Yeah, that's what
Tom Lane wrote:
Kevin Brown [EMAIL PROTECTED] writes:
- when requesting a type of lock, one must first acquire all lesser
lock types against the object in order of strength. Hence, one must
acquire AccessShareLock before acquiring AccessExclusiveLock.
This is exactly wrong
here shouldn't be a big deal.
--
Kevin Brown [EMAIL PROTECTED]
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
through.
--
Kevin Brown [EMAIL PROTECTED]
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
Tom Lane wrote:
Kevin Brown [EMAIL PROTECTED] writes:
In the above for large relations, the bulk of the REINDEX should
happen without any locks being held by the REINDEX operation.
As I just pointed out to Greg, the arm-waving notion that you can turn
off the FSM requires a great deal
Martijn van Oosterhout wrote:
None of this applies to PostgreSQL because we open the modules
directly, and don't rely on the linker loader.
Ah, right. I forgot the context was the server, not one of the
utilities...
Sorry for the waste of bandwidth...
--
Kevin Brown
by the
shared object. I don't know if that just causes the dynamic linker to
look for a file with the specified soname or if it will actually
examine the shared object under consideration to make sure it has the
DT_SONAME field in question, however.
--
Kevin Brown
) will just exit.
--
Kevin Brown [EMAIL PROTECTED]
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
[EMAIL PROTECTED] wrote:
On Thu, Oct 20, 2005 at 03:42:10PM -0700, Kevin Brown wrote:
Martijn van Oosterhout wrote:
You can't do a pclose in a signal handler, it's not one of the
reeentrant safe functions and could lead to deadlocks. The signal
manpage documents the ones you can use
Andrew - Supernews wrote:
On 2005-10-19, Kevin Brown [EMAIL PROTECTED] wrote:
Making assumptions about what the pager will do upon receipt of SIGINT
is folly as well.
Setting up SIGINT to be ignored may be the right answer (I don't
believe it is -- see below), but if so then it needs
signal handler (the one that gets
invoked when the pager is turned off) can be called from the cleanup
handler in order to maintain the proper semantics.
--
Kevin Brown [EMAIL PROTECTED]
---(end of broadcast
to
clean up the terminal manually than have an unusable core file.
--
Kevin Brown [EMAIL PROTECTED]
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
already exist (and if it already exists, then clearly the ACLs
should be storing the id of the role holding the grant, since the
audit structure will separately record the user/role issuing the
grant).
--
Kevin Brown [EMAIL PROTECTED
?
--
Kevin Brown [EMAIL PROTECTED]
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
write the page (you'll have to read it from the page prior to
incrementing it, of course).
Other than that, torn page detection is really just a special case of
page corruption detection.
--
Kevin Brown [EMAIL PROTECTED]
---(end
Greg Stark wrote:
Kevin Brown [EMAIL PROTECTED] writes:
Hence, it makes sense to go ahead and run the query, but issue a
warning at the very beginning, e.g. WARNING: query JOINs tables list
of tables without otherwise referencing or making use of those
tables. This may cause
.
That said, the real question is whether or not it's worth putting in
the effort to detect this condition and issue the warning. I'd say
probably not, but if this is a big enough itch for someone then why
should we discourage them from coding up a fix?
--
Kevin Brown
such references either, yielding
columnname is invalid in the HAVING clause because it is not
contained in either an aggregate function or the GROUP BY clause..
Can't comment about DB2.
--
Kevin Brown [EMAIL PROTECTED]
---(end
look for transaction
wraparound, or to automatically vacuum every N number of transactions
(e.g., 500 million)?
--
Kevin Brown [EMAIL PROTECTED]
---(end of broadcast)---
TIP 3: if posting/reading through
other
approach is probably warranted.
--
Kevin Brown [EMAIL PROTECTED]
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL
table_schema IN ('public', 'postgres'))
TO (SELECT usename from PG_USER WHERE usecatupd = true);
Actually, it would be very nice if all DDL statements could work that
way.
--
Kevin Brown [EMAIL PROTECTED]
---(end
and cynical, well, there's lots of good reason for
it. You need only look around, at least if you're in the U.S.
--
Kevin Brown [EMAIL PROTECTED]
---(end of broadcast)---
TIP 2: you can get off all lists at once
on
Windows platforms generally used the '.ini' extension. I believe on
most Windows systems that extension is by default associated with
Notepad.
--
Kevin Brown [EMAIL PROTECTED]
---(end of broadcast
that being able to properly specify the path of the
program to use with a minimum of fuss (hence no strange quoting
conventions) takes precedence.
--
Kevin Brown [EMAIL PROTECTED]
---(end of broadcast
,
and preferably with a relevant GUC for each operation.
Since WAL archiving requires that the operations in question be WAL
logged, the GUCs that control WAL logging of those statements would
clearly be ineffective if WAL archiving is turned on.
--
Kevin Brown
, and actually be interrupted the
second time.
So if Unixware doesn't have sigaction() or it's not being picked up by
autoconf then yeah, he'll have big problems...
--
Kevin Brown [EMAIL PROTECTED]
#include signal.h
#include stdio.h
#include unistd.h
want fine-grained
control of this process, you could stick a boolean column in the table
to indicate whether or not to load the value from the table at startup
time).
--
Kevin Brown [EMAIL PROTECTED]
---(end of broadcast
authors who would care about this one way or another
probably won't be expecting this behavior, it should also be
documented reasonably well -- something which I'm rather sure you were
going to do anyway.
--
Kevin Brown [EMAIL PROTECTED
)::varchar(4) after
the ALTER TABLE in the example.
FWIW...
--
Kevin Brown [EMAIL PROTECTED]
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
joining
be a bit unfortunate to introduce inconsistencies
where they're not needed, wouldn't you say?
--
Kevin Brown [EMAIL PROTECTED]
---(end of broadcast)---
TIP 2: you can get off all lists at once
Tom Lane wrote:
Kevin Brown [EMAIL PROTECTED] writes:
... But what we're talking about
here is brand new functionality for which the language hasn't been
defined yet.
You're missing the point, which is that there *is* a precedent of long
standing. ALTER TABLE has worked on indexes
a decent amount of PG
experience.
--
Kevin Brown [EMAIL PROTECTED]
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
that actually
modifies an index instead of the table itself, should there be an ALTER
INDEX? It would be cleaner and more consistent, IMO...
--
Kevin Brown [EMAIL PROTECTED]
---(end of broadcast)---
TIP 9
and DROP INDEX to drop one -- we
don't use ALTER TABLE subcommands to create or drop indexes. Why, then,
should modification of an index's properties be treated any differently
than the rest of the index manipulation commands?
I just happen to like consistency. :-)
--
Kevin Brown
filesystem-level restore of the
database as it was prior to the events in the first event log being
replayed has been done? In that event, wouldn't the PITR process Just
Work?
--
Kevin Brown [EMAIL PROTECTED]
---(end of broadcast
on files within the tablespace, but
that feels pretty uncomfortable to me --- it amounts to deliberately
discarding data ...
Any thoughts?
How is a dropped table handled by the recovery code? Doesn't it present
the same sort of issues (though on a smaller scale)?
--
Kevin Brown
Larry Rosenman wrote:
I had to hack on the code some more for FreeBSD:
(the realloc call needed the multiplication). I ran this same code
on UnixWare.
I feel like a moron, having missed that. Probably explains the bad
file number error I was getting on AIX, too...
--
Kevin Brown
from its effect on how
many normal files we can open.
I imagine this could easily be tested. I rather doubt that the
performance hit would be terribly large, but we certainly shouldn't rule
it out without testing it first.
--
Kevin Brown [EMAIL
Tom Lane wrote:
Kevin Brown [EMAIL PROTECTED] writes:
The goal here is simply to make it obvious to a system administrator where
the PG data directory that a given postmaster is using resides.
Why would it not be sufficient to add a read-only GUC variable that
tells that? Connect
line. That seems
easy enough to do: #ifdef is your friend.
--
Kevin Brown [EMAIL PROTECTED]
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
joining
option, the postmaster will refuse to run.
--
Kevin Brown [EMAIL PROTECTED]
---(end of broadcast)---
TIP 8: explain analyze is your friend
if this would break
anything, though.
--
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
kick in automatically, no?
Thoughts? Am I completely off my rocker here? :-)
--
Kevin Brown [EMAIL PROTECTED]
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
my results with it as well, so
we'll be able to see if there's any consistency between it and the live
database.
--
Kevin Brown [EMAIL PROTECTED]
---(end of broadcast)---
TIP 2: you can get off all lists
going to the effort when it may or may not
gain you a whole lot. Answering that is going to require some
experimentation with such an automatic configuration system.
--
Kevin Brown [EMAIL PROTECTED]
---(end of broadcast
opening 2 shared libs
[EMAIL PROTECTED]:~$ uname -a
AIX m048 1 5 0001063A4C00
--
Kevin Brown [EMAIL PROTECTED]
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http
Tom Lane wrote:
Kevin Brown [EMAIL PROTECTED] writes:
I originally thought that each shared library that was loaded would eat
a file descriptor (since I thought it would be implemented via mmap())
but that doesn't seem to be the case, at least under Linux
Hmm. This may be OS-specific
requires it somehow.
--
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:
Well, running out of space in the list isn't that much of a problem. If
the backends run out of list space (and the max size of the list could
be a configurable thing, either as a percentage of shared memory or as
an absolute size
Tom Lane wrote:
Kevin Brown [EMAIL PROTECTED] writes:
Instead, have each backend maintain its own separate list in shared
memory. The only readers of a given list would be the backend it belongs
to and the bgwriter, and the only time bgwriter attempts to read the
list is at checkpoint
be any dirty blocks in those files). I suppose it's possible that
on some OSes fsync()s could interfere with a running sync(), but for
those OSes we can just drop back do doing only fsync()s.
As usual, I could be completely full of it. Take this for what it's
worth. :-)
--
Kevin Brown
' in the database).
I'll be happy to share my code with anyone who's interested.
--
Kevin Brown [EMAIL PROTECTED]
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
in MySQL return. That said,
the inclusion of information_schema is a very recent development on the
PostgreSQL side of things, and doesn't even exist on some other major
databases such as MSSQL.
Of course, a PG equivalent to MySQL's show would be an even more
recent development... :-)
--
Kevin
cannot also be created on a per-database
basis.
I'm sure, of course, that doing so would bring with it a new set of
problems and tradeoffs, so it might not be worth it...
--
Kevin Brown [EMAIL PROTECTED]
---(end of broadcast
Tom Lane wrote:
Kevin Brown [EMAIL PROTECTED] writes:
Tom Lane wrote:
You don't. As I said, any physical backup is going to be
all-or-nothing. These techniques are not a replacement for pg_dump.
But this is just an artifact of the fact that the WAL is a single
instance-wide entity
the same as it is for PostgreSQL. The
difference is that the *only* releases PostgreSQL makes are stable
releases (or release candidates, when a stable release is close).
That's something we might want to re-think.
--
Kevin Brown [EMAIL PROTECTED
within a given block of time, on
average, because a lot more people pick up the releases than the CVS
snapshots or even release candidates..
--
Kevin Brown [EMAIL PROTECTED]
---(end of broadcast)---
TIP 3
should be for each
option. Clearly for non-gcc compilers, the default should be -O only
since they probably can't simultaneously handle -g. But gcc builds are
an exception, one which I think is worth considering. Hence my opinion
that for gcc builds, the default should be -g and -O.
--
Kevin
if it were, a database tends to be so critical to so many
things that you probably want to know why and how it crashes more than
you would most other things. So even if you might be inclined to strip
most of your binaries, you might think twice about doing the same for
the PG binaries.
--
Kevin Brown
. The -g option makes that possible for optimized
code when compiling with gcc.
Is there any way we can have configure put -g in when it detects gcc?
--
Kevin Brown [EMAIL PROTECTED]
---(end of broadcast
directed language?
Say what you want about SQL, but at least it was designed with querying
table-based data in mind and is at least somewhat good at its job.
--
Kevin Brown [EMAIL PROTECTED]
---(end of broadcast
Bruce Momjian wrote:
Kevin Brown wrote:
Actually, all that's really necessary is the ability to call a stored
procedure when some event occurs. The stored procedure can take it from
there, and since it can be written in C it can do anything the postgres
user can do (for good or for ill
changes. This fix won't work,
of course, if the serialization code is so broken that it doesn't work
properly even in the face of updates (something I'd find hard to believe).
--
Kevin Brown [EMAIL PROTECTED]
---(end of broadcast
as well as in shared memory, so that the commit
ID can be quickly looked up from the transaction ID.
Maybe there's a better way around all this, but I certainly can't think
of one at the moment. :-(
--
Kevin Brown [EMAIL PROTECTED
procedure when some event occurs. The stored procedure can take it from
there, and since it can be written in C it can do anything the postgres
user can do (for good or for ill, of course).
--
Kevin Brown [EMAIL PROTECTED]
---(end
this thread refers to regardless
of whether a row is examined/modified via directly issued SQL or via
the RI mechanism then the problem lies not within the RI code at all,
but within the serialization code.
I just hope I'm not merely stating the obvious here...
--
Kevin Brown
it possible for users to kill their own runaway queries
without having to run as whatever user PG is running as.
--
Kevin Brown [EMAIL PROTECTED]
---(end of broadcast)---
TIP 8: explain analyze is your
(no
matches).
Of course, I could always be off my rocker here. :-)
--
Kevin Brown [EMAIL PROTECTED]
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
that are relevant. Does this test represent a significant
performance hit?
--
Kevin Brown [EMAIL PROTECTED]
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http
unique
within a schema?
--
Kevin Brown [EMAIL PROTECTED]
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
-defined order). In my case I can
probably code around it but it does require some extra effort. But I
can easily imagine situations in which that wouldn't be an option.
Whatever happened to be liberal in what you accept and conservative in
what you send? :-)
--
Kevin Brown
Bruce Momjian wrote:
Kevin Brown wrote:
The two approaches aren't necessarily mutually exclusive (though SQL99
compliance on constraint names would obviously make it unnecessary to
specify a tablename along with a constraint name), so I see little
problem here. But the current
) that you can't reasonably extricate yourself from.
--
Kevin Brown [EMAIL PROTECTED]
---(end of broadcast)---
TIP 8: explain analyze is your friend
basic reason: not all compilers support the -o
option.
...jaw drops to ground...
I'm astounded. There are such compilers still in use?? Which ones?
--
Kevin Brown [EMAIL PROTECTED]
---(end of broadcast
really necessary today because of the huge amount of
memory that you can put into a system for cheap (HP servers excluded,
they want some serious cash for memory).
--
Kevin Brown [EMAIL PROTECTED]
---(end of broadcast
The Hermit Hacker wrote:
On Wed, 25 Jun 2003, Kevin Brown wrote:
So...would it make sense to create a gborg project to which people who
have written their own test suites can contribute whatever code and data
they feel comfortable releasing? As a gborg project, it would be
separate
into the PG distribution if people here wish.
Of course, like anything else this could be a bad (or perhaps redundant)
idea. :-)
--
Kevin Brown [EMAIL PROTECTED]
---(end of broadcast)---
TIP 6: Have you
(and, obviously,
only when verbosity is maximized), too, but that may be too much to
ask for. :-)
--
Kevin Brown [EMAIL PROTECTED]
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose
for whatever reason.
--
Kevin Brown [EMAIL PROTECTED]
---(end of broadcast)---
TIP 8: explain analyze is your friend
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)---
TIP 6: Have you searched
the tests.
--
Kevin Brown [EMAIL PROTECTED]
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
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 [EMAIL PROTECTED]
---(end of broadcast)---
TIP 1
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 he's not so eager to do so that he does
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)
of causing either the INSERT
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 except
when you know exactly what you're doing...
--
Kevin Brown
1 - 100 of 202 matches
Mail list logo
