I think it is time to start giving people official responsibility for
certain areas of the code.
In the old says, we didn't have many _exports_, and people submitting
patches often knew more than we did because they had spent time studying
the code.
Now, we have much more expertise, to the
When you mmap, you don't use write() ! mlock actualy locks page in
memory and as long as the page is locked the OS doesn't attempt to
store the dirty page. It is intended also for security app to
ensure that sensitive data are not written to unsecure storage
(hdd). It is definition of
Hi,
after long time I see the /contrib tree and I have I small notes.
- (IMHO) is good evidently that all executable programs stored here use
prefix 'pg_', but with the exception:
vacuumlo
pgbench (instead pg_bench)
oid2name
ipc_check
fti[.pl]
findoidjoins
It's great as long as you never block, but it sucks for making things
wait, because the wait interval will be some multiple of 10 msec rather
than just the time till the lock comes free.
On the AIX platform usleep (3) is able to really sleep microseconds without
busying the cpu when
For those interested in the topic, this is something that went through
the Vorbis-dev mailing list not that long ago which implements the
above topic into the vorbis decoder. Might be useful to see what
systems it works on, and where it breaks as well as a reference
implementation. (patch
WOOT WOOT! DANGER WILL ROBINSON!
- Original Message -
From: "Christian Weisgerber" [EMAIL PROTECTED]
Newsgroups: list.vorbis.dev
To: [EMAIL PROTECTED]
Sent: Saturday, March 17, 2001 12:01 PM
Subject: [vorbis-dev] ogg123: shared memory by mmap()
The patch below adds:
-
Whatever you guys decide is fine with me.
Thomas Lockhart [EMAIL PROTECTED] writes:
If it doesn't work, and will not be made to work, then let's remove it
from the tree.
I tend to agree with Peter's slightly less drastic proposal: remove it
from the installed fileset and disable its man
* William K. Volkman [EMAIL PROTECTED] [010318 11:56] wrote:
The Hermit Hacker wrote:
But, with shared libraries, are you really pulling in a "whole
thread-support library"? My understanding of shared libraries (altho it
may be totally off) was that instead of pulling in a whole
Hi,
New version of contrib-intarray is available from
http://www.sai.msu.su/~megera/postgres/gist/code/7.1/contrib-intarray.tar.gz
From README.intarray:
March 19, 2001
1. Added support for toastable keys
2. Improved split algorithm for intbig (selection speedup is about 30%)
This does make me wonder (again) about some kind of pg_dump regression
test. ISTM that a test should be doable by building a DB from data files,
dumping it, restoring it, then using COPY to extract the data back to files
(and probably doing a sort on the output). We could also store a BLOB or
Bruce Momjian writes:
Seems I am no longer capable of understanding the affects of such
changes as this:
! override CPPFLAGS := -I$(srcdir) $(CPPFLAGS) -DPGSQL71
! override CPPFLAGS += -I$(srcdir) -DPGSQL71
Having $(srcdir) before $(CPPFLAGS) must be significant.
The CVS log
Bruce Momjian [EMAIL PROTECTED] writes:
Only shared memory gives us near-zero cost for write/read. 99% of
backends will not be using stats, so it has to be cheap.
Not with a circular buffer it's not cheap, because you need interlocking
on writes. Your claim that you can get away without that
Sorry, I have again messed up this Makefile, and I am glad Tom has put
things back.
Seems I am no longer capable of understanding the affects of such
changes as this:
! override CPPFLAGS := -I$(srcdir) $(CPPFLAGS) -DPGSQL71
! override CPPFLAGS += -I$(srcdir)
Bruce Momjian [EMAIL PROTECTED] writes:
Only shared memory gives us near-zero cost for write/read. 99% of
backends will not be using stats, so it has to be cheap.
Not with a circular buffer it's not cheap, because you need interlocking
on writes. Your claim that you can get away
I have a new statistics collection proposal.
I suggest three shared memory areas:
One per backend to hold the query string and other per-backend stats
One global area to hold accumulated stats for all backends
One global circular buffer to hold per-table/object stats
Bruce Momjian writes:
Seems I am no longer capable of understanding the affects of such
changes as this:
! override CPPFLAGS := -I$(srcdir) $(CPPFLAGS) -DPGSQL71
! override CPPFLAGS += -I$(srcdir) -DPGSQL71
Having $(srcdir) before $(CPPFLAGS) must be significant.
The
Hello all,
Just to ask you if someone is planning to release beta 6 RPMs.
I am running Redhat 7.0 test servers and the compiler is broken.
Regards from Jean-Michel POURE, Paris
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go
Bruce Momjian wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Only shared memory gives us near-zero cost for write/read. 99% of
backends will not be using stats, so it has to be cheap.
Not with a circular buffer it's not cheap, because you need interlocking
on writes. Your claim
I figured it could just wake up every few seconds and check. It will
remember the loop counter and current pointer, and read any new
information. I was thinking of a 20k buffer, which could cover about 4k
events.
Here I wonder what your EVENT is. With an Oid as identifier
Jean-Michel POURE writes:
Just to ask you if someone is planning to release beta 6 RPMs.
I am running Redhat 7.0 test servers and the compiler is broken.
The "gcc 2.96" compiler on Red Hat 7.0 works for PostgreSQL. (And surely
an RPM would have to be compiled by the same compiler.) Later
Is there any way to get just the ODBC RPM to install with OUT
installing the whole DB?
I have a strange situation:
StarOffice 5.2 (Linux) Running under FreeBSD Linux Emulation
PG running NATIVE.
I want the two to talk, using ODBC.
How do I make this happen?
LER
--
Larry Rosenman
* Larry Rosenman [EMAIL PROTECTED] [010319 10:35] wrote:
Is there any way to get just the ODBC RPM to install with OUT
installing the whole DB?
I have a strange situation:
StarOffice 5.2 (Linux) Running under FreeBSD Linux Emulation
PG running NATIVE.
I want the two to talk, using
Bruce Momjian [EMAIL PROTECTED] writes:
I think it is time to start giving people official responsibility for
certain areas of the code.
This strikes me as overly formalistic, and more likely to lead to
arteriosclerosis than any improvement in code quality. Particularly
with a breakdown
* Alfred Perlstein [EMAIL PROTECTED] [010319 11:27] wrote:
* Larry Rosenman [EMAIL PROTECTED] [010319 10:35] wrote:
Is there any way to get just the ODBC RPM to install with OUT
installing the whole DB?
I have a strange situation:
StarOffice 5.2 (Linux) Running under FreeBSD
I figured that out, now to get the ODBC stuff totally right on the LINUX
side
of the box.
Do we work with unixODBC or the other one?
LER
Original Message
On 3/19/01, 1:44:02 PM, Alfred Perlstein [EMAIL PROTECTED] wrote
regarding Re: [HACKERS] ODBC/FreeBSD/LinuxEmulation/RPM?:
*
The below basically summarizes my opinion quite well ...
On Mon, 19 Mar 2001, Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
I think it is time to start giving people official responsibility for
certain areas of the code.
This strikes me as overly formalistic, and more likely
Jean-Michel POURE [EMAIL PROTECTED] writes:
Just to ask you if someone is planning to release beta 6 RPMs.
I am running Redhat 7.0 test servers and the compiler is broken.
The compiler is not broken. If you find some bugs, please submit them
and we'll fix them.
--
Trond Eivind Glomsrd
Red
On Mon, Mar 19, 2001 at 05:50:01PM +0100, Peter Eisentraut wrote:
In future ... please ignore patches those ignore the /contrib's practice
-- the trouble is overhaul the contrib tree during each version.
The reason it's in contrib is that it's a bit less than perfect. If we
were to
Bruce Momjian [EMAIL PROTECTED] writes:
I think it is time to start giving people official responsibility for
certain areas of the code.
This strikes me as overly formalistic, and more likely to lead to
arteriosclerosis than any improvement in code quality. Particularly
with a
Bruce Momjian [EMAIL PROTECTED] writes:
I understand the formalistic problem, and maybe I overstated its
formality, but it seems it would be good to maintain a list for two
reasons:
I don't have a problem with keeping an informal list of area experts.
I was just objecting to the notion of
Bruce Momjian [EMAIL PROTECTED] writes:
I understand the formalistic problem, and maybe I overstated its
formality, but it seems it would be good to maintain a list for two
reasons:
In projects like gcc and the GNU binutils, we use a MAINTAINERS file.
Some people have blanket write
Bruce Momjian [EMAIL PROTECTED] writes:
I understand the formalistic problem, and maybe I overstated its
formality, but it seems it would be good to maintain a list for two
reasons:
I don't have a problem with keeping an informal list of area experts.
I was just objecting to the notion
Ian Lance Taylor [EMAIL PROTECTED] writes:
In projects like gcc and the GNU binutils, we use a MAINTAINERS file.
Some people have blanket write privileges. Some people have write
priviliges to certain areas of the code. Anybody else needs a patch
to be approved before they can check it in.
Tom Lane [EMAIL PROTECTED] writes:
Ian Lance Taylor [EMAIL PROTECTED] writes:
In projects like gcc and the GNU binutils, we use a MAINTAINERS file.
Some people have blanket write privileges. Some people have write
priviliges to certain areas of the code. Anybody else needs a patch
to
Can someone suggest an addition to the FAQ for this? Does ILIKE, ~* use
such indexes automatically?
Hi,
I've trolled the archives and the FAQ and the closest I could come up with was
the following mailing list message:
Is it really necessary to maintain identical text in the test README
file and in the SGML docs? I'm sorely tempted to remove the README
rather than double-editing yet again.
regards, tom lane
---(end of broadcast)---
TIP
I've looked at the elog calls in the source, about 1700 in total (only
elog(ERROR)). If we mapped these to the SQL error codes then we'd have
about two dozen calls with an assigned code and the rest being "other".
The way I estimate it (I didn't really look at *each* call, of course) is
that
It has been brought up that elog should be able to automatically fill in
the file, line, and perhaps the function name where it's called, to avoid
having to prefix each message with the function name by hand, which is
quite ugly.
This is doable, but it requires a C preprocessor that can handle
Tom Lane writes:
Is it really necessary to maintain identical text in the test README
file and in the SGML docs? I'm sorely tempted to remove the README
rather than double-editing yet again.
It's referenced from the INSTALL file, because people presumably won't be
able to read the HTML
Peter Eisentraut [EMAIL PROTECTED] writes:
Tom Lane writes:
Is it really necessary to maintain identical text in the test README
file and in the SGML docs? I'm sorely tempted to remove the README
rather than double-editing yet again.
It's referenced from the INSTALL file, because people
Peter Eisentraut [EMAIL PROTECTED] writes:
It has been brought up that elog should be able to automatically fill in
the file, line, and perhaps the function name where it's called, to avoid
having to prefix each message with the function name by hand, which is
quite ugly.
Since these would
At 23:56 19/03/01 +0100, Peter Eisentraut wrote:
Essentially, I envision making up a new function, say "elogc", which has
elogc(level, [subsys,?] code, message...)
where the code is some macro, the expansion of which is to be determined.
A call to "elogc" would also require a formalized
Tom Lane [EMAIL PROTECTED] writes:
Additionally, C99 (and GCC for a while) would allow filling in the
function name automatically.
We could probably treat the function name as something that's optionally
added to the file/line error report info if the compiler supports it.
BTW, how
Philip Warner [EMAIL PROTECTED] writes:
I also think it's important that we get the source file and line number
somewhere in the message, and if we have these, we may not need the
subsystem.
I agree that the subsystem concept is not necessary, except possibly as
a means of avoiding collisions
Ian Lance Taylor [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
BTW, how does that work exactly? I assume it can't be a macro ...
It's a macro just like __FILE__ and __LINE__ are macros.
gcc has supported __FUNCTION__ and __PRETTY_FUNCTION__ for a long time
(the latter is
"Vadim Mikheev" [EMAIL PROTECTED] writes:
Anyway, deadlock in my tests are very correlated with new log file
creation - something probably is still wrong...
Well, if you can reproduce it easily, seems like you could
get in there and verify or disprove my theory about where
the deadlock
"Mikheev, Vadim" [EMAIL PROTECTED] writes:
"Vadim Mikheev" [EMAIL PROTECTED] writes:
Anyway, deadlock in my tests are very correlated with new log file
creation - something probably is still wrong...
Well, if you can reproduce it easily, seems like you could
get in there and verify or
* Tom Lane [EMAIL PROTECTED] [010319 18:58]:
Ian Lance Taylor [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
BTW, how does that work exactly? I assume it can't be a macro ...
It's a macro just like __FILE__ and __LINE__ are macros.
gcc has supported __FUNCTION__ and
Peter Eisentraut wrote:
It has been brought up that elog should be able to automatically fill in
the file, line, and perhaps the function name where it's called, to avoid
having to prefix each message with the function name by hand, which is
quite ugly.
This is doable, but it requires a
Oleg Bartunov [EMAIL PROTECTED] writes:
New version of contrib-intarray is available from
http://www.sai.msu.su/~megera/postgres/gist/code/7.1/contrib-intarray.tar.gz
I have made some further changes (you weren't quite there on not
scribbling on input datums, for example) and committed the
Oleg, can you grab the CVS copy and use that for further patches?
Thanks.
Oleg Bartunov [EMAIL PROTECTED] writes:
New version of contrib-intarray is available from
http://www.sai.msu.su/~megera/postgres/gist/code/7.1/contrib-intarray.tar.gz
I have made some further changes (you weren't
Bruce, what is the point of even an informal list of "experts"? There
have always been areas that folks have "adopted" or have developed an
interest and expertise in. And we've gotten lots of really great
contributions both large and small from people we barely knew existed
until the patch
What is the current state-of-the-art WRT replication of any sort ? If anyone
has homebrew solutions that they can share, we would welcome tyring too.
There is some code in contrib/rserv for 7.1 which does table
replication. It has some restrictions, but does implement the basic
concept. I
Is it really necessary to maintain identical text in the test README
file and in the SGML docs? I'm sorely tempted to remove the README
rather than double-editing yet again.
It's referenced from the INSTALL file, because people presumably won't be
able to read the HTML during
So we need some good error numbering scheme. Any ideas?
SQL9x specifies some error codes, with no particular numbering scheme
other than negative numbers indicate a problem afaicr.
Shouldn't we map to those where possible?
- Thomas
---(end of
Karel Zak [EMAIL PROTECTED] writes:
- (IMHO) is good evidently that all executable programs stored here use
prefix 'pg_', but with the exception:
vacuumlo
pgbench(instead pg_bench)
oid2name
ipc_check
fti[.pl]
findoidjoins
What rename it? After 7.1 output
Karel Zak writes:
- everything in the contrib tree has 'uninstall', with the
exception contrib/rserv
Feel free to implement it. ;-)
- every "WANTED_DIRS" has Makefile and is possible install it,
What contrib/start-scripts, contrib/tools and contrib/retep are?
retep is installed
57 matches
Mail list logo
