Re: [HACKERS] custom guc vars
[2005-05-01 18:38] Andrew Dunstan said:
|
| Is there a readme somewhere on how modules are supposed to use custom
| GUC variables? If there is I have missed it.
I don't think there is any documentation for this, but here's a
simple overview.
cheers.
Brent
=== postgresql.conf ===
custom_variable_classes = 'mymodule, anothermodule'
mymodule.integer = 10
mymodule.double = 5.5
mymodule.string = 'some string'
mymodule.bool = true
anothermodule.whatever = 'some string'
anothermodule.other = false
=== moduleConfig.c ===
#include utils/guc.h
int anIntVar;
char* aStringVar;
double aDoubleVar;
bool aBoolVar;
void setCustomVars()
{
DefineCustomIntegerVariable(
mymodule.integer,
A custom integer guc var,
NULL,
anIntVar,
PGC_USERSET,
NULL,NULL);
DefineCustomStringVariable(
mymodule.string,
A custom string guc var,
NULL,
aStringVar,
PGC_USERSET,
NULL,NULL);
DefineCustomRealVariable(
mymodule.double,
A custom double guc var,
NULL,
aDoubleVar,
PGC_USERSET,
NULL,NULL);
DefineCustomBoolVariable(
mymodule.bool,
A custom bool guc var,
NULL,
aBoolVar,
PGC_USERSET,
NULL,NULL);
}
---(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] [proposal] protocol extension to support loadable stream filters
[2005-04-28 10:00] Tom Lane said: | Brent Verner [EMAIL PROTECTED] writes: |Would it be sane to recognize a specific PG_PROTOCOL_MAJOR | to enter the filter-negotiation process? PG_PROTOCOL_MINOR | would then be used to lookup and call a ptr to the filter's | create() in CreateStreamFilter... | | Looks reasonable enough to me ... Now, the hard part...where should this code live? I'm thinking a src/transport directory seems sensible. StreamFilter.[ch] will contain the base StreamFilter along with various utility functions. StreamFilter implementations will reside in their own subdir. src/include/transport/StreamFilter.h src/transport/StreamFilter.c src/transport/zlib/... src/transport/ssl/... Comments/ideas appreciated. cheers. b ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] [proposal] protocol extension to support loadable stream filters
[2005-04-26 23:00] Tom Lane said: | Brent Verner [EMAIL PROTECTED] writes: | | I also wonder what happens when | | the client and server disagree on the meaning of a filter name. | |How this is any different than saying ...when the client and | server disagree on the meaning of a ProtocolVersion., which is | how ssl support is currently requested/negotiated? | | Nonsense. The ProtocolVersion stuff is documented, fixed, and the same | for every Postgres installation that understands a given version at all. Gotcha. Certainly, that is true of clients using libpq. I was thinking of client libraries that (re)implement the protocol instead of using libpq. In particular, the jdbc driver has its own idea of what must be done to setup a connection with the NEGOTIATE_SSL_CODE ProtocolVersion. | What you are proposing is an installation-dependent meaning of protocol | (because the meaning of any particular filter name is not standardized). In a way, yes, I would like the capabilities of the protocol to be installation-dependent. I'd like to be able to use a custom/local filter without having to modify and rebuild my PG installation. The use of named filters and dynamic loading was the only way I could see to accomplish that. |What am I overlooking? | | Cost/benefit. You have yet to offer even one reason why destandardizing | the protocol is a win. That one could provide a new filter implementation w/o modifying the internals of PG is the only benefit. If there's another way to do this w/o dynamic loading I'd love to hear it. | I am also pretty concerned about the security risks involved. AFAICS | what you are proposing is that a user who hasn't even authenticated yet, | let alone proven himself to be a superuser, can ask the server to load | in code of uncertain provenance. The downsides of this are potentially | enormous, and the upsides are ... well ... you didn't actually offer any. Correct, the use of a filter is not limited to/by user. The admin would have to enable a filter, which would then be available (or even required) for any connection. The certainty of provenance seems to be the same as that for a dynamically loaded PL. | The stream-filter part is not a bad idea: that would definitely make it | easier to incorporate new capabilities into the standard protocol. | What I'm complaining about is the dynamic-loading part, and the | installation-dependent behavior. I see no real advantage to either of | those aspects, and lots of risks. I'll rethink things w/o support for dynamic loading and installation- dependent behaviour then send an updated proposal. cheers. Brent ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [proposal] protocol extension to support loadable stream filters
[2005-04-25 18:34] Tom Lane said: | Brent Verner [EMAIL PROTECTED] writes: |I'd like to introduce the concept of (dynamically loaded) stream | filters that would be used to wrap calls to send/recv by the FE/BE | protocol. | You certainly don't get to have any help | from the database, for example, since you're not connected to it | at the time of the connection startup. Right. The list of available filters would controlled at the server level (in postgresql.conf). A snippet of how I envision configuring the filters...at the moment, anyway. I suspect my use of custom_variable_classes might be better done as a specific enable_stream_filters option, but this is what I'm currently working with... # # Define a custom_variable_class for each filter. A filter, # $filterName, will be available iff $filterName.enable == true # custom_variable_classes = 'ssl, zlib, ...' # see documentation of ssl filter for available options ssl.enable = true ssl.required = false # see documentation of zlib filter for available options zlib.enable = true zlib.required = true zlib.compression = 7 | I also wonder what happens when | the client and server disagree on the meaning of a filter name. How this is any different than saying ...when the client and server disagree on the meaning of a ProtocolVersion., which is how ssl support is currently requested/negotiated? Either way, client and server must agree on their behaviour. This doesn't change, AFAICS, when requesting support for some feature/filter by name. If the filter exists, an attempt will be made to communicate through it, if that fails, the filter is not installed, and the client ends up with a 'no support' response (or a disconnect if the filter is required) and the client goes on without it. What am I overlooking? | It | would seem a lot safer to stick to the existing, low-tech, non dynamic | approach. I still don't see what additional problems would be created by using this StreamFilter API, so I'm going to march on and perhaps the problems/difficulties will become apparent ;-) I could see the benefit in having some built-in StreamFilters, such as SSL (or zlib ;-)) that can't be replaced/overridden by dlopen'd code, but I think having the ability to provide alternate stream handling might be useful. cheers. brent ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Edge case problem with pg_dump
[2002-05-23 10:51] Tom Lane said: | D'Arcy J.M. Cain [EMAIL PROTECTED] writes: | So who was it that wanted to make this change. Perhaps I can help. | | I forget who had volunteered to work on it, but it was several months | ago and nothing's happened ... I'd be the disappearing culprit... This patch _was_ mostly done at one point around 7.2 released, infact I've been running the patch on three production installs. I'll take a look at making the patch current and resubmitting. cheers. b -- Develop your talent, man, and leave the world something. Records are really gifts from people. To think that an artist would love you enough to share his music with anyone is a beautiful thing. -- Duane Allman ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] [patch] helps fe-connect.c handle -EINTR more gracefully
On 25 Oct 2001 at 17:08 (-0400), David Ford wrote:
| I'm fresh in the code, but this has solved my issues with PQconnect*
| failing when interrupted by signals. Some of it is sloppy and not to my
| liking yet, but I'm still digging through to see if anything else needs
| touched. Comments appreciated.
Disclaimer: I may be wrong as hell ;-), but...
I'm not sure this is correct. I've tried to /make/ a SIGALRM cause
connect to errno==EINTR, but I can't cause this condition. I suspect
you have another signal being raised that is causing your symptom.
FTR, the textbook definition[1] of EINTR error for connect is:
The attempt to establish a connection was interrupted by delivery
of a signal that was caught; the connection will be established
asynchronously.
Please check the attached prog to see if it is representative of your
code relating to the connect error you're seeing. If it is, please
run it and see if you can get it to cause the EINTR error from connect.
If you can't I'm more certain that you have a problem elsewhere.
cheers.
brent
1. http://www.opengroup.org/onlinepubs/7908799/xns/connect.html
--
Develop your talent, man, and leave the world something. Records are
really gifts from people. To think that an artist would love you enough
to share his music with anyone is a beautiful thing. -- Duane Allman
#include sys/types.h
#include sys/socket.h
#include unistd.h
#include signal.h
#include netdb.h
#include netinet/in.h
#include sys/time.h
#include errno.h
#include fcntl.h
static int AT = 5; /* usecs for _ualarm to */
int nonblocking(int fd){
int fb = fcntl(fd, F_GETFL, 0);
if (fb == -1)
return -1;
return fcntl(fd, F_SETFL, fb|O_NONBLOCK);
}
void sigalrm(int arg){
ualarm(AT,0);
}
int try_connect(){
int s,c;
struct sockaddr_in serv;
memset(serv,0,sizeof(serv));
s = socket(PF_INET,SOCK_STREAM,6);
nonblocking(s);
serv.sin_family = AF_INET;
serv.sin_port = htons(80);
inet_aton(127.0.0.1,(struct in_addr*)serv.sin_addr);
c = connect(s,(struct sockaddr*)serv,sizeof(serv));
if( c 0 errno == EINTR )
perror(connect (EINTR):); // this is
return c;
}
int main( int argc, char** argv ){
signal(SIGALRM,sigalrm);
ualarm(AT,0);
while(1){
try_connect();
if( errno == EBADF ){
break;
}
sleep(100); // this sleep never really sleeps 100 secs.
}
puts(ran out of file descriptors as expected.);
return 0;
}
---(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] [patch] helps fe-connect.c handle -EINTR more gracefully
On 26 Oct 2001 at 00:05 (-0400), Tom Lane wrote: | Brent Verner [EMAIL PROTECTED] writes: | I'm not sure this is correct. I've tried to /make/ a SIGALRM cause | connect to errno==EINTR, but I can't cause this condition. | | It wouldn't surprise me in the least if this behavior is | platform-dependent. It may well be that David's kernel will allow | connect() to be interrupted by SIGALRM while yours won't. (Which | reminds me that neither of you specified what platforms you were | testing on. For shame.) Or maybe the difference depends on whether | you are trying to connect to a local or remote server. sorry, I tested the attached prog on linux(2.2/2.4) and freebsd(4.4R) to both local and remote(slow) servers. | Unless someone can point out a situation where retrying connect() | after EINTR is actively bad, my inclination is to accept the patch. | It seems like a net improvement in robustness to me, with no evident | downside other than a line or two more code. I've found numerous examples where connect() is retried after EINTR, infact it appears to be fairly common. cheers, brent -- Develop your talent, man, and leave the world something. Records are really gifts from people. To think that an artist would love you enough to share his music with anyone is a beautiful thing. -- Duane Allman ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] FAQ error
On 10 Oct 2001 at 17:12 (-0400), Bruce Momjian wrote:
|
| Our FAQ, item 4.16.2 has:
|
| $newSerialID = nextval('person_id_seq');
| INSERT INTO person (id, name) VALUES ($newSerialID, 'Blaise Pascal');
|
| Is this correct Perl? I don't see a nextval() function in Perl. Can
| you call SQL server-side functions natively from Perl?
no. The proper perl code would be more like...
use DBI;
my ($lastid,$nextid,$sql,$rv);
my $dbh = DBI-connect(perldoc DBD::Pg);
# to use the nextval
$sql = SELECT nextval('person_id_seq');
$nextid = ($dbh-selectrow_array($sql))[0];
$sql = INSERT INTO person (id, name) VALUES ($nextid, 'Blaise Pascal');
$rv = $dbh-do($sql);
# or to get the currval
$sql = INSERT INTO person (name) VALUES ('Blaise Pascal');
$rv = $dbh-do($sql);
$sql = SELECT currval('person_id_seq');
$lastid = ($dbh-selectrow_array($sql))[0];
| --
| 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://archives.postgresql.org
--
Develop your talent, man, and leave the world something. Records are
really gifts from people. To think that an artist would love you enough
to share his music with anyone is a beautiful thing. -- Duane Allman
---(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] ALTER RENAME and indexes
On 07 Oct 2001 at 04:03 (-0700), Stephan Szabo wrote: | | On Sat, 6 Oct 2001, Brent Verner wrote: | | On 06 Oct 2001 at 20:13 (-0400), Rod Taylor wrote: | | Of course, in 7.1 foreign key constraints become rather confused when | | you rename columns on them. | 1) modify this tgargs value to reflect the modified column name(s). | 2) modify whatever uses these args to use the oid instead of | the column names, and modify CreateTrigger to reflect this change.. | | #2 seems to be the most bulletproof approach, so I'm looking | into hacking this up right now. Any comments would be much | appreciated about any (better) ways to fix this problem. | | #2 also requires changes to dump/restore stuff, since AFAIK | it currently dumps create constraint trigger statements and the | oids won't be known for the restore, but this is probably a good | idea in general. After looking this over for a couple of hours and seeing how many places would have to be touched, combined with the pg_dump breakage makes #2 an unreasonable task for me to complete before real life stops my party. Plus, being this close to beta, this fix/hack might actually get into 7.2, since it will be a really minor addition to rename.c. Thanks for alerting me to pg_dump's dependency on this stuff :-). cheers. Brent -- Develop your talent, man, and leave the world something. Records are really gifts from people. To think that an artist would love you enough to share his music with anyone is a beautiful thing. -- Duane Allman ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] ALTER RENAME and indexes
On 05 Oct 2001 at 10:18 (-0400), Brent Verner wrote: | On 05 Oct 2001 at 09:46 (-0400), Tom Lane wrote: | | Brent Verner [EMAIL PROTECTED] writes: | | 'ALTER TABLE tbl RENAME col1 TO col2' does not update any indices that | | reference the old column name. | | | | It doesn't need to; the indexes link to column numbers, not column | | names. ah, I think I see the problem... The pg_attribute.attname just needs updating, right? I suspect this after noticing that the pg_get_indexdef(Oid) function produced the correct(expected) results, while those using pg_attribute were wrong. If this is the _wrong_ answer for this, stop me before I make a big mess :-) working... b -- Develop your talent, man, and leave the world something. Records are really gifts from people. To think that an artist would love you enough to share his music with anyone is a beautiful thing. -- Duane Allman ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] [patch] ALTER RENAME and indexes
The attached patch works for my case...
regression=# create table test (id serial, col1 varchar(64));
NOTICE: CREATE TABLE will create implicit sequence 'test_id_seq' for SERIAL column
'test.id'
NOTICE: CREATE TABLE/UNIQUE will create implicit index 'test_id_key' for table 'test'
CREATE
regression=# create index i_t_c on test(col1);
CREATE
regression=# alter table test rename col1 to col2;
ALTER
regression=# \d test
Table test
Column | Type |Modifiers
+---+-
id | integer | not null default nextval('test_id_seq'::text)
col2 | character varying(64) |
Indexes: i_t_c
Unique keys: test_id_key
regression=# \d itc
Did not find any relation named itc.
regression=# \d i_t_c
Index i_t_c
Column | Type
+---
col2 | character varying(64)
btree
wooohoo!!! Of course, it would be best if someone else looked this
code over, because I get the feeling there is an easier way to get
this done. The only thing I can say is that it solves my problem
and does not /appear/ to create any others.
cheers.
Brent
p.s., I appreciate the gurus not jumping in with the quick fix --
The experience has been fun :-)
--
Develop your talent, man, and leave the world something. Records are
really gifts from people. To think that an artist would love you enough
to share his music with anyone is a beautiful thing. -- Duane Allman
Index: src/backend/commands/rename.c
===
RCS file: /projects/cvsroot/pgsql/src/backend/commands/rename.c,v
retrieving revision 1.57
diff -r1.57 rename.c
35a36,37
static void
update_indexed_attnames(Oid indrelid, const char *_old, const char *_new);
169a172,235
update_indexed_attnames(relid,oldattname,newattname);
}
/* man, I want some sql here...
*
* UPDATE pg_attribute
* SET attname='$3'
* WHERE indrelid=$1 AND attname='$2'
*/
static void
update_indexed_attnames(Oid indrelid,
const char *oldattname,
const char *newattname)
{
List *indexoidlist;
List *indexoidscan;
Relation relation;
Relation attrelation;
relation = heap_open(indrelid, AccessShareLock);
indexoidlist = RelationGetIndexList(relation);
attrelation = heap_openr(AttributeRelationName, RowExclusiveLock);
foreach(indexoidscan, indexoidlist)
{
HeapTuple atttup;
Oid indexoid;
indexoid = lfirsti(indexoidscan);
elog(DEBUG,update_indexed_attnames: indexoid: %d, indexoid);
atttup = SearchSysCacheCopy(ATTNAME,
ObjectIdGetDatum(indexoid),
PointerGetDatum(oldattname),
0, 0);
if (!HeapTupleIsValid(atttup)){
elog(DEBUG, update_indexed_attnames: not updating %d.,
indexoid);
}
else{
elog(DEBUG, update_indexed_attnames: updating %d., indexoid);
StrNCpy(NameStr(((Form_pg_attribute) GETSTRUCT(atttup))-attname),
newattname, NAMEDATALEN);
simple_heap_update(attrelation, atttup-t_self, atttup);
/* keep system catalog indices current */
{
Relationirelations[Num_pg_attr_indices];
CatalogOpenIndices(Num_pg_attr_indices, Name_pg_attr_indices,
irelations);
CatalogIndexInsert(irelations, Num_pg_attr_indices, attrelation,
atttup);
CatalogCloseIndices(Num_pg_attr_indices, irelations);
}
heap_freetuple(atttup);
}
}
freeList(indexoidlist);
heap_close(attrelation, RowExclusiveLock);
heap_close(relation, AccessShareLock);
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] ALTER RENAME and indexes
On 06 Oct 2001 at 20:13 (-0400), Rod Taylor wrote: | Of course, in 7.1 foreign key constraints become rather confused when | you rename columns on them. | | create table parent (id serial); | create table child (id int4 references parent(id) on update cascade); | alter table parent rename column id to anotherid; | alter table child rename column id to junk; | insert into child values (1); | | - ERROR: constraint unnamed: table child does now have an | attribute id ok, I see where this breaks. The args to the RI_ConstraintTrigger_%d are written into the pg_trigger tuple like so.. 'unnamed\000child\000parent\000UNSPECIFIED\000id\000id\000' There are really two approaches, AFAICS. 1) modify this tgargs value to reflect the modified column name(s). 2) modify whatever uses these args to use the oid instead of the column names, and modify CreateTrigger to reflect this change.. #2 seems to be the most bulletproof approach, so I'm looking into hacking this up right now. Any comments would be much appreciated about any (better) ways to fix this problem. cheers. Brent -- Develop your talent, man, and leave the world something. Records are really gifts from people. To think that an artist would love you enough to share his music with anyone is a beautiful thing. -- Duane Allman ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] ALTER RENAME and indexes
On 05 Oct 2001 at 09:46 (-0400), Tom Lane wrote:
| Brent Verner [EMAIL PROTECTED] writes:
| 'ALTER TABLE tbl RENAME col1 TO col2' does not update any indices that
| reference the old column name.
|
| It doesn't need to; the indexes link to column numbers, not column
| names.
Forgive my incorrect description of the problem... By example...
brent=# select version();
version
---
PostgreSQL 7.1.3 on i686-pc-linux-gnu, compiled by GCC 2.95.4
(1 row)
brent=# create table test ( id serial, col1 varchar(64) NOT NULL);
NOTICE: CREATE TABLE will create implicit sequence 'test_id_seq' for SERIAL column
'test.id'
NOTICE: CREATE TABLE/UNIQUE will create implicit index 'test_id_key' for table 'test'
CREATE
brent=# create index idx_test_col1 on test(col1);
CREATE
brent=# \d idx_test_col1
Index idx_test_col1
Attribute | Type
---+---
col1 | character varying(64)
btree
brent=# alter table test rename col1 to col2;
ALTER
brent=# \d idx_test_col1
Index idx_test_col1
Attribute | Type
---+---
col1 | character varying(64)
btree
brent=# \d test
Table test
Attribute | Type |Modifier
---+---+-
id| integer | not null default nextval('test_id_seq'::text)
col2 | character varying(64) | not null
Indices: idx_test_col1,
test_id_key
I hit this problem using the jdbc driver, and originally thought
it was the jdbc code, but as the above shows, the problem seems to
be a failure to update one (or more) of the system catalogs.
Again, any pointers beyond look in src/backend/commands/rename.c
would be appreciated. My big question is how is the content of
the system tables used/affected from within PG -- I originally
thought it would be simple enough to issue some SQL to properly
update the system tables, but apparently that idea was /very/ naive.
Is there any way to list all $things that reference the altered
entity? find_all_inheritors() does not /appear/ to be getting
everything that needs to be updated.
Also, a lot of terminology within the code is making my head spin (not
a difficult task ;-)), but then I've only spent about two hours
digging around this code. Is there a 'understanding internal PostgreSQL
terminology' document that I've missed?
thanks.
Brent
--
Develop your talent, man, and leave the world something. Records are
really gifts from people. To think that an artist would love you enough
to share his music with anyone is a beautiful thing. -- Duane Allman
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
[HACKERS] Re: Re: WAL and commit_delay
On 17 Feb 2001 at 15:53 (-0800), Nathan Myers wrote:
| On Sat, Feb 17, 2001 at 06:30:12PM -0500, Brent Verner wrote:
| On 17 Feb 2001 at 17:56 (-0500), Tom Lane wrote:
|
| [snipped]
|
| | Is anyone out there running a 2.4 Linux kernel? Would you try pgbench
| | with current sources, commit_delay=0, -B at least 1024, no -F, and see
| | how the results change when pg_fsync is made to call fdatasync instead
| | of fsync? (It's in src/backend/storage/file/fd.c)
|
| I've not run this requested test, but glibc-2.2 provides this bit
| of code for fdatasync, so it /appears/ to me that kernel version
| will not affect the test case.
|
| [glibc-2.2/sysdeps/generic/fdatasync.c]
|
|int
|fdatasync (int fildes)
|{
|return fsync (fildes);
|}
|
| In the 2.4 kernel it says (fs/buffer.c)
|
|/* this needs further work, at the moment it is identical to fsync() */
|down(inode-i_sem);
|err = file-f_op-fsync(file, dentry);
|up(inode-i_sem);
|
| We can probably expect this to be fixed in an upcoming 2.4.x, i.e.
| well before 2.6.
2.4.0-ac11 already has provisions for fdatasync
[fs/buffer.c]
352 asmlinkage long sys_fsync(unsigned int fd)
353 {
...
372 down(inode-i_sem);
373 filemap_fdatasync(inode-i_mapping);
374 err = file-f_op-fsync(file, dentry, 0);
375 filemap_fdatawait(inode-i_mapping);
376 up(inode-i_sem);
384 asmlinkage long sys_fdatasync(unsigned int fd)
385 {
...
403 down(inode-i_sem);
404 filemap_fdatasync(inode-i_mapping);
405 err = file-f_op-fsync(file, dentry, 1);
406 filemap_fdatawait(inode-i_mapping);
407 up(inode-i_sem);
ext2 does use this third param of its fsync() operation to (potentially)
bypass a call to ext2_sync_inode(inode)
b
[HACKERS] Re: preproc.y error
On 07 Feb 2001 at 20:15 (-0500), Tom Lane wrote: | Vince Vielhaber [EMAIL PROTECTED] writes: | Now I get: | byacc -d preproc.y | byacc: f - maximum table size exceeded | gmake[4]: *** [preproc.c] Error 2 | | Better install bison if you want to work with CVS sources ... | the lack of bison probably explains why it's failing for you on | this system when it's OK on other FreeBSD boxes. I concur that bison is required -- A fresh OpenBSD install failed to build with the same error mentioned above until I installed bison. | I wonder if we ought not accept byacc as a suitable yacc in configure? | Peter, what do you think? I can agree with this approach, unless there is some magic to get byacc to work. In any case, there should be a note in the installation docs stating that bison must be used when working with the CVS src. brent
[HACKERS] Re: 7.1beta4 RPMs.
On 29 Jan 2001 at 02:50 (-0500), Lamar Owen wrote: | Lamar Owen wrote: | ftp://ftp.postgresql.org/pub/dev/test-rpms is the place. | | One note: for whatever reason the date on the uploaded RPM's has the | wrong year -- but the timestamp on my local copy has the correct date. | In any case, ignore the datestamp on those RPM's -- there were _not_ | built a year ago on Sat, January 29, 2000. yeah, right ;) comment on the rpms: 1) could you modify the init script, specifically the initdb command, to use the assigned $PGDATA. I have an environment where the main database must be installed to a different location than /var/lib/pgsql(/data)?. the suggested line is below. su -l postgres -c "/usr/bin/initdb -D $PGDATA" /dev/null also, the original had a little typo: ' /dev/null' otherwise, my experience with the rpms has been pretty good :) Thanks for your effort. brent -- "We want to help, but we wouldn't want to deprive you of a valuable learning experience." http://openbsd.org/mail.html
[HACKERS] function optimization ???
Hi, I've the following function: CREATE FUNCTION book_info(pricing) RETURNS catalog_general AS ' select * from catalog_general where star_isbn = $1.vista_isbn ' LANGUAGE 'sql'; calling it as: SELECT p.*, p.book_info.title FROM pricing p WHERE vista_ans='POD'; background and observation: the pricing table is fairly large, but only a small number meet "WHERE vista_ans='POD'". I can select all where vista_ans='POD' very quickly (.2 sec), but adding in the get_book(pricing) call slows this down to about 20sec. I can, with an external sql query, select all of the desired records in about 1 sec, so it appears to me that the function is being called regardless of whether or not the WHERE clause is being satisfied. question: is there any way the function call could be _not_ called if: 1) the WHERE clause does not reference any of its return values, and 2) the WHERE clause has already been satisified. ??? If this behavior is reasonable, could someone point me _toward_ the code where I'd need to make this optimization. I think this would be nice to have for 7.2 :) brent
Re: [HACKERS] function optimization ???
On 24 Jan 2001 at 12:14 (-0500), Tom Lane wrote: | Brent Verner [EMAIL PROTECTED] writes: | calling it as: |SELECT p.*, p.book_info.title FROM pricing p WHERE vista_ans='POD'; | background and observation: |the pricing table is fairly large, but only a small number meet |"WHERE vista_ans='POD'". I can select all where vista_ans='POD' |very quickly (.2 sec), but adding in the get_book(pricing) call |slows this down to about 20sec. I can, with an external sql query, |select all of the desired records in about 1 sec, so it appears |to me that the function is being called regardless of whether |or not the WHERE clause is being satisfied. | | This conclusion is absolutely false: the SELECT target list is NOT | evaluated except at rows where the WHERE condition is satisfied. | | I suspect the real problem is that the select inside the function | is not being done as efficiently as you'd like. yes, this is indeed the case. Sorry for the noise, my 'with an external query' case was a broken product of sleep-dep :\. thanks. brent
[HACKERS] oid failures on Alpha solved
Hi, It turns out the problem causing the oid failures is with our snprintf. specifically we are formatting "%u" incorrectly: using a enhanced-for-testing version of our snprintf I get. formatting '-1040' with '%lu' snprintf = 18446744073709550576 sprintf = 18446744073709550576 formatting '-1040' with '%u' snprintf = 18446744073709550576 sprintf = 4294966256 oidout() is where the offending call originates, FWIW. snprintf(result, 12, "%u", o); I've massaged in the snprintf.c code from openssh into postgres, and oid now passes the regression test, but have a couple of questions: 1) could the openssh code be a candidate to replace our version? It looks quite a bit more 'featureful', and I'd imagine it is about as safe as snprintf gets. 2) do we _need_ oidout() to "%u", or could we "%lu" and fully take advantage of the longer long on 64bit platforms? cheers. brent
[HACKERS] Re: oid failures on Alpha solved
On 30 Dec 2000 at 14:24 (-0500), Tom Lane wrote: | Brent Verner [EMAIL PROTECTED] writes: | formatting '-1040' with '%u' | snprintf = 18446744073709550576 | sprintf = 4294966256 | | oidout() is where the offending call originates, FWIW. | snprintf(result, 12, "%u", o); | | Hm. This is clearly a bug in snprintf. | | OK, I was able to duplicate this failure on Debian Alpha after forcing | our snprintf emulation to be used instead of the system's. Problem is | sloppy signed-vs-unsigned casting in snprintf.c. I've committed a fix. | Another day, another bug... indeed. the most recent snprintf.c works as expected. thank you. brent
[HACKERS] Re: Alpha tas() patch
On 27 Dec 2000 at 21:37 (-0500), Tom Lane wrote:
| Brent Verner [EMAIL PROTECTED] writes:
|This is a revised patch that I sent earlier to allow building
| pg-7.1 with gcc as well as DEC's cc. I've had good results with this
| applied. Could some other Alpha users try this out. Even better, could
| an Alpha asm guru look over the asm that I'm using (instead of the
| original asm in the file).
|
| tas() is not supposed to contain a loop. It can succeed or fail, but
| it should not wait.
|
| The code now in s_lock.h does seem rather gratuitously obscure about
| the instructions it uses to load constants. I'd suggest
|
| static __inline__ int
| tas(volatile slock_t *lock)
| {
| register slock_t _res;
|
| __asm__(" ldq $0, %0 \n\
| bne $0, 2f \n\
| ldq_l $0, %0 \n\
| bne $0, 2f \n\
| mov 1, $0\n\
| stq_c $0, %0 \n\
| beq $0, 2f \n\
| mov 0, %1\n\
| mb \n\
| jmp $31, 3f \n\
|2: mov 1, %1\n\
|3: nop ": "=m"(*lock), "=r"(_res): :"0");
|
| return (int) _res;
| }
another loop-free version of TAS that /seems/ to work as desired. WRT to your
seeing the shutdown lock failure, what are you doing to provoke this bug?,
because I have not seen it with either version of the TAS that I've used.
brent
#define TAS(lock) tas_dbv(lock)
#define S_UNLOCK(lock) do { __asm__("mb"); *(lock) = 0; } while (0)
static
__inline__
int
tas(volatile slock_t* __lock)
{
register slock_t __rv;
register slock_t __temp;
__asm__
__volatile__
(
"1: ldq_l %0, %1 \n" /* load (and lock) __lock */
"and %0, 1, %2\n" /* if bit 1 is set, store 1 in __rv */
"bne %2, 2f \n" /* if __rv != 0, already locked. leave*/
"xor %0, 1, %0\n" /* set bit 1 in slock_t */
"stq_c %0, %1 \n" /* store __lock, only stores if we locked */
"mb \n" /* memory block (necessary?) */
" 2: nop \n" /* exit point */
: "=r" (__temp),
"=m" (*__lock),
"=r" (__rv)
: "m" (*__lock)
);
return (int) __rv;
}
Re: [HACKERS] Re: Alpha tas() patch
On 28 Dec 2000 at 17:03 (+0200), Adriaan Joubert wrote: | Hi, | | I missed the beginning of this thread. Are you doing this for Tru64 or | for Linux? For Tru64 there are macros in /usr/include/alpha/builtins.h | which do the job. gcc + Tru64, since gcc-2.95.2 doesn't implement the builtins defined in alpha/builtins.h. Having never seen linux on an Alpha box, I can only assume that the asm (instruction-wise) would be(have) the same. brent
[HACKERS] Re: Alpha tas() patch
On 28 Dec 2000 at 10:48 (-0500), Tom Lane wrote: | Brent Verner [EMAIL PROTECTED] writes: | another loop-free version of TAS that /seems/ to work as desired. | | Since it doesn't check to see if the stq_c succeeded, it can't possibly | be right... right, I just realized that while composing a now-deleted response to Adriaan :-) back to the TAS-loop issue. when using | WRT to your seeing the shutdown lock failure, what are you doing to | provoke this bug? | | "pg_ctl stop". I see this with the version of TAS() that you recently suggested, but not with either of the versions I'd hacked up. | I am wondering if the machine I am testing on is different from yours. | I know there are multiple revisions of Alpha hardware out there; is | there a way to test which mask rev is running a particular machine? I have no clue right now, but I'll look into it. brent
[HACKERS] Re: Alpha tas() patch
On 28 Dec 2000 at 12:41 (-0500), Tom Lane wrote: | Brent Verner [EMAIL PROTECTED] writes: | I see this with the version of TAS() that you recently suggested, but not | with either of the versions I'd hacked up. | | Hm. Your second version might incorrectly appear to work because it's | not checking for stq_c failure. The first one loops until it succeeds, | so if the deal is that stq_c might work sometimes but not always | (dependent on, say, cache miss effects) then that might explain why it | works. Clearly there's more here to worry about than the available | documentation suggests. what have I stumbled into :). 'damnit Jim!, I'm just a perl hacker.' | Awhile back I received some mail from a guy at Compaq saying that a | taken branch between ldq_l and stq_c is no good, apparently because some | versions of the processor will clear the lock register when any transfer | of control occurs. But it sounded like a not-taken conditional branch | is OK. Nonetheless, it's interesting that the | __INTERLOCKED_TESTBITSS_QUAD macro doesn't use any branch at all between | those two instructions. Maybe we should try it that way. I agree with this assessment from my reading of the asm docs so far. there is also the (w)mb instruction whose importance/effect I'm not sure of... | Is there any documentation on exactly what __INTERLOCKED_TESTBITSS_QUAD | is supposed to do? It looks like it's computing which bit to set in the | quadword, but I'm not sure I'm interpreting the code correctly. yes, WRT to the 'which bit', since __INTERLOCKED_TESTBITSS_QUAD takes as second arg, which is the bit to set. | I'm going to instrument my version a little more to see exactly which | step is failing ... I suspect it's the stq_c result test but want to | prove that before trying alternatives. my understanding of the ldq_l/stc_q interaction, is: (forgive me if you already grok all of this, I'm mostly thinking out loud.) ldq_l $0, $1 # $0 = $1; addq $0, 1, $2 # $2 = $0 + 1; stq_c $2, $1 # $1 = $2; cmpeq $2, $1, $3 # $3 = $2 == $1 ? 1 : 0 if $3 == 1 we successfully modified the locked value ($1). I /believe/ this will hold true across multi-processors as well, as all of the builtins I've seen asm for seem to have similar structure. | BTW, is your machine single- or multi-processor? single. brent
[HACKERS] Re: Alpha tas() patch
On 28 Dec 2000 at 17:40 (-0500), Tom Lane wrote: | Okay ... I guess the LOCK_LONG macros are our best shot. Here is a | proposed new Alpha section for s_lock.h. Would you try it and let me | know how it works for you? | | Note that this will NOT fix the CreateCheckPoint shutdown error; don't | worry about that. The thing to look at is whether the parallel regress | tests pass. after fresh CVS update: geometry, float8, and oid are still failing, and I now am seeing the CheckPoint shutdown bug, which leaves the db in an unusable state after running the regression tests. mnemosyne:~/src/gcc-pgsql pgadmin$ pg_ctl start postmaster successfully started up mnemosyne:~/src/gcc-pgsql pgadmin$ DEBUG: starting up DEBUG: database system was interrupted at 2000-12-28 21:28:39 DEBUG: CheckPoint record at (0, 1563064) DEBUG: Redo record at (0, 1563064); Undo record at (0, 0); Shutdown TRUE DEBUG: NextTransactionId: 615; NextOid: 18720 DEBUG: database system was not properly shut down; automatic recovery in progress... DEBUG: redo starts at (0, 1563128) mnemosyne:~/src/gcc-pgsql pgadmin$ Startup failed - abort
Re: [HACKERS] Re: Tuple-valued datums on Alpha (was Re: 7.1 on DEC/Alpha)
On 26 Dec 2000 at 23:41 (-0500), Tom Lane wrote:
| Brent Verner [EMAIL PROTECTED] writes:
| | Please apply it locally and let me know what you find.
|
| what I'm seeing now is much the same.
|
| Drat. More to do, then.
after hours in the gdb-hole, I see this... maybe a clue? :)
src/include/access/common/heaptuple.c:
450 {
451
452 /*
453* Fix me when going to a machine with more than a four-byte
454* word!
455*/
456 off = att_align(off, att[j]-attlen, att[j]-attalign);
457
458 att[j]-attcacheoff = off;
459
460 off = att_addlength(off, att[j]-attlen, tp + off);
461 }
I'm pretty sure I don't know best how to fix this, but I've got some
randomly entered code compiling now :) If it passes the regression
tests I'll send it along.
brent 'glad the coffee shop in the backyard is open now :)'
Re: [PATCHES] Re: [HACKERS] Re: Tuple-valued datums on Alpha (was Re: 7.1 on DEC/Alpha)
On 27 Dec 2000 at 21:45 (-0500), Tom Lane wrote: | Brent Verner [EMAIL PROTECTED] writes: | | Hm. I thought I'd fixed that. Are you up to date on | | src/backend/utils/adt/oid.c ? Current CVS has rev 1.42. | | yup. got that version -- 1.42 2000/12/22 21:36:09 tgl | | You're right, it was still broken :-(. I think I've got it now, though. i'll check it tomorrow. | Oliver Elphick was kind enough to arrange access to an Alpha running | Debian Linux, and I find that current-as-of-this-moment sources pass | all regression tests in either serial or parallel test mode on that | system. Curiously, however, the system fails when you try to shut | it down: good. I'm glad you guys linked up :) | Smart Shutdown request at Thu Dec 28 02:41:49 2000 | DEBUG: shutting down | FATAL 2: Checkpoint lock is busy while data base is shutting down | Shutdown failed - abort I'm not seeing this with my latest revision of the TAS() asm. Smart Shutdown request at Wed Dec 27 19:25:45 2000 DEBUG: shutting down DEBUG: MoveOfflineLogs: remove DEBUG: database system is shut down | I have no idea why this should be. Evidently there's something wrong | with the TAS() macro --- yet it seems to work fine elsewhere. Ideas | anyone? re-evaluating the asm stuff now. thanks. brent
[HACKERS] Re: Tuple-valued datums on Alpha (was Re: 7.1 on DEC/Alpha)
On 26 Dec 2000 at 14:41 (-0500), Tom Lane wrote: | I wrote: | ... What I'm thinking about doing is setting typmod of | an entire-tuple function argument to sizeof(Pointer), rather than | the default -1, to indicate that a pointer representation is being | used. Comments, hackers? | | Here is a patch to current sources along this line. I have not | committed it, since I'm not sure it does the job. It doesn't break | the regress tests on my machine, but does it fix them on Alphas? | Please apply it locally and let me know what you find. what I'm seeing now is much the same. FWIW, it looks like we're picking up the cruft around functions.c:354paramLI-value = fcinfo-arg[paramLI-id - 1]; (both of which are type Datum) i've been in circles trying to figure out where fcinfo-arg is filled. can you point me toward that? thanks for your help. brent
Re: [HACKERS] Re: Tuple-valued datums on Alpha (was Re: 7.1 on DEC/Alpha)
On 26 Dec 2000 at 23:41 (-0500), Tom Lane wrote: | Brent Verner [EMAIL PROTECTED] writes: | | Please apply it locally and let me know what you find. | | what I'm seeing now is much the same. sorry, I sent the previous email w/o the details of the different behavior. Inside ExecEvalFieldSelect(), result is now 303, instead of 110599844 (...or whatever is was). I'm not sure if this gives you any additional clues. thanks. brent
[HACKERS] Re: 7.1 on DEC/Alpha
On 24 Dec 2000 at 01:19 (-0500), Tom Lane wrote: | Brent Verner [EMAIL PROTECTED] writes: | (gdb) p *resSlot | Error accessing memory address 0x40141830: Invalid argument. | | Oooh. resSlot has been truncated to 32 bits --- judging by the other | nearby pointer values, it almost certainly should have been 0x140141830. | Now we have a lead. FWIW, saying 'set econtext-ecxt_param_list_info-value 0x14014183' in geb allows the process to not SEGV where it _was_ destined to do so, though it does SEGV in a later return to the function. I've tried to determine where this value is originating, and where it is subsequently modified, but have not been able to do so. lost in gdb. Q: I tried doing 'watch address', but this (appeared) to just hang. is there some trick to using 'watch' on addresses that I might be overlooking? | I am guessing that the truncation happened somewhere in | executor/functions.c, but don't see it right away... more observations WRT sql that blows up postgres on Alpha. works: SELECT p.hobbies.equipment.name, p.hobbies.name, p.name FROM ONLY person p; breaks: SELECT p.hobbies.equipment.name, p.hobbies.name, p.name FROM person p; SELECT p.hobbies.equipment.name, p.hobbies.name, p.name FROM person* p; whatever it is that ONLY causes, avoids the breakage. I've spent the past two days in a gdb-hole, going in circles. I just think don't know enough (about gdb or postgres) to make any further progress. anyway, if someone could tell me what difference the ONLY keyword makes WRT pg internally, it might help me quit running in circles. thanks. brent
[HACKERS] Re: 7.1 on DEC/Alpha
here's a post-mortem. #0 0x1200ce58c in ExecEvalFieldSelect (fselect=0x1401615c0, econtext=0x14016a030, isNull=0x14016ab31 "", isDone=0x0) at execQual.c:1096 #1 0x1200ceafc in ExecEvalExpr (expression=0x1401615f0, econtext=0x0, isNull=0x14016ab31 "", isDone=0x0) at execQual.c:1234 #2 0x1200cdd74 in ExecEvalFuncArgs (fcache=0x14016aa70, argList=0x14016a030, econtext=0x14016a030) at execQual.c:603 #3 0x1200cde54 in ExecMakeFunctionResult (fcache=0x14016aa70, arguments=0x1401616d0, econtext=0x14016a030, isNull=0x11fffdf88 "", isDone=0x0) at execQual.c:654 #4 0x1200ce224 in ExecEvalOper (opClause=0x1401615f0, econtext=0x14016a030, isNull=0x11fffdf88 "", isDone=0x0) at execQual.c:841 #5 0x1200cea24 in ExecEvalExpr (expression=0x1401615f0, econtext=0x0, isNull=0x14016ab31 "", isDone=0x0) at execQual.c:1204 #6 0x1200cec54 in ExecQual (qual=0x14016a1a0, econtext=0x14016a030) at execQual.c:1356 #7 0x1200cf2a8 in ExecScan (node=0x14016a1d0, accessMtd=0x1200d8320 SeqNext) at execScan.c:129 #8 0x1200d846c in ExecSeqScan (node=0x1401615f0) at nodeSeqscan.c:138 #9 0x1200cc280 in ExecProcNode (node=0x14016a1d0, parent=0x14016a1d0) at execProcnode.c:284 #10 0x1200ca8c0 in ExecutePlan (estate=0x14016a310, plan=0x14016a1d0, numberTuples=1, direction=ForwardScanDirection, destfunc=0x140020c20) at execMain.c:959 #11 0x1200c9b50 in ExecutorRun (queryDesc=0x1401615f0, estate=0x14016a310, count=0) at execMain.c:199 #12 0x1200d1140 in postquel_getnext (es=0x140160630) at functions.c:324 #13 0x1200d1300 in postquel_execute (es=0x140160630, fcinfo=0x1401604a0, fcache=0x140160590) at functions.c:417 #14 0x1200d14d8 in fmgr_sql (fcinfo=0x1401604a0) at functions.c:542 #15 0x1200ce09c in ExecMakeFunctionResult (fcache=0x140160480, arguments=0x14015e810, econtext=0x140119cd0, isNull=0x140160350 "", isDone=0x11fffe258) at execQual.c:712 #16 0x1200ce2c4 in ExecEvalFunc (funcClause=0x1401615f0, econtext=0x140119cd0, isNull=0x140160350 "", isDone=0x11fffe258) at execQual.c:883 #17 0x1200cea3c in ExecEvalExpr (expression=0x1401615f0, econtext=0x0, isNull=0x14016ab31 "", isDone=0x0) at execQual.c:1208 #18 0x1200c8e10 in ExecEvalIter (iterNode=0x1401615f0, econtext=0x14016a030, isNull=0x1 Error reading address 0x1: Invalid argument, isDone=0x0) at execFlatten.c:56 #19 0x1200ce9b0 in ExecEvalExpr (expression=0x1401615f0, econtext=0x0, isNull=0x14016ab31 "", isDone=0x0) at execQual.c:1183 #20 0x1200cdd74 in ExecEvalFuncArgs (fcache=0x140160290, argList=0x14016a030, econtext=0x140119cd0) at execQual.c:603 #21 0x1200cde54 in ExecMakeFunctionResult (fcache=0x140160290, arguments=0x14015e840, econtext=0x140119cd0, isNull=0x11fffe3a0 "", isDone=0x11fffe468) at execQual.c:654 #22 0x1200ce2c4 in ExecEvalFunc (funcClause=0x1401615f0, econtext=0x140119cd0, isNull=0x11fffe3a0 "", isDone=0x11fffe468) at execQual.c:883 #23 0x1200cea3c in ExecEvalExpr (expression=0x1401615f0, econtext=0x0, isNull=0x14016ab31 "", isDone=0x0) at execQual.c:1208 #24 0x1200ce574 in ExecEvalFieldSelect (fselect=0x14015e720, econtext=0x14016a030, isNull=0x11fffe3a0 "", isDone=0x0) at execQual.c:1091 #25 0x1200ceafc in ExecEvalExpr (expression=0x1401615f0, econtext=0x0, isNull=0x14016ab31 "", isDone=0x0) at execQual.c:1234 #26 0x1200c8e10 in ExecEvalIter (iterNode=0x1401615f0, econtext=0x14016a030, isNull=0x1 Error reading address 0x1: Invalid argument, isDone=0x0) at execFlatten.c:56 #27 0x1200ce9b0 in ExecEvalExpr (expression=0x1401615f0, econtext=0x0, isNull=0x14016ab31 "", isDone=0x0) at execQual.c:1183 #28 0x1200ceea4 in ExecTargetList (targetlist=0x14015e870, targettype=0x14016, values=0x140160260, econtext=0x140119cd0, isDone=0x11fffe5a8) at execQual.c:1528 #29 0x1200cf1a8 in ExecProject (projInfo=0x0, isDone=0x1) at execQual.c:1751 #30 0x1200d8074 in ExecResult (node=0x14015e5b0) at nodeResult.c:167 #31 0x1200cc238 in ExecProcNode (node=0x14015e5b0, parent=0x14015e5b0) at execProcnode.c:272 #32 0x1200ca8c0 in ExecutePlan (estate=0x14015eab0, plan=0x14015e5b0, numberTuples=0, direction=ForwardScanDirection, destfunc=0x1401603a0) at execMain.c:959 #33 0x1200c9b50 in ExecutorRun (queryDesc=0x1401615f0, estate=0x14015eab0, count=0) at execMain.c:199 #34 0x12013e5c0 in ProcessQuery (parsetree=0x14015ea80, plan=0x14016) at pquery.c:305 #35 0x12013c568 in pg_exec_query_string ( query_string=0x140115310 "SELECT p.hobbies.equipment.name, p.hobbies.name, p.name FROM person* p;", parse_context=0x1400c5c60) at postgres.c:817 #36 0x12013dd10 in PostgresMain (argv=0x11fffe9a8, real_argv=0x11ae8, username=0x1400b72f9 "pgadmin") at postgres.c:1827 #37 0x12011aef0 in DoBackend (port=0x1400b7080) at postmaster.c:2021 #38 0x12011a888 in BackendStartup (port=0x1400b7080) at postmaster.c:1798 #39 0x12011938c in ServerLoop () at postmaster.c:957 #40 0x120118c10 in PostmasterMain
[HACKERS] Re: Re: 7.1 on DEC/Alpha
On 24 Dec 2000 at 01:00 (-0500), Tom Lane wrote:
| Brent Verner [EMAIL PROTECTED] writes:
| here's a post-mortem.
|
| #0 0x1200ce58c in ExecEvalFieldSelect (fselect=0x1401615c0,
| econtext=0x14016a030, isNull=0x14016ab31 "", isDone=0x0) at execQual.c:1096
|
| Looks reasonable as far as it goes. Evidently the crash is in the
| heap_getattr macro call at line 1096 of src/backend/executor/execQual.c.
| We need to look at the data structures that macro uses.
| What do you get from
|
| p *fselect
$1 = {type = T_FieldSelect, arg = 0x140169d40, fieldnum = 1, resulttype = 25,
resulttypmod = -1}
| p *econtext
$2 = {type = T_ExprContext, ecxt_scantuple = 0x14016a568,
ecxt_innertuple = 0x0, ecxt_outertuple = 0x0,
ecxt_per_query_memory = 0x1400c5df0, ecxt_per_tuple_memory = 0x1400c6670,
ecxt_param_exec_vals = 0x0, ecxt_param_list_info = 0x140141760,
ecxt_aggvalues = 0x0, ecxt_aggnulls = 0x0}
| p *resSlot-val
Error accessing memory address 0x40141838: Invalid argument.
| p *resSlot-ttc_tupleDescriptor
Error accessing memory address 0x40141848: Invalid argument.
additionally:
(gdb) p result
$4 = 1075058736
(gdb) p *resSlot
Error accessing memory address 0x40141830: Invalid argument.
| BTW, if you didn't configure with --enable-cassert, it'd be a good idea
| to go back and try it that way...
will reconfig/rebuild shortly.
brent
[HACKERS] 7.1 on DEC/Alpha
Hi, I saw the thread from a few days ago about Linux/Alpha and 7.1. I believe I'm seeing the same problems with DEC/Alpha (Tru64Unix 4.0D). I noticed the following in the postmaster.log, which occurs, as the Linux/Alpha bug report states, during the misc regression test. DEBUG: copy: line 293, XLogWrite: had to create new log file - you probably should do checkpoints more often Server process (pid 24954) exited with status 139 at Fri Dec 22 17:15:48 2000 Terminating any active server processes... Server processes were terminated at Fri Dec 22 17:15:48 2000 Reinitializing shared memory and semaphores DEBUG: starting up DEBUG: database system was interrupted at 2000-12-22 17:15:47 DEBUG: CheckPoint record at (0, 316624) DEBUG: Redo record at (0, 316624); Undo record at (0, 0); Shutdown TRUE the full src/test/regress/log/postmaster.log can be snagged from http://www.rcfile.org/postmaster.log in addition to this, compiling on DEC/Alpha with gcc does not work, without some shameful hackery :) as __INTERLOCKED_TESTBITSS_QUAD() is a builtin that gcc does not know about. The DEC cc builds pg properly. either way pg is built the test results are much the same, esp the FAILURE of misc regression test. If there is anything else I can do to help get this working, please let me know. Brent Verner
[HACKERS] Re: 7.1 on DEC/Alpha
On 22 Dec 2000 at 20:27 (-0500), Brent Verner wrote: observation: commenting out the queries with 'FROM person* p' causes the misc regression test to pass. SELECT p.name, p.hobbies.name FROM person* p; Brent | Hi, | I saw the thread from a few days ago about Linux/Alpha and 7.1. I | believe I'm seeing the same problems with DEC/Alpha (Tru64Unix 4.0D). | | I noticed the following in the postmaster.log, which occurs, as the | Linux/Alpha bug report states, during the misc regression test. | | DEBUG: copy: line 293, XLogWrite: had to create new log file - you probably |should do checkpoints more often | Server process (pid 24954) exited with status 139 at Fri Dec 22 17:15:48 2000 | Terminating any active server processes... | Server processes were terminated at Fri Dec 22 17:15:48 2000 | Reinitializing shared memory and semaphores | DEBUG: starting up | DEBUG: database system was interrupted at 2000-12-22 17:15:47 | DEBUG: CheckPoint record at (0, 316624) | DEBUG: Redo record at (0, 316624); Undo record at (0, 0); Shutdown TRUE | | the full src/test/regress/log/postmaster.log can be snagged from | http://www.rcfile.org/postmaster.log | | in addition to this, compiling on DEC/Alpha with gcc does not work, | without some shameful hackery :) as __INTERLOCKED_TESTBITSS_QUAD() is | a builtin that gcc does not know about. The DEC cc builds pg properly. | either way pg is built the test results are much the same, esp the | FAILURE of misc regression test. | | If there is anything else I can do to help get this working, please | let me know. | | Brent Verner
[HACKERS] Re: 7.1 on DEC/Alpha
On 22 Dec 2000 at 21:58 (-0500), Brent Verner wrote: | On 22 Dec 2000 at 20:27 (-0500), Brent Verner wrote: | | observation: | | commenting out the queries with 'FROM person* p' causes the misc | regression test to pass. that's not what I meant to say. the misc test still FAILS, but it no longer causes pg to die. b
