At 05:36 20/03/01 +, Thomas Lockhart wrote:
>
>Unless there is a "process improvement" which comes with developing this
>list, I don't really see what the benefit will be wrt existance of the
>list, developing the list, of deciding who should be on a list, etc etc.
>
Totally agree; such forma
> 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
> >> 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 duri
> 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 thi
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 arrived
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
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
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 requi
* 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 __
"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
> "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
> th
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 lat
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 collis
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.
>
> B
At 23:56 19/03/01 +0100, Peter Eisentraut wrote:
>
>Essentially, I envision making up a new function, say "elogc", which has
>
>elogc(, [,?] , message...)
>
>where the code is some macro, the expansion of which is to be determined.
>A call to "elogc" would also require a formalized message wor
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
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
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 du
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 va
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 abou
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 4:
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:
>
> http://www.postgresql.org/mhonarc/pgsql-general/2001-01/msg0
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 p
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
> 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
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 privi
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 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
> wit
Jean-Michel POURE wrote:
> 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.
Yes. Announcement soon -- hopefully, it will snow knee-deep here
tonight, giving me the day off tomorrow to build a new set at home.
Been f
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 Glomsrød
R
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
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/Fr
* 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) Runnin
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
* 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 t
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
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 v
> > 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 identif
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.
On Sat, Mar 17, 2001 at 12:31:20PM -0500, Tom Lane wrote:
> After looking more closely I see that pg_restore has two different
> buffer overrun conditions in this one routine. Attached is take two
> of my patch.
>
> This would be a lot simpler and cleaner if _PrintData() simply didn't
> append a
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 installe
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
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 poi
> 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 si
Been reading
http://www.postgresql.org/docs/pgsql/doc/TODO.detail/replication with
interest as we are now approaching a real requirement for it on a project we
have finally resurrected for a bit of a dormant state.
What is the current state-of-the-art WRT replication of any sort ? If anyone
has h
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
> we
Zeugswetter Andreas SB <[EMAIL PROTECTED]> writes:
>> HPUX has usleep, but the man page says
>>
>> The usleep() function is included for its historical usage. The
>> setitimer() function is preferred over this function.
> I doubt that setitimer has microsecond precision on HPUX.
Well, if you i
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
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
The
> 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 aw
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) -DPG
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
Got it, will review it ASAP ...
regards, tom lane
---(end of broadcast)---
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 t
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
> 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
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%)
Reg
> * 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 pu
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 disabl
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 ad
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 include
> >> 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
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
W
> > 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 defi
63 matches
Mail list logo
