[HACKERS] Re: elog with automatic file, line, and function
Larry Rosenman writes:
> * Tom Lane <[EMAIL PROTECTED]> [010319 18:58]:
> > However, if the C99 spec has such a concept, they didn't use that name
> > for it ...
> My C99 compiler (SCO, UDK FS 7.1.1b), defines the following:
> Predefined names
>
> The following identifiers are predefined as object-like macros:
>
>
> __LINE__
> The current line number as a decimal constant.
>
> __FILE__
> A string literal representing the name of the file being compiled.
>
> __DATE__
> The date of compilation as a string literal in the form ``Mmm dd
> .''
>
> __TIME__
> The time of compilation, as a string literal in the form
> ``hh:mm:ss.''
>
> __STDC__
> The constant 1 under compilation mode -Xc, otherwise 0.
>
> __USLC__
> A positive integer constant; its definition signifies a USL C
> compilation system.
>
> Nothing for function that I can find.
It is called __func__ in C99 but it is not an object-like macro. The
difference is that it behaves as if it were declared thus.
static const char __func__[] = "function-name";
Those other identifiers can be used in this sort of way.
printf("Error in " __FILE__ " at line " __LINE__ "\n");
But you've got to do something like this for __func__.
printf("Error in %s\n", __func__);
--
Pete Forman -./\.- Disclaimer: This post is originated
WesternGeco -./\.- by myself and does not represent
[EMAIL PROTECTED] -./\.- opinion of Schlumberger, Baker
http://www.crosswinds.net/~petef -./\.- Hughes or their divisions.
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Re: FAQ: Current state of replication ?
I found interesting paper http://citeseer.nj.nec.com/330257.html "Don't be lazy, be consistent: Postgres-R, A new way to implement Database Replication" Abstract: Database designers often point out that eager, update everywhere replication suffers from high deadlock rates, message overhead and poor response times. In this paper, we show that these limitations can be circumvented by using a combination of known and novel techniques. Moreover, we show how the proposed solution can be incorporated into a real database system. The paper discusses the new protocols and their implementation in PostgreSQL. It also provides experimental results proving that many of the dangers and limitations of replication can be avoided by using the appropriate techniques. 1 Introduction Existing replication protocols can be divided into eager and lazy Regards, Oleg On Tue, 20 Mar 2001, Thomas Lockhart wrote: > > 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 think a tarball to do the same for 7.0 and earlier is > available at www.pgsql.com (just Makefile differences). > > We are currently working through the issues involved with multi-slave > replication and the ramifications for failover to (one of) the slaves. > It looks like the rserv code may assume too much independence between > slaves and replication sync information, and failover may be > not-quite-right in those cases. > > Will be posting to the list when we know the answer (though > contributions and inputs are of course always welcome!). afaict changes > in rserv schema, if necessary, will not be available for 7.1, but we'll > be posting patches and updating the CVS tree. > > btw, it looks like TODO.detail/replication predates the replication > implementation, and has no real relationship with the implementation. > There is some thought that WAL/BAR features can help support replication > at a different level than is done now, but that is work for the future > afaik. > > - Thomas > > ---(end of broadcast)--- > TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] > Regards, Oleg _ Oleg Bartunov, sci.researcher, hostmaster of AstroNet, Sternberg Astronomical Institute, Moscow University (Russia) Internet: [EMAIL PROTECTED], http://www.sai.msu.su/~megera/ phone: +007(095)939-16-83, +007(095)939-23-83 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
AW: [HACKERS] Re: elog with automatic file, line, and function
> > Nothing for function that I can find. > > It is called __func__ in C99 but it is not an object-like macro. The > difference is that it behaves as if it were declared thus. AIX xlc has __FUNCTION__, but unfortunately no __func__ or __PRETTY... It outputs the full demagled funcname with __FUNCTION__ (like __PRETTY...). I do not think it would be appropriate to send file, line and func infos to the client though. Andreas ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] Re: elog with automatic file, line, and function
* Pete Forman <[EMAIL PROTECTED]> [010320 04:22]:
> Larry Rosenman writes:
> > * Tom Lane <[EMAIL PROTECTED]> [010319 18:58]:
> > > However, if the C99 spec has such a concept, they didn't use that name
> > > for it ...
> > My C99 compiler (SCO, UDK FS 7.1.1b), defines the following:
> > Predefined names
> >
> > The following identifiers are predefined as object-like macros:
> >
> >
> > __LINE__
> > The current line number as a decimal constant.
> >
> > __FILE__
> > A string literal representing the name of the file being compiled.
> >
> > __DATE__
> > The date of compilation as a string literal in the form ``Mmm dd
> > .''
> >
> > __TIME__
> > The time of compilation, as a string literal in the form
> > ``hh:mm:ss.''
> >
> > __STDC__
> > The constant 1 under compilation mode -Xc, otherwise 0.
> >
> > __USLC__
> > A positive integer constant; its definition signifies a USL C
> > compilation system.
> >
> > Nothing for function that I can find.
>
> It is called __func__ in C99 but it is not an object-like macro. The
> difference is that it behaves as if it were declared thus.
>
> static const char __func__[] = "function-name";
>
> Those other identifiers can be used in this sort of way.
>
> printf("Error in " __FILE__ " at line " __LINE__ "\n");
>
> But you've got to do something like this for __func__.
>
> printf("Error in %s\n", __func__);
>
I couldn't find it in the docs, but it is in the compiler.
Wierd.
I'll look more.
LER
> --
> Pete Forman -./\.- Disclaimer: This post is originated
> WesternGeco -./\.- by myself and does not represent
> [EMAIL PROTECTED] -./\.- opinion of Schlumberger, Baker
> http://www.crosswinds.net/~petef -./\.- Hughes or their divisions.
>
> ---(end of broadcast)---
> TIP 5: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/users-lounge/docs/faq.html
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED]
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[HACKERS] Re: More on elog and error codes
Thomas Lockhart <[EMAIL PROTECTED]> writes: > > 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? > Good point, but I guess most of the errors produced are pgsql specific. If I remember right Sybase had several different SQL types of error mapped to one of the standard error codes. Also the JDBC API provides methods to look at the database dependent error code and standard error code. I've found both useful when working with Sybase. cheers, Gunnar ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: AW: [HACKERS] Re: elog with automatic file, line, and function
Zeugswetter Andreas SB <[EMAIL PROTECTED]> writes: > I do not think it would be appropriate to send file, line and func > infos to the client though. We still need to work out the details, but my first thought would be to make this conditional on the value of some SET variable. Also, probably the info should always be recorded in the postmaster log. regards, tom lane ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[HACKERS] Re: [DOCS] regression.diff wrong dir name
Justin Clift writes: > Something minor, but when you do a "make check" from the main source > directory and it finishes, it mentions that the regression.diff file is > in ./regression.diff But it says afterwards, "make: leaving directory xyz". If figured that would be sufficient. I hesitated to include the full name, because it would uglify the display so much. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/ ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] More on elog and error codes
Philip Warner writes: > elog(CACHELOOKUPFAIL, cacheItemThatFailed); The disadvantage of this approach, which I tried to explain in a previous message, is that we might want to have different wordings for different occurences of the same class of error. Additionally, the whole idea behind having error *codes* is that the client program can easily distinguish errors that it can handle specially. Thus the codes should be numeric or some other short, fixed scheme. In the backend they could be replaced by macros. Example: #define PGERR_TYPE 1854 /* somewhere... */ elogc(ERROR, PGERR_TYPE, "type %s cannot be created because it already exists", ...) /* elsewhere... */ elogc(ERROR, PGERR_TYPE, "type %s used as argument %d of function %s doesn't exist", ...) In fact, this is my proposal. The "1854" can be argued, but I like the rest. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/ ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
AW: [HACKERS] Re: More on elog and error codes
> > 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? Yes, it defines at least a few dozen char(5) error codes. These are hierarchical, grouped into Warnings and Errors, and have room for implementation specific message codes. Imho there is no room for inventing something new here, or only in addition. Andreas ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] Re: [DOCS] Re: src/test/regress/README duplicates SGML material
Peter Eisentraut <[EMAIL PROTECTED]> writes: > The regress README is also documented, but it involves manual labour. I ended up just applying the same diffs to the README by hand, so it's not an issue at the moment. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] Re: [DOCS] Re: src/test/regress/README duplicates SGML material
> It's all documented: Developer's Guide -> Documentation -> Building the > Documentation -> Plain Text Files. > > The three affected text files are: > INSTALL > HISTORY > src/test/regress/README > > The INSTALL file hasn't been updated in a while, but I am keeping my eye > on it, but we need to have a complete platform list first. (Probably a > good time now...) The HISTORY file isn't actually generated the way it's > documented, but just in case Bruce loses his memory there's an option. > ;-) The regress README is also documented, but it involves manual labour. > I thought we were going to be generating HISTORY from SGML in the future. Good to know we will just keep it as as double-patch. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: AW: [HACKERS] Re: More on elog and error codes
Zeugswetter Andreas SB writes: > > 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? > > Yes, it defines at least a few dozen char(5) error codes. These are hierarchical, > grouped into Warnings and Errors, and have room for implementation specific > message codes. Let's use those then to start with. Anyone got a good idea for a client API to this? I think we could just prefix the actual message with the error code, at least as a start. Since they're all fixed width the client could take them apart easily. I recall other RDBMS' (Oracle?) also having an error code before each message. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/ ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] Re: src/test/regress/README duplicates SGML material
Thomas Lockhart writes: > Just make sure that we have a *complete* list of files which need to be > formatted from sgml to something other than HTML and postscript or pdf > and we'll get them built for the release. It's all documented: Developer's Guide -> Documentation -> Building the Documentation -> Plain Text Files. The three affected text files are: INSTALL HISTORY src/test/regress/README The INSTALL file hasn't been updated in a while, but I am keeping my eye on it, but we need to have a complete platform list first. (Probably a good time now...) The HISTORY file isn't actually generated the way it's documented, but just in case Bruce loses his memory there's an option. ;-) The regress README is also documented, but it involves manual labour. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/ ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
AW: [HACKERS] More on elog and error codes
> #define PGERR_TYPE 1854
#define PGSQLSTATE_TYPE "S0021"// char(5) SQLSTATE
The standard calls this error variable SQLSTATE
(look up in ESQL standard)
first 2 chars are class next 3 are subclass
"0" is e.g. Success
"02000" is Data not found
"U0xxx" user defined routine error xxx is user defined
> /* somewhere... */
>
> elogc(ERROR, PGERR_TYPE, "type %s cannot be created because it already exists", ...)
PGELOG(ERROR, PGSQLSTATE_TYPE, ("type %s cannot be created because it already exists",
...))
put varargs into parentheses to avoid need for ... macros see Tom's proposal
I also agree, that we can group different text messages into the same SQLSTATE,
if it seems appropriate for the client to handle them alike.
Andreas
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: AW: [HACKERS] Re: More on elog and error codes
Coming from an IBM Mainframe background, I'm used to ALL OS/Product messages having a message number, and a fat messages and codes book. I hope we can do that eventually. (maybe a database of the error numbers and codes?) LER >> Original Message << On 3/20/01, 10:53:42 AM, Peter Eisentraut <[EMAIL PROTECTED]> wrote regarding Re: AW: [HACKERS] Re: More on elog and error codes: > Zeugswetter Andreas SB writes: > > > 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? > > > > Yes, it defines at least a few dozen char(5) error codes. These are hierarchical, > > grouped into Warnings and Errors, and have room for implementation specific > > message codes. > Let's use those then to start with. > Anyone got a good idea for a client API to this? I think we could just > prefix the actual message with the error code, at least as a start. > Since they're all fixed width the client could take them apart easily. I > recall other RDBMS' (Oracle?) also having an error code before each > message. > -- > Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/ > ---(end of broadcast)--- > TIP 5: Have you checked our extensive FAQ? > http://www.postgresql.org/users-lounge/docs/faq.html ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: AW: [HACKERS] More on elog and error codes
Zeugswetter Andreas SB <[EMAIL PROTECTED]> writes:
> PGELOG(ERROR, PGSQLSTATE_TYPE, ("type %s cannot be created because it already
>exists", ...))
> put varargs into parentheses to avoid need for ... macros see Tom's proposal
I'd be inclined to make it
PGELOG((ERROR, PGSQLSTATE_TYPE, "type %s cannot be created because it already exists",
...))
The extra parens are ugly and annoying in any case, but they seem
slightly less so if you just double the parens associated with the
PGELOG call. Takes less thought than adding a paren somewhere in the
middle of the call. IMHO anyway...
regards, tom lane
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[HACKERS] Final Call: RC1 about to go out the door ...
Okay folks ...
We'd like to wrap up an RC1 and get this release happening this
year sometime :) Tom mentioned to me that he has no outstandings left on
his plate ... does anyone else have any *show stoppers* left that need to
be addressed, or can I package things up?
Speak now, or forever hold your piece (where forever is the time
between now and RC1 is packaged) ...
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Final Call: RC1 about to go out the door ...
The Hermit Hacker <[EMAIL PROTECTED]> writes: > Speak now, or forever hold your piece (where forever is the time > between now and RC1 is packaged) ... I rather hope it's *NOT* regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] Final Call: RC1 about to go out the door ...
* Tom Lane <[EMAIL PROTECTED]> [010320 10:21] wrote: > The Hermit Hacker <[EMAIL PROTECTED]> writes: > > Speak now, or forever hold your piece (where forever is the time > > between now and RC1 is packaged) ... > > I rather hope it's *NOT* And still no LAZY vacuum. *sigh* -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
RE: [HACKERS] Final Call: RC1 about to go out the door ...
> We'd like to wrap up an RC1 and get this release happening > this year sometime :) Tom mentioned to me that he has no > outstandings left on his plate ... does anyone else have any > *show stoppers* left that need to be addressed, or can I package > things up? I wonder if anybody tried to stop PG in the time of high write activity with pg_ctl -m immediate stop or power off to see how recovery works..? Vadim ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
RE: [HACKERS] Final Call: RC1 about to go out the door ...
> And still no LAZY vacuum. *sigh* Patch will be available in a few days after release. Sorry, Alfred. Vadim ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] Final Call: RC1 about to go out the door ...
The Hermit Hacker writes: > We'd like to wrap up an RC1 and get this release happening this > year sometime :) Tom mentioned to me that he has no outstandings left on > his plate ... does anyone else have any *show stoppers* left that need to > be addressed, or can I package things up? I just uploaded new man pages. I'll probably do them once more in a few days to catch all the changes. We need a supported platform list. Let's hear it. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/ ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] FAQ: Current state of replication ?
> 1. One "writer", many "reader" PostgreSQL servers. We will want to write > provisioning / configuration information centrally and can tolerate a > "writer" failuer for a time. > 2. Consitency at the transaction level. All changes to the "writer" server > will be wrapped in transactions, and there will be foreign key consistency > checking in many tables. > 3. Delays from "writer" through to consistent state on "readers" can be > tolerated to within a few minutes or even more. All read-servers must be in > the same state when answering requests. > > Our objective is to acheive performance and some fault tolerance as the data > is going to be used for near-real time configuration of various other > backend systems in an almost traditional 'net environment. > > As we are coding various other stuff for this project over the next few > months, any help we can be in developing for this part of PostgreSQL, just > let me know. While knowing very little about PostgreSQL internals, we learn > quick. Peter, I've been mostly a lurker here (at least on the hackers list) for a couple of years, but I thought I would "de-lurk" for long enough to reply to your question ;) Attached is the source for a replication solution I recently wrote for a project I'm working on. I think it meets your criteria. I was considering sending it to the list as a possible contrib after 7.1 was released (if anyone is interested, and the code is worthy), but since you asked, here it is. A few disclaimers are in order. First, I am *not* an experienced C programmer. The code works in the limited testing I've done so far but needs to be reviewed and scrubbed by someone with more experience. Second, I have not yet used this in production, so use at your own risk. Third, I have only tested it under Red Hat 6.2 and 7.0. Finally, it will only work with >= PostgreSQL 7.1 beta3. Basic installation instructions: copy pg_lnk.tgz to contrib under the PostgreSQL source tree tar -xzvf pg_lnk.tgz cd pg_lnk ./install.sh I'll be happy to answer any questions to help you get it installed and working. I would appreciate any feedback, improvements, general guidance if you decide to use it. Thanks, Joe pg_lnk.tgz ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Final Call: RC1 about to go out the door ...
UnixWare 7, Rel 7.1.1, using UDK FS Compiler FreeBSD 4.[23] LER >> Original Message << On 3/20/01, 1:11:21 PM, Peter Eisentraut <[EMAIL PROTECTED]> wrote regarding Re: [HACKERS] Final Call: RC1 about to go out the door ...: > The Hermit Hacker writes: > > We'd like to wrap up an RC1 and get this release happening this > > year sometime :) Tom mentioned to me that he has no outstandings left on > > his plate ... does anyone else have any *show stoppers* left that need to > > be addressed, or can I package things up? > I just uploaded new man pages. I'll probably do them once more in a few > days to catch all the changes. > We need a supported platform list. Let's hear it. > -- > Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/ > ---(end of broadcast)--- > TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED]) ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] Final Call: RC1 about to go out the door ...
BSDI 4.01. [ Charset ISO-8859-1 unsupported, converting... ] > UnixWare 7, Rel 7.1.1, using UDK FS Compiler > FreeBSD 4.[23] > > LER > > >> Original Message << > > On 3/20/01, 1:11:21 PM, Peter Eisentraut <[EMAIL PROTECTED]> wrote regarding > Re: [HACKERS] Final Call: RC1 about to go out the door ...: > > > > The Hermit Hacker writes: > > > > We'd like to wrap up an RC1 and get this release happening this > > > year sometime :) Tom mentioned to me that he has no outstandings left on > > > his plate ... does anyone else have any *show stoppers* left that need to > > > be addressed, or can I package things up? > > > I just uploaded new man pages. I'll probably do them once more in a few > > days to catch all the changes. > > > We need a supported platform list. Let's hear it. > > > -- > > Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/ > > > > ---(end of broadcast)--- > > TIP 2: you can get off all lists at once with the unregister command > > (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED]) > > ---(end of broadcast)--- > TIP 6: Have you searched our list archives? > > http://www.postgresql.org/search.mpl > -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] Added to TODO
Added to TODO: * Make elog(LOG) in WAL its own output type, distinct from DEBUG * Delay fsync() when other backends are about to commit too [fsync] * Determine optimal commit_delay value -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] Allowing WAL fsync to be done via O_SYNC
Added to TODO: * Determine optimal fdatasync/fsync, O_SYNC/O_DSYNC options * Allow multiple blocks to be written to WAL with one write() > Bruce Momjian <[EMAIL PROTECTED]> writes: > > It is hard for me to imagine O_* being slower than fsync(), > > Not hard at all --- if we're writing multiple xlog blocks per > transaction, then O_* constrains the sequence of operations more > than we really want. Changing xlog.c to combine writes as much > as possible would reduce this problem, but not eliminate it. > > Besides, the entire object of this exercise is to work around > an unexpected inefficiency in some kernels' implementations of > fsync/fdatasync (viz, scanning over lots of not-dirty buffers). > Who's to say that there might not be inefficiencies in other > platforms' implementations of the O_* options? > > regards, tom lane > -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] triggered data change violation
Cedar Cox <[EMAIL PROTECTED]> writes: >> AFAIK the "triggered data change" message comes out of the AFTER trigger >> code. You sure you don't have any AFTER triggers on the table? Perhaps >> ones added implicitly by a foreign-key constraint? > Not any that I wrote. Ok, the table def is: > CREATE TABLE tblStSC2Options ( > SC2OptionID int4 NOT NULL, > SC2OptionName character varying(50) NOT NULL CHECK (SC2OptionName<>''), > SC2OptionValue float4 CHECK (SC2OptionValue>0), > SurID character varying(50) NOT NULL REFERENCES tblStSC2 ON UPDATE > CASCADE ON DELETE CASCADE, ^^^ Sure looks like a foreign key to me. If you dump the table definition with pg_dump you'll see some AFTER triggers. regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
RE: [HACKERS] Final Call: RC1 about to go out the door ...
Title: RE: [HACKERS] Final Call: RC1 about to go out the door ... Redhat Linux 7.0 (glibc 2.2-12, gcc 2.96-69) MikeA -Original Message- From: Peter Eisentraut To: The Hermit Hacker Cc: [EMAIL PROTECTED] Sent: 20/03/01 19:11 Subject: Re: [HACKERS] Final Call: RC1 about to go out the door ... The Hermit Hacker writes: > We'd like to wrap up an RC1 and get this release happening this > year sometime :) Tom mentioned to me that he has no outstandings left on > his plate ... does anyone else have any *show stoppers* left that need to > be addressed, or can I package things up? I just uploaded new man pages. I'll probably do them once more in a few days to catch all the changes. We need a supported platform list. Let's hear it. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/ ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED]) _ This e-mail and any attachments are confidential and may also be privileged and/or copyright material of Intec Telecom Systems PLC (or its affiliated companies). If you are not an intended or authorised recipient of this e-mail or have received it in error, please delete it immediately and notify the sender by e-mail. In such a case, reading, reproducing, printing or further dissemination of this e-mail is strictly prohibited and may be unlawful. Intec Telecom Systems PLC. does not represent or warrant that an attachment hereto is free from computer viruses or other defects. The opinions expressed in this e-mail and any attachments may be those of the author and are not necessarily those of Intec Telecom Systems PLC. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. __
[HACKERS] Beta 6 Regression results on Redat 7.0.
Ok, thanks to our snowstorm :-0 I have been working on the beta 6 RPM situation on my _slow_ notebook today (power outages for ten minutes at a time happening at hour or so intervals due to 45mph+ winds and a foot of snow). Well, I have preliminary RPM's built -- just need to work on the contrib tree situation. I ran regression the usual RPM way (which I am fully aware is not the normally approved method, but it _would_ be the method any RPM beta testers would use), and got a different failure, one that is not locale related (LC_ALL=C both for the initdb and the postmaster startup in the newest initscript). See attached regression.diffs for details of the temptest failure I experienced. Regression run with CWD=/usr/share/test/regress, user=postgres. ./pg_regress --schedule=parallel_schedule This is the only regression test failure I have found thus far. I have never seen this failure before, so I'm not sure where to proceed. Now to attack the contrib tree (looking forward to my new notebook, as this old P133 takes an hour and twenty minutes to slog through a full build). Seeing that RC1 is in prep, is there a pressing need to upload and release beta 6 RPM's, or will it be a day or two before RC1? -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 *** ./expected/temp.out Sat Jan 8 22:48:39 2000 --- ./results/temp.out Tue Mar 20 16:06:10 2001 *** *** 23,32 (1 row) DROP TABLE temptest; SELECT * FROM temptest; col - !1 (1 row) DROP TABLE temptest; --- 23,34 (1 row) DROP TABLE temptest; + NOTICE: FlushRelationBuffers(temptest, 0): block 0 is referenced (private 0, global +1) + ERROR: heap_drop_with_catalog: FlushRelationBuffers returned -2 SELECT * FROM temptest; col - !2 (1 row) DROP TABLE temptest; *** *** 34,37 -- test temp table deletion \c regression SELECT * FROM temptest; ! ERROR: Relation 'temptest' does not exist --- 36,43 -- test temp table deletion \c regression SELECT * FROM temptest; ! col ! - !1 ! (1 row) ! == ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] More on elog and error codes
On Tue, 20 Mar 2001 10:56, you wrote: > I've looked at the elog calls in the source, about 1700 in total (only [ ... ] > So we need some good error numbering scheme. Any ideas? Just that it might be a good idea to incorporate the version / release details in some way so that when somebody on the list is squeaking about an error message it is obvious to the helper that the advice needed is to upgrade from the Cretatious Period version to a modern release, and have another go. -- Sincerely etc., NAME Christopher Sawtell CELL PHONE 021 257 4451 ICQ UIN45863470 EMAIL csawtell @ xtra . co . nz CNOTES ftp://ftp.funet.fi/pub/languages/C/tutorials/sawtell_C.tar.gz -->> Please refrain from using HTML or WORD attachments in e-mails to me <<-- ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Performance monitor signal handler
I have talked to Jan over the phone, and he has convinced me that UDP is the proper way to communicate stats to the collector, rather than my shared memory idea. The advantages of his UDP approach is that the collector can sleep on the UDP socket rather than having the collector poll the shared memory area. It also has the auto-discard option. He will make logging configurable on a per-database level, so it can be turned off when not in use. He has a trial UDP implementation that he will post soon. Also, I asked him to try DGRAM Unix-domain sockets for performance reasons. My Steven's book says it they should be supported. He can put the socket file in /data. > > > 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 > > and a 1 byte (even if it'd be anoter 32-bit value), how many > > messages do you want to generate to get these statistics: > > > > - Number of sequential scans done per table. > > - Number of tuples returned via sequential scans per table. > > - Number of buffer cache lookups done through sequential > > scans per table. > > - Number of buffer cache hits for sequential scans per > > table. > > - Number of tuples inserted per table. > > - Number of tuples updated per table. > > - Number of tuples deleted per table. > > - Number of index scans done per index. > > - Number of index tuples returned per index. > > - Number of buffer cache lookups done due to scans per > > index. > > - Number of buffer cache hits per index. > > - Number of valid heap tuples returned via index scan per > > index. > > - Number of buffer cache lookups done for heap fetches via > > index scan per index. > > - Number of buffer cache hits for heap fetches via index > > scan per index. > > - Number of buffer cache lookups not accountable for any of > > the above. > > - Number of buffer cache hits not accountable for any of > > the above. > > > > What I see is that there's a difference in what we two want > > to see in the statistics. You're talking about looking at the > > actual querystring and such. That's information useful for > > someone actually looking at a server, to see what a > > particular backend is doing. On my notebook a parallel > > regression test (containing >4,000 queries) passes by under > > 1:30, that's more than 40 queries per second. So that doesn't > > tell me much. > > > > What I'm after is to collect the above data over a week or so > > and then generate a report to identify the hot spots of the > > schema. Which tables/indices cause the most disk I/O, what's > > the average percentage of tuples returned in scans (not from > > the query, I mean from the single scan inside of the joins). > > That's the information I need to know where to look for > > possibly better qualifications, useless indices that aren't > > worth to maintain and the like. > > > > I was going to have the per-table stats insert a stat record every time > it does a sequential scan, so it sould be [oid][sequential_scan_value] > and allow the collector to gather that and aggregate it. > > I didn't think we wanted each backend to do the aggregation per oid. > Seems expensive. Maybe we would need a count for things like "number of > rows returned" so it would be [oid][stat_type][value]. > > -- > Bruce Momjian| http://candle.pha.pa.us > [EMAIL PROTECTED] | (610) 853-3000 > + If your life is a hard drive, | 830 Blythe Avenue > + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 > > ---(end of broadcast)--- > TIP 3: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to [EMAIL PROTECTED] so that your > message can get through to the mailing list cleanly > -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Final Call: RC1 about to go out the door ...
Peter Eisentraut <[EMAIL PROTECTED]> writes: > We need a supported platform list. Let's hear it. HPUX 10.20 (HP-PA architecture) Linux/PPC (LinuxPPC 2000 Q4 distro tested here; 2.2.18 kernel I think) regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
[HACKERS] RE: Re: More on elog and error codes
> So we need some good error numbering scheme. Any ideas? I'm a newbie, but have been following dev and have a few comments and these are thoughts not criticisms: 1) I've seen a huge mixture of "how to implement" to support some desired feature without first knowing "all" of the features that are desired. Examination over all of the mailings reveals some but not all of possible features you may want to include. 2) Define what you want to have without worrying about how to do it. 3) Design something that can implement all of the features. 4) Reconsider design if there are performance issues. e.g. Features desired * system * subsystem * function * file, line, etc * severity * user-ability-to-recover * standards conformance - e.g.. SQL std * default msg statement * locale msg statement lookup mech, os dep or indep (careful here) * success/warning/failure * semantic taxonomy * syntactic taxonomy * forced to user, available to api, logging or not, tracing * concept of level * reports filtering on some attribute * interoperation with existing system reports e.g. syslog, event log,... * system environment snapshot option (e.g. resource low/empty may/should trigger a log of conn cnt, sys resource counts, load, etc) * non-mnemonic internal numbers (mnemonic only to obey stds and then only as a function call, not by implementation) * ease of use (i.e. pgsql-dev-hacker use) * ease of use (i.e. api development use) * ease of use (i.e. rolling into an existing system, e.g. during transition both may need to be in use.) * ease of use (i.e. looking through existing errors to find one that may "correctly" fit the situation, instead of creating yet-another-error-message.) * ease of use (i.e. maybe having each "sub-system" having its own "error domain" but using the same error mechanism) * distinction btwn error report, debug report, tracing report, etc * separate the concepts of - report creation - report delivery - report reception - report interpretation * what do other's do, other's as in os, db, middleware, etc along with their strong and weak points ... what else do you want... and lets flesh out the meaning of each of these. Then we can go on to a design... Sorry if this sounds like a lecture. With regards to mnemonic things - ugh - this is a database. I've worked with a LARGE electronics company that had 10 and 12 digit mnemonic part numbers. The mnemonic-ness begins to break down. (So you have a part number of an eprom, what is the part number when it is blown - still an eprom? how about including the version of the sw on the eprom? is it now an assembly? opps that tended to mean multiple parts attached together, humm still looks like an eprom?) They have gone through a huge transition to move away, as has the industry from mnemonic numbers to simply an id number. You look up the id number in a >database< :-) to find out what it is. So why not drop the mnemonic concept and apply a function to a blackbox dataitem to determine its attribute? But again first determine what attributes you want, which are mandatory, optional, system supplied (e.g. __LINE__ etc), is it for erroring, tracing, debugging, some combo; then the appropriate dataitem can be designed and functions defined. Functions (macros) for both the report creation, report distribution, report reception, and report interpretation. Some other email pointed out that there are different people doing different things. Each of these people-groups should identify what they need with regards to error, debug, tracing reports. Each may have some nuances that are not needed elsewhere, but the reporting system should be able to support them all. Ok, so I've got my flame suit on... but I am really trying to give an "outsiders" birdseye view of what I've been reading, hopefully which may be helpful. Best regards, .. Otto Otto Hirr OLAB Inc. [EMAIL PROTECTED] 503 / 617-6595 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] More on elog and error codes
On Wed, Mar 21, 2001 at 09:41:44AM +1200, Christopher Sawtell wrote: > On Tue, 20 Mar 2001 10:56, you wrote: > > Just that it might be a good idea to incorporate the version / release > details in some way so that when somebody on the list is squeaking about > an error message it is obvious to the helper that the advice needed is to > upgrade from the Cretatious Period version to a modern release, and have ROFL - parsed this as Cretinous period on the first pass. Ross ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Fw: [vorbis-dev] ogg123: shared memory by mmap()
> > > The patch below adds: > > > > > > - acinclude.m4: A new macro A_FUNC_SMMAP to check that sharing > > pages > > > through mmap() works. This is taken from Joerg Schilling's star. > > > - configure.in: A_FUNC_SMMAP > > > - ogg123/buffer.c: If we have a working mmap(), use it to create > > > a region of shared memory instead of using System V IPC. > > > > > > Works on BSD. Should also work on SVR4 and offspring (Solaris), > > > and Linux. > > This is a really bad idea performance wise. Solaris has a special > code path for SYSV shared memory that doesn't require tons of swap > tracking structures per-page/per-process. FreeBSD also has this > optimization (it's off by default, but should work since FreeBSD > 4.2 via the sysctl kern.ipc.shm_use_phys=1) > > Both OS's use a trick of making the pages non-pageable, this allows > signifigant savings in kernel space required for each attached > process, as well as the use of large pages which reduce the amount > of TLB faults your processes will incurr. That is interesting. BSDi has SysV shared memory as non-pagable, and I always thought of that as a bug. Seems you are saying that having it pagable has a significant performance penalty. Interesting. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Re: Patch application
OK, seems there have been enough objections that I will not implement a "experts" page, nor change the way patches are applied. I will be posting a diff -c of any patches I have to munge into place, so people can see how stuff was merged into the code. It seems the problem of people having to massage patches after they are applied is either not a big deal, or the other ways of applying patches are considered worse. > 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 formality will be barrier and we will gain almost > nothing. It will also further disenfranchise the wider developer community. > ISTM that the motivation is based on one or two isolated incidents where > patches were applied when they should not have been. Tom's suggestion of > insisting on CVS headers will deal with the specific case in point, at far > lesser social and labour overhead. > > The last thing we want to do to people who contribute heavily to the > project is say 'Gee, thanks. And you are now responsible for all approvals > on this area of code', especially in late beta, when they are likely to be > quite busy. Similarly, when we are outside the beta phase, we don't need > the process. > > I suspect that anybody who has worked on a chunk of code in a release cycle > will keep an eye on what is happening to the code. > > My suggestion for handling this process would be to allow an opt-in 'watch' > to be placed on files/modules in CVS (CVS supports this, from memory). > Then, eg, I can say 'send me info when someone makes a match to pg_dump'. > Similarly, when I start working on a module, I can add myself to the list > to be informed when someone changes it underneath me. This would be > genuinely useful to me as a part-time developer. > > As a further development from this, it would be good to see a way for bug > reports to be redirected to 'subsystems' (or something like that), which > developers could opt into. So, using myself as an example, I would like > special notification when a pg_dump bug is reported. Similarly, I might > like to be notified when changes are made to the WAL code... > > If you want to make cute web pages, and define domain experts, make it > useful, make it opt-in, and make it dynamic. > > > > Philip Warner| __---_ > Albatross Consulting Pty. Ltd. |/ - \ > (A.B.N. 75 008 659 498) | /(@) __---_ > Tel: (+61) 0500 83 82 81 | _ \ > Fax: (+61) 0500 83 82 82 | ___ | > Http://www.rhyme.com.au |/ \| > |---- > PGP key available upon request, | / > and from pgp5.ai.mit.edu:11371 |/ > > ---(end of broadcast)--- > TIP 4: Don't 'kill -9' the postmaster > -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Beta 6 Regression results on Redat 7.0.
Lamar Owen <[EMAIL PROTECTED]> writes: > DROP TABLE temptest; > + NOTICE: FlushRelationBuffers(temptest, 0): block 0 is referenced (private 0, >global 1) > + ERROR: heap_drop_with_catalog: FlushRelationBuffers returned -2 > SELECT * FROM temptest; Hoo, that's interesting ... Exactly what fileset were you using again? > Seeing that RC1 is in prep, is there a pressing need to upload and > release beta 6 RPM's, or will it be a day or two before RC1? I think you might as well wait for RC1 as far as actually making RPMs goes. But do you want to let anyone else check out the RPM build process? For instance, I've been wondering what you did about the which-set-of-headers-to-install issue. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] pg_dump - failed sanity check, type
(First of all, is this the right list?) When doing pg_dump testdb -u I get failed sanity check, type with oid 899762 was not found I searched my backend log for this oid and found something near the 'tryme' function. As far as I can find I have two functions defined with different args and one has a problem. These are an old unused functions I wrote in plpgsql. I'm guessing that if I remove them the problem will go away. Result | Function | Arguments ---+---+-- bool | tryme | - bool | tryme | record testdb=# select proargtypes from pg_proc where proname='tryme'; proargtypes - 298035 899762 (2 rows) Am I making sense? .. comments? What's going on? Thanks -Cedar ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] More on elog and error codes
At 17:35 20/03/01 +0100, Peter Eisentraut wrote: >Philip Warner writes: > >> elog(CACHELOOKUPFAIL, cacheItemThatFailed); > >The disadvantage of this approach, which I tried to explain in a previous >message, is that we might want to have different wordings for different >occurences of the same class of error. > >Additionally, the whole idea behind having error *codes* is that the >client program can easily distinguish errors that it can handle specially. >Thus the codes should be numeric or some other short, fixed scheme. In >the backend they could be replaced by macros. This seems to be just an argument for constructing the value of PGERR_CACHELOOKUPFAIL carefully (which is what the VMS message source files did). The point is that when they are used by a developer, they are simple. >#define PGERR_TYPE 1854 > >/* somewhere... */ > >elogc(ERROR, PGERR_TYPE, "type %s cannot be created because it already exists", ...) > >/* elsewhere... */ > >elogc(ERROR, PGERR_TYPE, "type %s used as argument %d of function %s doesn't exist", ...) > I can appreciate that there may be cases where the same message is reused, but that is where parameter substitution comes in. In the specific example above, returning the same error code is not going to help the client. What if they want to handle "type %s used as argument %d of function %s doesn't exist" by creating the type, and silently ignore "type %s cannot be created because it already exists"? How do you handle "type %s can not be used as a function return type"? Is this PGERR_FUNC or PGERR_TYPE? If the motivation behind this is to alloy easy translation to SQL error codes, then I suggest we have an error definition file with explicit translation: Code SQL Text PGERR_TYPALREXI 02xxx "type %s cannot be created because it already exists" PGERR_FUNCNOTYPE 02xxx "type %s used as argument %d of function %s doesn't exist" and if we want a generic 'type does not exist', then: PGERR_NOSUCHTYPE 02xxx "type %s does not exist - %s" where the %s might contain 'it can't be used as a function argument'. the we just have elogc(ERROR, PGERR_TYPALEXI, ...) /* elsewhere... */ elogc(ERROR, PGERR_FUNCNOTYPE, ...) Creating central message files/objects has the added advantage of a much simpler locale support - they're just resource files, and they're NOT embedded throughout the code. Finally, if you do want to have some kind of error classification beyond the SQL code, it could be encoded in the error message file. Philip Warner| __---_ Albatross Consulting Pty. Ltd. |/ - \ (A.B.N. 75 008 659 498) | /(@) __---_ Tel: (+61) 0500 83 82 81 | _ \ Fax: (+61) 0500 83 82 82 | ___ | Http://www.rhyme.com.au |/ \| |---- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/ ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] Beta 6 Regression results on Redat 7.0.
On Tue, 20 Mar 2001, Lamar Owen wrote: > Ok, thanks to our snowstorm :-0 I have been working on the beta 6 RPM situation > on my _slow_ notebook today (power outages for ten minutes at a time happening > at hour or so intervals due to 45mph+ winds and a foot of snow). > > Well, I have preliminary RPM's built -- just need to work on the contrib tree > situation. I ran regression the usual RPM way (which I am fully aware is not > the normally approved method, but it _would_ be the method any RPM beta testers > would use), and got a different failure, one that is not locale related > (LC_ALL=C both for the initdb and the postmaster startup in the newest > initscript). See attached regression.diffs for details of the temptest failure > I experienced. > > Regression run with CWD=/usr/share/test/regress, user=postgres. > ./pg_regress --schedule=parallel_schedule > > This is the only regression test failure I have found thus far. I have never > seen this failure before, so I'm not sure where to proceed. > > Now to attack the contrib tree (looking forward to my new notebook, as this old > P133 takes an hour and twenty minutes to slog through a full build). > > Seeing that RC1 is in prep, is there a pressing need to upload and release beta > 6 RPM's, or will it be a day or two before RC1? Im going to do RC1 tonight ... so no pressng need :) ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] More on elog and error codes
At 09:41 21/03/01 +1200, Christopher Sawtell wrote: >Just that it might be a good idea to incorporate the version / release >details in some way so that when somebody on the list is squeaking about >an error message it is obvious to the helper that the advice needed is to >upgrade from the Cretatious Period version to a modern release, and have >another go. This is better handled by the bug *reporting* system; the users can easily get the current version number from PG and send it with their reports. We don't really want all the error codes changing between releases. Philip Warner| __---_ Albatross Consulting Pty. Ltd. |/ - \ (A.B.N. 75 008 659 498) | /(@) __---_ Tel: (+61) 0500 83 82 81 | _ \ Fax: (+61) 0500 83 82 82 | ___ | Http://www.rhyme.com.au |/ \| |---- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/ ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] Beta 6 Regression results on Redat 7.0.
On Tue, 20 Mar 2001, Tom Lane wrote:
> Lamar Owen <[EMAIL PROTECTED]> writes:
> > DROP TABLE temptest;
> > + NOTICE: FlushRelationBuffers(temptest, 0): block 0 is referenced (private 0,
>global 1)
> > + ERROR: heap_drop_with_catalog: FlushRelationBuffers returned -2
> > SELECT * FROM temptest;
> Hoo, that's interesting ... Exactly what fileset were you using again?
When you say 'fileset', I'm assuming you are referring to the --schedule
parameter -- I am invoking the following command:
./pg_regress --schedule=parallel_schedule
7.1beta6 distribution tarball. LC_ALL=C. Compiled on RedHat 7 as shipped.
I'm rerunning to see if it is intermittent. Second run -- no error. Running a
third time..no error. Now I'm confused. What would cause such an error,
Tom? I'm going to check on my desktop, once power gets more stable (and it
quits lightning -- yes, a snowstorm with lightning :-0 I certainly got what I
wanted.). So, more to come later.
> > Seeing that RC1 is in prep, is there a pressing need to upload and
> > release beta 6 RPM's, or will it be a day or two before RC1?
> I think you might as well wait for RC1 as far as actually making RPMs
> goes. But do you want to let anyone else check out the RPM build
> process? For instance, I've been wondering what you did about the
> which-set-of-headers-to-install issue.
Oh, ok. Spec file attached. All other files needed are the beta6 tarball and
the contents of the beta4-1 source rpm, with names changed to match the beta6
version number. There are some other changes I have to merge in --
particularly a set from Karl for the optional PL/Perl build, as well as others,
so this is a preliminary spec file.
But I was just getting the basic build done and tested.
To directly answer your question, I'm using 'make install-all-headers' and
stuffing it into the devel rpm in one piece at this time.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
Summary: PostgreSQL client programs and libraries.
Name: postgresql
Version: 7.1beta6
Release: 0.2
License: BSD
Group: Applications/Databases
Source0: ftp://ftp.postgresql.org/pub/source/v%{version}/postgresql-%{version}.tar.gz
Source3: postgresql.init-%{version}
Source4: file-lists-pgsql-%{version}.tar.gz
Source5: ftp://ftp.postgresql.org/pub/source/v%{version}/postgresql-%{version}.tar.gz.md5
Source6: README.rpm-dist.postgresql-%{version}
Source7: pg-migration-scripts-%{version}.tar.gz
Source8: logrotate.postgresql-%{version}
Source10: http://www.retep.org.uk/postgres/jdbc7.0-1.1.jar
Source11: http://www.retep.org.uk/postgres/jdbc7.0-1.2.jar
Source12: postgresql-dump.1.gz
Source14: rh-pgdump.sh
Patch1: rpm-pgsql-%{version}.patch
Requires: perl
Prereq: /sbin/chkconfig /sbin/ldconfig /usr/sbin/useradd initscripts
BuildPrereq: python-devel perl tcl /lib/cpp
Url: http://www.postgresql.org/
Obsoletes: postgresql-clients
Buildroot: %{_tmppath}/%{name}-%{version}-root
# This is the PostgreSQL Global Development Group Official RPMset spec file.
# Copyright 2000 Lamar Owen <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
# and others listed.
# Major Contributors:
# ---
# Lamar Owen
# Trond Eivind Glomsrød <[EMAIL PROTECTED]>
# Thomas Lockhart
# This spec file and ancilliary files are licensed in accordance with
# The PostgreSQL license.
#Below are the default build package list macros. These can be overridden by defining
# on the rpm command line:
# rpm --define 'packagename 1' to force the package to build.
# rpm --define 'packagename 0' to force the package NOT to build.
# The base package, the lib package, the devel package, and the server package always get built.
%{!?perl:%define perl 1}
%{!?tcl:%define tcl 1}
%{!?tkpkg:%define tkpkg %{expand:tcl}}
%{!?odbc:%define odbc 1}
%{!?jdbc:%define jdbc 1}
%{!?test:%define test 1}
%{!?python:%define python 1}
%{!?pltcl:%define pltcl 1}
%{!?plperl:%define plperl 1}
# Utility feature defines.
%{!?enable_mb:%define enable_mb 1}
%{!?pgacess:%define pgaccess 1}
%dump
%description
PostgreSQL is an advanced Object-Relational database management system
(DBMS) that supports almost all SQL constructs (including
transactions, subselects and user-defined types and functions). The
postgresql package includes the client programs and libraries that
you'll need to access a PostgreSQL DBMS server. These PostgreSQL
client programs are programs that directly manipulate the internal
structure of PostgreSQL databases on a PostgreSQL server. These client
programs can be located on the same machine with the PostgreSQL
server, or may be on a remote machine which accesses a PostgreSQL
server over a network connection. This package contains the client
libraries for C and C++, as well as command-line utilities for
managing PostgreSQL databases on a PostgreSQL server.
If you want to manipulate a PostgreSQL database on a remote PostgreSQL
server, you need this package. You also need to install this package
if you're installing the postgresql-server package.
%
Re: [HACKERS] Beta 6 Regression results on Redat 7.0.
Lamar Owen <[EMAIL PROTECTED]> writes: > DROP TABLE temptest; > + NOTICE: FlushRelationBuffers(temptest, 0): block 0 is referenced (private 0, >global 1) > + ERROR: heap_drop_with_catalog: FlushRelationBuffers returned -2 > SELECT * FROM temptest; >> Hoo, that's interesting ... Exactly what fileset were you using again? > When you say 'fileset', I'm assuming you are referring to the --schedule > parameter -- No, I was wondering about whether you had an inconsistent set of source files, or had managed to not do a complete rebuild, or something like that. The above error should be entirely impossible considering that the table in question is a temp table that's not been touched by any other backend. If you did manage to get this from a clean build then I think we have a serious problem to look at. >> I think you might as well wait for RC1 as far as actually making RPMs >> goes. But do you want to let anyone else check out the RPM build >> process? For instance, I've been wondering what you did about the >> which-set-of-headers-to-install issue. > Oh, ok. Spec file attached. All other files needed are the beta6 tarball and > the contents of the beta4-1 source rpm, with names changed to match the beta6 > version number. OK, I will pull the files and try to replicate this on my own laptop. Does anyone else have time to try to duplicate the problem tonight? If it's replicatable at all, I think it's a release stopper. > To directly answer your question, I'm using 'make install-all-headers' and > stuffing it into the devel rpm in one piece at this time. Works for me. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Beta 6 Regression results on Redat 7.0.
On Tue, 20 Mar 2001, Tom Lane wrote: > Lamar Owen <[EMAIL PROTECTED]> writes: > > DROP TABLE temptest; > > + NOTICE: FlushRelationBuffers(temptest, 0): block 0 is referenced (private 0, >global 1) > > + ERROR: heap_drop_with_catalog: FlushRelationBuffers returned -2 > > SELECT * FROM temptest; > >> Hoo, that's interesting ... Exactly what fileset were you using again? > > When you say 'fileset', I'm assuming you are referring to the --schedule > > parameter -- > No, I was wondering about whether you had an inconsistent set of source > files, or had managed to not do a complete rebuild, or something like > that. The above error should be entirely impossible considering that > the table in question is a temp table that's not been touched by any > other backend. If you did manage to get this from a clean build then > I think we have a serious problem to look at. Standard RPM rebuild -- always wipes the whole build tree out and re-expands from the tarball, reapplies patches, and rebuilds from scratch every time I change even the smallest detail in the spec file -- which is why it takes so long to get these things out. So, no, this is a scratch build from a fresh tarball. > Does anyone else have time to try to duplicate the problem tonight? > If it's replicatable at all, I think it's a release stopper. I have not yet been able to repeat the problem. I am running my fifth regression test run (which takes a long time on this P133) with a freshly initdb'ed PGDATA -- the previous regression runs were done on the same PGDATA tree as the first run was done on. Took 12 minutes 40 seconds, but I can't repeat the error. I'm hoping it was a problem on my machine -- educate me on what caused the error so I can see if something in my setup did something not so nice. So, the score is one error out of six test runs, thus far. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Beta 6 Regression results on Redat 7.0.
Lamar Owen <[EMAIL PROTECTED]> writes: > I'm hoping it was a problem on my machine -- educate me on > what caused the error Well, that's exactly what I'd like to know. The direct cause of the error is that DROP TABLE is finding that some other backend has a reference-count hold on a page of the temp table it's trying to drop. Since no other backend should be trying to touch this temp table, there's something pretty fishy here. Given that this is a parallel test, you may be looking at a low-probability timing-dependent failure. I'd say set up the machine and run repeat tests for an hour or three ... that's what I plan to do here. BTW, what postmaster parameters are you using --- -B and so forth? regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
RE: [HACKERS] Beta 6 Regression results on Redat 7.0.
> I'm rerunning to see if it is intermittent. Second run -- no > error. Running a third time..no error. Now I'm confused. > What would cause such an error, Tom? I'm going to check on my Hmm, concurrent checkpoint? Probably we could simplify dirty test in ByfferSync() - ie test bufHdr->cntxDirty without holding shlock (and pin!) on buffer: should be good as long as we set cntxDirty flag *before* XLogInsert in access methods. Have to look more... Vadim ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] Beta 6 Regression results on Redat 7.0.
On Tue, 20 Mar 2001, Tom Lane wrote: > Since no other backend should be trying to touch this temp table, > there's something pretty fishy here. I see. > Given that this is a parallel test, you may be looking at a > low-probability timing-dependent failure. I'd say set up the machine > and run repeat tests for an hour or three ... that's what I plan to do > here. As a broadcast engineer, I'm a little too familiar with such things. But this isn't an engineer list, so I'll spare you the war stories. :-) > BTW, what postmaster parameters are you using --- -B and so forth? Default. To be changed before RPM release, but currently it is the default. The only option that postmaster.opts records is -D, and I'm not passing anything else. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] pgindent run?
With RC1 nearing, when should I run pgindent? This is usually the time I do it. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
[HACKERS] pg_inherits: not found, but visible
Postmaster crashed on me, and on restart, pg_inherits cannot be found. I can see it in pg_class (and it shows up w/ \dS), but any attempt to modify anything fails with "pg_inherits: No such file or directory". I've reindexed the database (w/postgres -P -O). Vacuuming fails (w/error above). What could this be? Is there any hope? Thanks! -- Joel Burton <[EMAIL PROTECTED]> Director of Information Systems, Support Center of Washington ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Fw: [vorbis-dev] ogg123: shared memory by mmap()
* Bruce Momjian <[EMAIL PROTECTED]> [010320 14:10] wrote: > > > > The patch below adds: > > > > > > > > - acinclude.m4: A new macro A_FUNC_SMMAP to check that sharing > > > pages > > > > through mmap() works. This is taken from Joerg Schilling's star. > > > > - configure.in: A_FUNC_SMMAP > > > > - ogg123/buffer.c: If we have a working mmap(), use it to create > > > > a region of shared memory instead of using System V IPC. > > > > > > > > Works on BSD. Should also work on SVR4 and offspring (Solaris), > > > > and Linux. > > > > This is a really bad idea performance wise. Solaris has a special > > code path for SYSV shared memory that doesn't require tons of swap > > tracking structures per-page/per-process. FreeBSD also has this > > optimization (it's off by default, but should work since FreeBSD > > 4.2 via the sysctl kern.ipc.shm_use_phys=1) > > > > > Both OS's use a trick of making the pages non-pageable, this allows > > signifigant savings in kernel space required for each attached > > process, as well as the use of large pages which reduce the amount > > of TLB faults your processes will incurr. > > That is interesting. BSDi has SysV shared memory as non-pagable, and I > always thought of that as a bug. Seems you are saying that having it > pagable has a significant performance penalty. Interesting. Yes, having it pageable is actually sort of bad. It doesn't allow you to do several important optimizations. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Beta 6 Regression results on Redat 7.0.
On Tue, 20 Mar 2001, Tom Lane wrote: > Lamar Owen <[EMAIL PROTECTED]> writes: > > I'm hoping it was a problem on my machine -- educate me on > > what caused the error > > Well, that's exactly what I'd like to know. The direct cause of the > error is that DROP TABLE is finding that some other backend has a > reference-count hold on a page of the temp table it's trying to drop. > Since no other backend should be trying to touch this temp table, > there's something pretty fishy here. > > Given that this is a parallel test, you may be looking at a > low-probability timing-dependent failure. I'd say set up the machine > and run repeat tests for an hour or three ... that's what I plan to do > here. Okay, I roll'd an RC1 but haven't put it up for FTP yet ... I'll wait for a few hours to see if anyone can reproduce this, and, if not, put out what I've rolled ... say, 00:00AST ... ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] pg_inherits: addt'l info
I'm sorry, I should have included: PostgreSQL 7.1beta4 Linux-Mandrake 7.1 (very simiiar RedHat 7) Intel hardware -- Joel Burton <[EMAIL PROTECTED]> Director of Information Systems, Support Center of Washington ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Beta 6 Regression results on Redat 7.0.
"Mikheev, Vadim" <[EMAIL PROTECTED]> writes: > Hmm, concurrent checkpoint? Probably we could simplify dirty test > in ByfferSync() - ie test bufHdr->cntxDirty without holding > shlock (and pin!) on buffer: should be good as long as we set > cntxDirty flag *before* XLogInsert in access methods. Have to > look more... Yes, I'm wondering if some other backend is trying to write/flush the buffer (maybe as part of a checkpoint, maybe not). But seems like we should have seen this before, if so; that's not a low- probability scenario, particularly with just 64 buffers... regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Final Call: RC1 about to go out the door ...
Go here to report or to see the list. http://www.postgresql.org/~vev/regress/ Vince. On Tue, 20 Mar 2001, Larry Rosenman wrote: > UnixWare 7, Rel 7.1.1, using UDK FS Compiler > FreeBSD 4.[23] > > LER > > >> Original Message << > > On 3/20/01, 1:11:21 PM, Peter Eisentraut <[EMAIL PROTECTED]> wrote regarding > Re: [HACKERS] Final Call: RC1 about to go out the door ...: > > > > The Hermit Hacker writes: > > > > We'd like to wrap up an RC1 and get this release happening this > > > year sometime :) Tom mentioned to me that he has no outstandings left on > > > his plate ... does anyone else have any *show stoppers* left that need to > > > be addressed, or can I package things up? > > > I just uploaded new man pages. I'll probably do them once more in a few > > days to catch all the changes. > > > We need a supported platform list. Let's hear it. > > > -- > > Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/ > > > > ---(end of broadcast)--- > > TIP 2: you can get off all lists at once with the unregister command > > (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED]) > > ---(end of broadcast)--- > TIP 6: Have you searched our list archives? > > http://www.postgresql.org/search.mpl > -- == Vince Vielhaber -- KA8CSHemail: [EMAIL PROTECTED]http://www.pop4.net 56K Nationwide Dialup from $16.00/mo at Pop4 Networking Online Campground Directoryhttp://www.camping-usa.com Online Giftshop Superstorehttp://www.cloudninegifts.com == ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] pg_inherits: not found, but visible
Joel Burton wrote: > > Postmaster crashed on me, and on restart, pg_inherits cannot be found. > I can see it in pg_class (and it shows up w/ \dS), but any attempt to > modify anything fails with "pg_inherits: No such file or directory". > > I've reindexed the database (w/postgres -P -O). Vacuuming fails (w/error > above). > > What could this be? Is there any hope? > Try the following queries. 1) select oid from pg_database where datname = your_db_name; 2) select oid, relfilenode from pg_class where relname = 'pg_inherits'; For example I get the followings in my environment. 1) oid = 18720 2) relfilenode(==oid) = 16567; and I could find a $PGDATA/base/18720/16567 file. Could you find such a file ? regards, Hiroshi Inoue ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] Beta 6 Regression results on Redat 7.0.
The Hermit Hacker <[EMAIL PROTECTED]> writes: > Okay, I roll'd an RC1 but haven't put it up for FTP yet ... I'll wait for > a few hours to see if anyone can reproduce this, and, if not, put out what > I've rolled ... This will not be RC1 :-( I'm been running one backend doing repeated iterations of CREATE TABLE temptest(col int); INSERT INTO temptest VALUES (1); CREATE TEMP TABLE temptest(col int); INSERT INTO temptest VALUES (2); SELECT * FROM temptest; DROP TABLE temptest; SELECT * FROM temptest; DROP TABLE temptest; and another one doing repeated CHECKPOINTs. I've already gotten a couple occurrences of Lamar's failure. I think the problem is that BufferSync unconditionally does PinBuffer on each buffer, and holds the pin during intervals where it's released BufMgrLock, even if there's not really anything for it to do on that buffer. If someone else is running FlushRelationBuffers then it's possible for that routine to see a nonzero pin count when it looks. Vadim, what do you think about how to change this? I think this is BufferSync's fault not FlushRelationBuffers's ... regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] pg_inherits: not found, but visible
On Wed, 21 Mar 2001, Hiroshi Inoue wrote: > Joel Burton wrote: > > > > Postmaster crashed on me, and on restart, pg_inherits cannot be found. > > I can see it in pg_class (and it shows up w/ \dS), but any attempt to > > modify anything fails with "pg_inherits: No such file or directory". > > > > I've reindexed the database (w/postgres -P -O). Vacuuming fails (w/error > > above). > > > > What could this be? Is there any hope? > > > > Try the following queries. > 1) select oid from pg_database where datname = your_db_name; > 2) select oid, relfilenode from pg_class where relname = 'pg_inherits'; > > For example I get the followings in my environment. > 1) oid = 18720 > 2) relfilenode(==oid) = 16567; > > and I could find a $PGDATA/base/18720/16567 file. > Could you find such a file ? No. I do have the db directory, and all of the other file for the existing classes, but not this. Any ideas why this would disappear? Or any ideas about how to get my existing data out? (I have a dump from about 36 hours ago; it would be nice to extract some more recent data!) -- Joel Burton <[EMAIL PROTECTED]> Director of Information Systems, Support Center of Washington ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Final Call: RC1 about to go out the door ...
On Tue, Mar 20, 2001 at 08:11:21PM +0100, Peter Eisentraut wrote: > > We need a supported platform list. Let's hear it. Linux 2.4.2 (Debian, Woody), glibc 2.2.2, gcc 2.95.3 (from CVS). -Roberto -- +| http://fslc.usu.edu USU Free Software & GNU/Linux Club|--+ Roberto Mello - Computer Science, USU - http://www.brasileiro.net http://www.sdl.usu.edu - Space Dynamics Lab, Web Developer ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Beta 6 Regression results on Redat 7.0.
On Tue, 20 Mar 2001, Tom Lane wrote: > This will not be RC1 :-( > 'Ive already gotten a > couple occurrences of Lamar's failure. Well, I was at least hoping it was a problem here -- particularly since I haven't been able to reproduce it. But, since it is not a local problem, I'm glad I caught it -- on the first regression test run, no less. I've run a dozen tests since without duplication. Although, like you, Tom, I'm curious as to why it hadn't showed up before -- is the fact that this is a slow machine a factor, possibly? Although I am now much more leery of our regression suite -- this issue isn't even tested, in reality. Do we have _any_ WAL-related tests? The parallel testing is a good thing -- but I wonder what boundary conditions aren't getting tested. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] pg_inherits: not found, but visible
Joel Burton <[EMAIL PROTECTED]> writes: >> and I could find a $PGDATA/base/18720/16567 file. >> Could you find such a file ? > No. I do have the db directory, and all of the other file for the existing > classes, but not this. Hm. You could make an empty file by that name (just 'touch' it) and then you'd probably be able to dump (possibly after reindexing pg_inherit's indexes again). pg_inherits isn't a real critical table, fortunately. > Any ideas why this would disappear? Interesting question, all right. Did you have a system crash? regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] pg_inherits: not found, but visible
Joel Burton wrote: > > On Wed, 21 Mar 2001, Hiroshi Inoue wrote: > > > Joel Burton wrote: > > > > > > Postmaster crashed on me, and on restart, pg_inherits cannot be found. > > > I can see it in pg_class (and it shows up w/ \dS), but any attempt to > > > modify anything fails with "pg_inherits: No such file or directory". > > > > > > I've reindexed the database (w/postgres -P -O). Vacuuming fails (w/error > > > above). > > > > > > What could this be? Is there any hope? > > > > > > > Try the following queries. > > 1) select oid from pg_database where datname = your_db_name; > > 2) select oid, relfilenode from pg_class where relname = 'pg_inherits'; > > > > For example I get the followings in my environment. > > 1) oid = 18720 > > 2) relfilenode(==oid) = 16567; > > > > and I could find a $PGDATA/base/18720/16567 file. > > Could you find such a file ? > > No. I do have the db directory, and all of the other file for the existing > classes, but not this. > Just a confirmation. What is a result of the second query in your current environment ? > Any ideas why this would disappear? I have no idea but this is really a disastrous phenomenon. > Or any ideas about how to get my > existing data out? (I have a dump from about 36 hours ago; it would be > nice to extract some more recent data!) > Are you using inheritance ? regards, Hiroshi Inoue ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Beta 6 Regression results on Redat 7.0.
Lamar Owen <[EMAIL PROTECTED]> writes: > Although I am now much more leery of our regression suite The regression tests are not at all designed to test concurrent behavior, and never have been. The parallel form runs some tests in parallel, true, but those tests are deliberately designed not to interact. So I don't put any faith in the regression tests as a means to catch bugs like this. We need some thought and work on better concurrent tests... regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] pg_inherits: not found, but visible
On Tue, 20 Mar 2001, Tom Lane wrote: > Joel Burton <[EMAIL PROTECTED]> writes: > >> and I could find a $PGDATA/base/18720/16567 file. > >> Could you find such a file ? > > > No. I do have the db directory, and all of the other file for the existing > > classes, but not this. > > Hm. You could make an empty file by that name (just 'touch' it) and > then you'd probably be able to dump (possibly after reindexing > pg_inherit's indexes again). pg_inherits isn't a real critical table, > fortunately. > > > Any ideas why this would disappear? > > Interesting question, all right. Did you have a system crash? Ok, so I touched the file, and did a postgres -P -O reindex of the table with force. Going into psql then, I could select * from the table, and, not surprisingly, nothing was in it, but I can (& did) dump my data. For those watching, that's about 15 minutes from the sinking feeling of 'I just lost two days of work' to 'resolution and data restored'. Our community has *damn fine* technical support! :-) Thanks, Tom, and Hiroshi, for being so helpful so quickly. As for your questions, no, I didn't have a system crash. I was running a Zope page that queries several tables (show all classes, for each class, show all instances, for each instance, show all dates, etc.); the page normally takes about 2 minutes to pull everything together (I think that's Zope's speed issue, not PG!) Anyway, while that was chugging away, I tried to drop a view and recreate it, and that request just hung there for a few minutes. The Zope page never came up, and psql notified me that I lost my connection. I wasn't, and haven't ever, used inheritance in this database. -- Joel Burton <[EMAIL PROTECTED]> Director of Information Systems, Support Center of Washington ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] pg_inherits: not found, but visible
On Wed, 21 Mar 2001, Hiroshi Inoue wrote: > Joel Burton wrote: > > > > On Wed, 21 Mar 2001, Hiroshi Inoue wrote: > > > > > Joel Burton wrote: > > > > > > > > Postmaster crashed on me, and on restart, pg_inherits cannot be found. > > > > I can see it in pg_class (and it shows up w/ \dS), but any attempt to > > > > modify anything fails with "pg_inherits: No such file or directory". > > > > > > > > I've reindexed the database (w/postgres -P -O). Vacuuming fails (w/error > > > > above). > > > > > > > > What could this be? Is there any hope? > > > > > > > > > > Try the following queries. > > > 1) select oid from pg_database where datname = your_db_name; > > > 2) select oid, relfilenode from pg_class where relname = 'pg_inherits'; > > > > > > For example I get the followings in my environment. > > > 1) oid = 18720 > > > 2) relfilenode(==oid) = 16567; > > > > > > and I could find a $PGDATA/base/18720/16567 file. > > > Could you find such a file ? > > > > No. I do have the db directory, and all of the other file for the existing > > classes, but not this. > > > > Just a confirmation. What is a result of the second query > in your current environment ? I got exactly what I would expect in a working PG db: the oid and relfilenode matched, and were OIDs in the range of the other system tables in the directory. -- Joel Burton <[EMAIL PROTECTED]> Director of Information Systems, Support Center of Washington ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
RE: [HACKERS] Beta 6 Regression results on Redat 7.0.
> I think the problem is that BufferSync unconditionally does PinBuffer > on each buffer, and holds the pin during intervals where it's released > BufMgrLock, even if there's not really anything for it to do on that > buffer. If someone else is running FlushRelationBuffers then it's > possible for that routine to see a nonzero pin count when it looks. > > Vadim, what do you think about how to change this? I think this is > BufferSync's fault not FlushRelationBuffers's ... I'm looking there right now... Vadim ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[HACKERS] Re: Final Call: RC1 about to go out the door ...
> HPUX 10.20 (HP-PA architecture) Time to drop 9.2 from the list? > Linux/PPC (LinuxPPC 2000 Q4 distro tested here; 2.2.18 kernel I think) What processor? Tatsuo had tested on a 603... - Thomas ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] pg_inherits: not found, but visible [IT GETS WORSE]
Yikes. It gets weirder. Fixed the pg_inherits problem, went back to my Zoping, trying to optimize some views, and during another run, get an error that trelclasspq, one of my tables, couldn't open. Trying this out in psql, I get the same error message--the file doesn't exist. And, getting the oid for the file, looked in the directory--and this file is gone too! Now, I just made a good dump of the database, so I can always go back to that. But this seems to be a *serious* problem in the system. I have Zope 2.3.1b2 (most recent version of Zope) running on a Linux-Mandrake 7.2 box (server #1) It has a database adapter called ZPoPy, which is the Zope version of PoPy, a Python database adapter for PostgreSQL. PoPy is getting data from my PostgreSQL database, which is 7.1beta4, and served on a different Mandrake 7.2 box. Has anyone seen anything like this? I doubt the error is Zope *per se*, since Zope can only talk to the database adapter, and I doubt the database adapter has the intentional feature of delete-the-file-for-this-table in its protocol. It *could* be a problem w/ZPoPy or PoPy; I'll send a message to their list as well. Thanks! -- Joel Burton <[EMAIL PROTECTED]> Director of Information Systems, Support Center of Washington ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] Beta 6 Regression results on Redat 7.0.
>> I think the problem is that BufferSync unconditionally does PinBuffer >> on each buffer, and holds the pin during intervals where it's released >> BufMgrLock, even if there's not really anything for it to do on that >> buffer. If someone else is running FlushRelationBuffers then it's >> possible for that routine to see a nonzero pin count when it looks. Further note: this bug does not arise in 7.0.* because in that code, BufferSync will only pin buffers that have been dirtied in the current transaction. This cannot affect a concurrent FlushRelationBuffers, which should be holding exclusive lock on the table it's flushing. Or can it? The above is safe enough for user tables, but on system tables we have a bad habit of releasing locks early. It seems possible that a VACUUM on a system table might see pins due to BufferSyncs running in concurrent transactions that have altered that system table. Perhaps this issue does explain some of the reports of FlushRelationBuffers failure that we've seen from the field. regards, tom lane ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[HACKERS] Re: Beta 6 Regression results on Redat 7.0.
> Seeing that RC1 is in prep, is there a pressing need to upload and release beta > 6 RPM's, or will it be a day or two before RC1? Can I get the src rpm to give a try on Mandrake? I had trouble with 7.0.3 (a mysterious disappearing file in the perl build) and would like to see where we are at with 7.1... - Thomas ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[HACKERS] Re: Final Call: RC1 about to go out the door ...
Thomas Lockhart <[EMAIL PROTECTED]> writes: >> HPUX 10.20 (HP-PA architecture) > Time to drop 9.2 from the list? I don't have it running here anymore. Is there anyone on the list who can test on HPUX 9? >> Linux/PPC (LinuxPPC 2000 Q4 distro tested here; 2.2.18 kernel I think) > What processor? Tatsuo had tested on a 603... It's a Powerbook G3 (FireWire model), but I'm not sure which chip is inside (and Apple's spec sheet isn't too helpful)... regards, tom lane ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] pg_inherits: not found, but visible [IT GETS WORSE]
On Tue, Mar 20, 2001 at 08:03:16PM -0500, Joel Burton wrote: > > Yikes. It gets weirder. > > > I have > > Zope 2.3.1b2 (most recent version of Zope) > running on a Linux-Mandrake 7.2 box (server #1) > What kind of filesystem is the pgsql data tree living on? If you do a fsck, does anything turn up in lost+found? Ross ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
[HACKERS] Re: Final Call: RC1 about to go out the door ...
> >> Linux/PPC (LinuxPPC 2000 Q4 distro tested here; 2.2.18 kernel I think) > > > What processor? Tatsuo had tested on a 603... > It's a Powerbook G3 (FireWire model), but I'm not sure which chip is > inside (and Apple's spec sheet isn't too helpful)... >From what I can tell (which isn't much ;) Apple at least calls the processor a "G3". Which accounts for why we can't find another designation. Not sure where it fits into the lineup I *used* to know about (for embedded systems) but I don't care. Will refer to it as a "G3" for now... - Thomas ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
RE: [HACKERS] Beta 6 Regression results on Redat 7.0.
> Further note: this bug does not arise in 7.0.* because in that code, > BufferSync will only pin buffers that have been dirtied in the current > transaction. This cannot affect a concurrent FlushRelationBuffers, > which should be holding exclusive lock on the table it's flushing. > > Or can it? The above is safe enough for user tables, but on system > tables we have a bad habit of releasing locks early. It seems possible > that a VACUUM on a system table might see pins due to BufferSyncs > running in concurrent transactions that have altered that system table. > > Perhaps this issue does explain some of the reports of > FlushRelationBuffers failure that we've seen from the field. Another possible source of this problem (in 7.0.X) is BufferReplace..? Vadim ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] Re: Final Call: RC1 about to go out the door ...
> > >> Linux/PPC (LinuxPPC 2000 Q4 distro tested here; 2.2.18 kernel I think) > > > What processor? Tatsuo had tested on a 603... > > It's a Powerbook G3 (FireWire model), but I'm not sure which chip is > > inside (and Apple's spec sheet isn't too helpful)... > From what I can tell (which isn't much ;) Apple at least calls the > processor a "G3". Which accounts for why we can't find another > designation. Tatsuo, I have a separate listing for "mklinux" for the 7.0 release. Is that distro still valid and unique? Or is there a better way to represent the PPC options under Linux? - Thomas ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] pg_inherits: not found, but visible [IT GETS WORSE]
On Tue, 20 Mar 2001, Ross J. Reedstrom wrote: > What kind of filesystem is the pgsql data tree living on? If you do a fsck, > does anything turn up in lost+found? > > Ross ext2, straight out of the box. It's in /var, which is a separate partition. fscking shows no errors, tells no lies, and nothing appears in lost+found. Thanks, -- Joel Burton <[EMAIL PROTECTED]> Director of Information Systems, Support Center of Washington ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] Re: Beta 6 Regression results on Redat 7.0.
On Tue, 20 Mar 2001, Thomas Lockhart wrote: > > Seeing that RC1 is in prep, is there a pressing need to upload and release beta > > 6 RPM's, or will it be a day or two before RC1? > Can I get the src rpm to give a try on Mandrake? I had trouble with > 7.0.3 (a mysterious disappearing file in the perl build) and would like > to see where we are at with 7.1... Sure. If you want to try out one already up there, pull the beta4 set off the ftp site. I'm on dialup right now -- it will take quite some time to get an src.rpm up for beta 6. Although, it does look like it may be a little bit before RC1, now. I'm at beta6-0.2 right now, with several changes to make in the line, but, I can upload if you can wait a couple of hours (I'm in a rebuild right now for 0.2, which will take 77 minutes or more on this machine, and then I have to scp it over to hub.). Tomorrow morning, if I can get out of the snow-covered driveway and to work, I can upload it much quicker. I'll go ahead and upload the one I'm testing with right now if you'd like. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Re: Final Call: RC1 about to go out the door ...
On Wed, 21 Mar 2001, Thomas Lockhart wrote: > > > >> Linux/PPC (LinuxPPC 2000 Q4 distro tested here; 2.2.18 kernel I think) > > > > What processor? Tatsuo had tested on a 603... > > > It's a Powerbook G3 (FireWire model), but I'm not sure which chip is > > > inside (and Apple's spec sheet isn't too helpful)... > > From what I can tell (which isn't much ;) Apple at least calls the > > processor a "G3". Which accounts for why we can't find another > > designation. > > Tatsuo, I have a separate listing for "mklinux" for the 7.0 release. Is > that distro still valid and unique? Or is there a better way to > represent the PPC options under Linux? mklinux is older Motorola 68k-based systems LinuxPPC is the newer powerPC-based systems -- Dominic J. Eidson "Baruk Khazad! Khazad ai-menu!" - Gimli --- http://www.the-infinite.org/ http://www.the-infinite.org/~dominic/ ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[HACKERS] Re: Beta 6 Regression results on Redat 7.0.
> I'll go ahead and upload the one I'm testing with right now if you'd like. Not necessary, unless (I suppose) that you know the rpm for beta 4 is broken. That vintage CVS tree behaved well enough for me try it out afaicr... - Thomas ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] Re: Final Call: RC1 about to go out the door ...
> mklinux is older Motorola 68k-based systems > LinuxPPC is the newer powerPC-based systems Hmm. I have mklinux listed as being on the 750. My vague recollection is that the distinction is between NuBus and PCI machines (not necessarily in that order), but... I also vaguely recalled that the distros had merged (or something :/ - Thomas ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[HACKERS] Call for platforms
OK, here is my current platform list taken from the -hackers list and from Vince's web page. I'm sure I've missed at least a few reports, but please confirm that platforms are actually running and passing regression tests with recent betas or the latest release candidate. If a platform you are running on is not listed, make sure it gets included! Platforms with reports for 7.0 risk being demoted to the "used to be supported list", and platforms with reports for only 6.5 are on a deathwatch, so be sure to speak up! Also, I've included names below to remind us who helped last time, but feel free to report even if your name is not already listed. I've separated out recent reports and put them at the end of the list. Thanks in advance. - Thomas AIX 4.3.2 RS6000 7.0 2000-04-05, Andreas Zeugswetter Compaq Tru64 5.0 Alpha 7.0 2000-04-11, Andrew McMurry IRIX 6.5.6f MIPS 6.5.3 2000-02-18, Kevin Wheatley Linux 2.2.x armv4l 7.0 2000-04-17, Mark Knox Linux 2.0.x MIPS 7.0 2000-04-13, Tatsuo Ishii mklinux PPC750 7.0 2000-04-13, Tatsuo Ishii NetBSD 1.4 arm32 7.0 2000-04-08, Patrick Welche NetBSD 1.4U x867.0 2000-03-26, Patrick Welche NetBSD m68k7.0 2000-04-10, Henry B. Hotz NetBSD Sparc 7.0 2000-04-13, Tom I. Helbekkmo QNX 4.25 x86 7.0 2000-04-01, Dr. Andreas Kardos SCO OpenServer 5 x86 6.5 1999-05-25, Andrew Merrill Solaris x867.0 2000-04-12, Marc Fournier Solaris 2.5.1-2.7 Sparc 7.0 2000-04-12, Peter Eisentraut SunOS 4.1.4 Sparc 7.0 2000-04-13, Tatsuo Ishii Windows/Win32 x86 7.0 2000-04-02, Magnus Hagander (clients only) WinNT/Cygwin x86 7.0 2000-03-30, Daniel Horak BeOS 5.0.3 x86 7.1 2000-12-18, Cyril Velter BSDI 4.01 x86 7.1 2001-03-19, Bruce Momjian FreeBSD 4.2 x867.1 2001-03-19, Vince Vielhaber HPUX 10.20 PA-RISC 7.1 2001-03-19, Tom Lane IBMS/390 7.1 2000-11-17, Neale Ferguson Linux 2.2.x Alpha 7.1 2001-01-23, Ryan Kirkpatrick Linux 2.2.16 x86 7.1 2001-03-19, Thomas Lockhart Linux 2.2.15 Sparc 7.1 2001-01-30, Ryan Kirkpatrick LinuxPPC G37.1 2001-03-19, Tom Lane SCO UnixWare 7.1.1 x86 7.1 2001-03-19, Larry Rosenman MacOS-X Darwin PowerPC 7.1 2000-12-11, Peter Bierman ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Call for platforms
* Thomas Lockhart <[EMAIL PROTECTED]> [010320 20:04]: > OK, here is my current platform list taken from the -hackers list and > from Vince's web page. I'm sure I've missed at least a few reports, but > please confirm that platforms are actually running and passing > regression tests with recent betas or the latest release candidate. > > If a platform you are running on is not listed, make sure it gets > included! Platforms with reports for 7.0 risk being demoted to the "used > to be supported list", and platforms with reports for only 6.5 are on a > deathwatch, so be sure to speak up! Also, I've included names below to > remind us who helped last time, but feel free to report even if your > name is not already listed. FreeBSD 4.3-BETA (will be -RELEASE by the time we release) works too. I reported FreeBSD 4.[23]. LER > > I've separated out recent reports and put them at the end of the list. > Thanks in advance. > >- Thomas > > AIX 4.3.2 RS6000 7.0 2000-04-05, Andreas Zeugswetter > Compaq Tru64 5.0 Alpha 7.0 2000-04-11, Andrew McMurry > IRIX 6.5.6f MIPS 6.5.3 2000-02-18, Kevin Wheatley > Linux 2.2.x armv4l 7.0 2000-04-17, Mark Knox > Linux 2.0.x MIPS 7.0 2000-04-13, Tatsuo Ishii > mklinux PPC750 7.0 2000-04-13, Tatsuo Ishii > NetBSD 1.4 arm32 7.0 2000-04-08, Patrick Welche > NetBSD 1.4U x867.0 2000-03-26, Patrick Welche > NetBSD m68k7.0 2000-04-10, Henry B. Hotz > NetBSD Sparc 7.0 2000-04-13, Tom I. Helbekkmo > QNX 4.25 x86 7.0 2000-04-01, Dr. Andreas Kardos > SCO OpenServer 5 x86 6.5 1999-05-25, Andrew Merrill > Solaris x867.0 2000-04-12, Marc Fournier > Solaris 2.5.1-2.7 Sparc 7.0 2000-04-12, Peter Eisentraut > SunOS 4.1.4 Sparc 7.0 2000-04-13, Tatsuo Ishii > Windows/Win32 x86 7.0 2000-04-02, Magnus Hagander (clients only) > WinNT/Cygwin x86 7.0 2000-03-30, Daniel Horak > > BeOS 5.0.3 x86 7.1 2000-12-18, Cyril Velter > BSDI 4.01 x86 7.1 2001-03-19, Bruce Momjian > FreeBSD 4.2 x867.1 2001-03-19, Vince Vielhaber > HPUX 10.20 PA-RISC 7.1 2001-03-19, Tom Lane > IBMS/390 7.1 2000-11-17, Neale Ferguson > Linux 2.2.x Alpha 7.1 2001-01-23, Ryan Kirkpatrick > Linux 2.2.16 x86 7.1 2001-03-19, Thomas Lockhart > Linux 2.2.15 Sparc 7.1 2001-01-30, Ryan Kirkpatrick > LinuxPPC G37.1 2001-03-19, Tom Lane > SCO UnixWare 7.1.1 x86 7.1 2001-03-19, Larry Rosenman > MacOS-X Darwin PowerPC 7.1 2000-12-11, Peter Bierman > > ---(end of broadcast)--- > TIP 5: Have you checked our extensive FAQ? > > http://www.postgresql.org/users-lounge/docs/faq.html -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] Re: Beta 6 Regression results on Redat 7.0.
On Tue, 20 Mar 2001, Thomas Lockhart wrote: > > I'll go ahead and upload the one I'm testing with right now if you'd like. > Not necessary, unless (I suppose) that you know the rpm for beta 4 is > broken. That vintage CVS tree behaved well enough for me try it out > afaicr... It's a good start to test with for the purposes for which I think you want to test for. (and I'm an English teacher by night -- argh). Beta 6 changes a few minor things and one major thing -- the minor things are: - Separate libs package with requisite dependency redo - Change in the initscript to use pg_ctl to (properly) stop postmaster (no kill -9's here this time :-)) - Change in the initscript to initdb with LC_ALL=C and to start postmaster with LC_ALL=C as well. - devel subpackage now uses make install-all-headers instead of cpp hack to pull in required headers for client and server development. The major thing is going to be a build of the contrib tree and a contrib subpackage -- the source will remain as part of the docs, but now that whole set of useful files will be built out. That is what I was beginning to do when I stumbled across the regression failure that subsequently took the rest of the afternoon to track. Before final release I have a rewrite of the README to do, as well as a full update of the migration scripts for testing. I'm looking at /usr/lib/pgsql/contrib/* for the contrib stuff. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] More on elog and error codes
At 09:43 21/03/01 +1100, Philip Warner wrote: > >Code SQL Text >PGERR_TYPALREXI 02xxx "type %s cannot be created because it already exists" >PGERR_FUNCNOTYPE 02xxx "type %s used as argument %d of function %s doesn't >exist" > Peter, Just to clarify, because in a previous email you seemed to believe that I wanted 'PGERR_TYPALREXI' to resolve to a string. I have no such desire; a meaningful number is fine, but we should never have to type it. One possibility is that it is the address of an error-info function (built by 'compiling' the message file). Another possibility is that it could be a prefix to several external symbols, PGERR_TYPALREXI_msg, PGERR_TYPALREXI_code, PGERR_TYPALREXI_num, PGERR_TYPALREXI_sqlcode etc, which are again built by compiling the message file. We can then encode whatever we like into the message, have flexible text, and ease of use for developers. Hope this clarifies things... Philip Warner| __---_ Albatross Consulting Pty. Ltd. |/ - \ (A.B.N. 75 008 659 498) | /(@) __---_ Tel: (+61) 0500 83 82 81 | _ \ Fax: (+61) 0500 83 82 82 | ___ | Http://www.rhyme.com.au |/ \| |---- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/ ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[HACKERS] Re: Call for platforms
> SCO OpenServer 5 x86... OK, I see that Billy Allie recently updated FAQ_SCO to indicate demonstrated (?) support for OpenServer. I will reflect that in the platform support info. - Thomas ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] Re: PostgreSQL JDBC Unicode Support
[Cced: to PostgreSQL hackers list] Alexander, I believe this problem was fixed in the latest JDBC driver, that is supposed to be shipped with 7.1. It asks your database which encoding is used for particular database while connecting to the database. So you should be able to see "select getdatabaseencoding" if you turn on a debugging option for postmaster. I also think the latest driver is compatible with 7.0.3, but I'm not sure. Peter T? -- Tatsuo Ishii From: "Alexander Vaysman" <[EMAIL PROTECTED]> Subject: PostgreSQL JDBC Unicode Support Date: Thu, 15 Mar 2001 15:34:43 -0500 Message-ID: <[EMAIL PROTECTED]> > Tatsuo, > > my name is Alex Vaysman, and I saw your numerous posts in the newsgroups > regarding Postgres and mutli-language support. I have a problem with our > Postgres database, and intensive searches on the Internet/newsgroups didn't > provide me with an answer. I was wondering if you would know the answer or > point me towards it. > > In the nutshell, we are trying to get Postgres DB running that supports > Unicode and interacts with clients via JDBC. We have PostgreSQL version > 7.0.3 installed. I have downloaded the latest JDBC driver from > http://jdbc.postgresql.org. > > I have created a Unicode database (confirmed through \l command in psql, > reported encoding is 'UNICODE'). In that DB I've created a table with two > fields integer and varchar(64). Then I store a record into this table. In my > code I specify the string through Unicode escapes. After that I retrieve > this value and write it out. I don't get my value back but rather ?. I'm > attaching the code I use for reference. > > My Internet searches for the solution indicated that I need to apply some > patches to JDBC driver. However, I don't know how to do that. Do you know > where I may download the JDBC driver version with the appropriate patches > applied? If you're using one, would you be kind enough and e-mail it to me. > Also, having some experience with SQL Server, I know that if I wanted to > store Unicode values into some column I was creating that column as nvarchar > rather the varchar. Is anything like this required for Postgres? > > Your help is greatly appreciated. Thanks in advance, > > Alex Vaysman. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] Re: Final Call: RC1 about to go out the door ...
> Tatsuo, I have a separate listing for "mklinux" for the 7.0 release. Is > that distro still valid and unique? Or is there a better way to > represent the PPC options under Linux? I think MkLinux is completely different from Linux/PPC. Will test RC1 on my MkLiux box soon... -- Tatsuo Ishii ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[HACKERS] RPM building (was regression on RedHat)
> It's a good start to test with for the purposes for which I think you want to > test for. (and I'm an English teacher by night -- argh). :) Mandrake (as of 7.2) still does a brain-dead mix of "-O3" and "-ffast-math", which is a risky and unnecessary combination according to the gcc folks (and which kills some of our date/time rounding). From the man page for gcc: -ffast-math This option should never be turned on by any `-O' option since it can result in incorrect output for programs which depend on an exact implementation of IEEE or ANSI rules/specifications for math functions. I'd like to get away from having to post a non-brain-dead /root/.rpmrc file which omits the -ffast-math flag. Can you suggest mechanisms for putting a "-fno-fast-math" into the spec file? Isn't there a mechanism to mark things as "distro specific"? Suggestions? Also, I'm getting the same symptom as I had for 7.0.3 with a "disappearing file". Anyone seen this? I recall tracing this back for the 7.0.3 case and found that Pg.bs existed in the build tree, at least at some point in the build, but then goes away. 7.0.2, at least at the time I did the build, did not have the problem :( File not found: /var/tmp/postgresql-7.1beta4-root/ (cont'd) usr/lib/perl5/site_perl/5.6.0/i386-linux/auto/Pg/Pg.bs - Thomas ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] Re: Final Call: RC1 about to go out the door ...
> > Tatsuo, I have a separate listing for "mklinux" for the 7.0 release. Is > > that distro still valid and unique? Or is there a better way to > > represent the PPC options under Linux? > > mklinux is older Motorola 68k-based systems No. MkLinux runs on Power PC based system also. I believe there is a x86 based MkLinux exists somewhere. -- Tatsuo Ishii ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] Re: More on elog and error codes
> Creating central message files/objects has the added advantage of a much > simpler locale support - they're just resource files, and they're NOT > embedded throughout the code. > Finally, if you do want to have some kind of error classification beyond > the SQL code, it could be encoded in the error message file. We could also (automatically) build a DBMS reference table *from* this message file (or files), which would allow lookup of messages from codes for applications which are not "message-aware". Not a requirement, and it does not meet all needs (e.g. you would have to be connected to get the messages in that case) but it would be helpful for some use cases... - Thomas ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] Re: More on elog and error codes
At 03:28 21/03/01 +, Thomas Lockhart wrote: >> Creating central message files/objects has the added advantage of a much >> simpler locale support - they're just resource files, and they're NOT >> embedded throughout the code. >> Finally, if you do want to have some kind of error classification beyond >> the SQL code, it could be encoded in the error message file. > >We could also (automatically) build a DBMS reference table *from* this >message file (or files), which would allow lookup of messages from codes >for applications which are not "message-aware". > >Not a requirement, and it does not meet all needs (e.g. you would have >to be connected to get the messages in that case) but it would be >helpful for some use cases... If we extended the message definitions to have (optional) description & user-resolution sections, then we have the possibilty of asking psql to explain the last error, and (broadly) how to fix it. Of course, in the first pass, these would all be empty. Philip Warner| __---_ Albatross Consulting Pty. Ltd. |/ - \ (A.B.N. 75 008 659 498) | /(@) __---_ Tel: (+61) 0500 83 82 81 | _ \ Fax: (+61) 0500 83 82 82 | ___ | Http://www.rhyme.com.au |/ \| |---- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/ ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Re: Final Call: RC1 about to go out the door ...
On Wed, 21 Mar 2001, Thomas Lockhart wrote: > > > >> Linux/PPC (LinuxPPC 2000 Q4 distro tested here; 2.2.18 kernel I think) > > > > What processor? Tatsuo had tested on a 603... > > > It's a Powerbook G3 (FireWire model), but I'm not sure which chip is > > > inside (and Apple's spec sheet isn't too helpful)... > > From what I can tell (which isn't much ;) Apple at least calls the > > processor a "G3". Which accounts for why we can't find another > > designation. The G3s are the MPC7XX family and the G4s are the MPC7XXX family. All of the ones Mac is currently releasing are MPC7450s. See http://e-www.motorola.com/webapp/sps/prod_cat/taxonomy.jsp?catId=M934309493763 for more details. FWIW. -- Dominic J. Eidson "Baruk Khazad! Khazad ai-menu!" - Gimli --- http://www.the-infinite.org/ http://www.the-infinite.org/~dominic/ ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[HACKERS] Re: RPM building (was regression on RedHat)
At 3/20/2001 09:24 PM, Thomas Lockhart wrote: > > It's a good start to test with for the purposes for which I think you > want to > > test for. (and I'm an English teacher by night -- argh). > >:) > >Mandrake (as of 7.2) still does a brain-dead mix of "-O3" and >"-ffast-math", which is a risky and unnecessary combination according to >the gcc folks (and which kills some of our date/time rounding). From the >man page for gcc: > >-ffast-math > This option should never be turned on by any `-O' option > since it can result in incorrect output for programs which > depend on an exact implementation of IEEE or ANSI > rules/specifications for math functions. > >I'd like to get away from having to post a non-brain-dead /root/.rpmrc >file which omits the -ffast-math flag. Can you suggest mechanisms for >putting a "-fno-fast-math" into the spec file? Isn't there a mechanism >to mark things as "distro specific"? Suggestions? I don't know if it helps. But, a stock install has the environment MACHTYPE=i586-mandrake-linux. If you hunt for mandrake in the MACHTYPE variable you could reset those variables. Also, I think those are set in the rpmrc file of the distro for the i386 target. If you specify anything else like i486, i686, you don't have that problem. It would be in the RPM_OPT_FLAGS or RPM_OPTS part of the build environment. I don't think there would be a problem overriding it, in fact, I would recommend the following : RPM_OPTS="$RPM_OPTS -fno-fast-math". Since gcc will take the last argument as overriding the first, it would be a nice safeguard. Even setting CFLAGS="$CFLAGS -fno-fast-math" might be good idea. Hope this helps, Thomas ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[HACKERS] Question
Hi, I want to ask question: can i write my own concurrency control algorithm and apply it using postgresql? Thanks in advance Manal __ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/ ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
[HACKERS] libpqeasy cursor error after multiple calls
Hi all,
I'm just wondering if this is an error on my part, or a bug. I have the
same trouble with PG 7.1beta6 and PG7.1 snapshot (March 8th) on Solaris
8 INTEL, Solaris 8 SPARC and Linux Mandrake 7.2.
When using the libpqeasy library in a C function, I have the following
section of code :
// Get the sequence number for the next directory entry (PostgreSQL
commands)
doquery("BEGIN WORK");
doquery("DECLARE c_getdirid BINARY CURSOR FOR SELECT
nextval('prescan_directories_idnum_seq'::text)");
doquery("FETCH ALL IN c_getdirid");
fetch(&enumdirstruc_p->presentdirid);
doquery("CLOSE c_getdirid");
doquery("COMMIT WORK");
This is called once per entry in a filesystem (this is a filesystem
scanning utility) but after about 1000 or so calls, it errors out and
won't work again. I have to actually DROP the database and re-create it
again before the code will work again at all. Just vacumming doesn't
help, nor does just shutting down the database and starting it again
(doing both and vacuum and restarting the database doesn't help either).
The error message is :
/archive/install/kde/kdeadmin-2.1/ksysctrl/.cvsignore
NOTICE: PerformPortalFetch: portal "c_getdirid" not found
NOTICE: PerformPortalClose: portal "c_getdirid" not found
Directory query failed, trying again...New directory idnum = -2147483648
(This is my error message from the program)
query error:
failed request: insert into prescan_files(filename, dirent, ownername,
owenerid, groupname, groupid, filesize, os, os_version, package_id)
values ('/archive/install/kde/kdeadmin-2.1/add-on/.cvsignore',
2147483648, 'jclift', 100, 'staff', 10, 21, 1, '8 INTEL', 16777216)
$
I can include the database schema and complete source code if needed,
but I'm just not sure where to start debugging... is it my app or is it
PostgreSQL?
Regards and best wishes,
Justin Clift
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] regression.diff wrong dir name
Hi all, Something minor, but when you do a "make check" from the main source directory and it finishes, it mentions that the regression.diff file is in ./regression.diff It's really at src/test/regress/regression.diff, and although not hard to figure out (it's a carry-over from pre 7.1), it might be confusing to people to new PostgreSQL. Regards and best wishes, Justin Clift ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] pg_inherits: not found, but visible [IT GETS WORSE]
Joel Burton <[EMAIL PROTECTED]> writes: > Yikes. It gets weirder. > Fixed the pg_inherits problem, went back to my Zoping, trying to optimize > some views, and during another run, get an error that trelclasspq, one of > my tables, couldn't open. > Trying this out in psql, I get the same error message--the file doesn't > exist. And, getting the oid for the file, looked in the directory--and > this file is gone too! This does not seem good. Just to clarify: in both cases, the pg_class row for the table is still there, but the underlying Unix file is gone? Barring major malfeasance from your kernel, it seems like Postgres must be issuing a delete on the wrong file when you are doing something else. This is particularly bizarre if you are just doing create/delete view, because in 7.1 a view hasn't got any associated file, and so no unlink() kernel call should be issued at all. I would recommend that you try to narrow down the events leading up to this --- in particular, keeping a postmaster log of queries issued (-d2) seems like a good idea. > I doubt the error is Zope *per se*, Zope cannot be the culprit --- there is no API for deleting a table file without deleting its pg_class entry ;-). But it seems possible that some peculiar pattern of queries that they issue could be triggering a previously-unknown Postgres bug. I will be out of town all day tomorrow, but please see what data you can gather. If you can create a reproducible failure case it'd be great... regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] libpqeasy cursor error after multiple calls
I am kind of stumped. Glad to see _someone_ is using libpgeasy. :-)
I would be glad to run tests here if you can shoot over the code.
> Hi all,
>
> I'm just wondering if this is an error on my part, or a bug. I have the
> same trouble with PG 7.1beta6 and PG7.1 snapshot (March 8th) on Solaris
> 8 INTEL, Solaris 8 SPARC and Linux Mandrake 7.2.
>
> When using the libpqeasy library in a C function, I have the following
> section of code :
>
> // Get the sequence number for the next directory entry (PostgreSQL
> commands)
> doquery("BEGIN WORK");
> doquery("DECLARE c_getdirid BINARY CURSOR FOR SELECT
> nextval('prescan_directories_idnum_seq'::text)");
> doquery("FETCH ALL IN c_getdirid");
> fetch(&enumdirstruc_p->presentdirid);
> doquery("CLOSE c_getdirid");
> doquery("COMMIT WORK");
>
> This is called once per entry in a filesystem (this is a filesystem
> scanning utility) but after about 1000 or so calls, it errors out and
> won't work again. I have to actually DROP the database and re-create it
> again before the code will work again at all. Just vacumming doesn't
> help, nor does just shutting down the database and starting it again
> (doing both and vacuum and restarting the database doesn't help either).
>
> The error message is :
>
>
> /archive/install/kde/kdeadmin-2.1/ksysctrl/.cvsignore
> NOTICE: PerformPortalFetch: portal "c_getdirid" not found
> NOTICE: PerformPortalClose: portal "c_getdirid" not found
> Directory query failed, trying again...New directory idnum = -2147483648
> (This is my error message from the program)
> query error:
> failed request: insert into prescan_files(filename, dirent, ownername,
> owenerid, groupname, groupid, filesize, os, os_version, package_id)
> values ('/archive/install/kde/kdeadmin-2.1/add-on/.cvsignore',
> 2147483648, 'jclift', 100, 'staff', 10, 21, 1, '8 INTEL', 16777216)
> $
>
> I can include the database schema and complete source code if needed,
> but I'm just not sure where to start debugging... is it my app or is it
> PostgreSQL?
>
> Regards and best wishes,
>
> Justin Clift
>
> ---(end of broadcast)---
> TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
>
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup.| Drexel Hill, Pennsylvania 19026
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[HACKERS] PostgreSQL-JDBC driver
-
Hi,
I am trying to access PostGreSQL database running at the default port
5432
using JDBC. But the application is giving error "Cannot find suitable
driver". I have included JDBC driver JAR file in my CLASSPATH and
Class.forName("org.postgresql.Driver") is loading driver successfully.
Can anybody tell me how to go about to solve the problem?
With regards,
Sourabh
> ---(end of broadcast)---
> TIP 5: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/users-lounge/docs/faq.html
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://www.postgresql.org/search.mpl
Re: [HACKERS] Call for platforms
> mklinux PPC750 7.0 2000-04-13, Tatsuo Ishii I got core dump while running the parallel regression test of beta6. Will look at... -- Tatsuo Ishii ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
