Re: [HACKERS] What do you want me to do?

[Peter Eisentraut]

Tom Lane writes:

 What we could use instead is for someone knowledgeable to commit to
 transferring *valid* emailed bug reports into the tracking system.
 Bruce could do that if he wants, but there are surely dozens of other
 people who would be qualified to handle this task.

I don't think we need decicated bug transferrers.  Typically, when someone
reports a problem by email, the first step is that some developer or other
expert responds (unless the reporter gets blown away by fellow users as
clueless :-)).  So the natural extension of this process would be that the
person doing the analysis records the problem.  The only way we can get
more people involved in doing the recording is if more people can do the
analyzing.  And that step is independent of the presence of a bug-tracking
system.

In other words, I don't want to have a group of people cleaning up after
a different group of people along the lines of the current Is this a TODO
item?.  That way, we'd just have a more complex technology but no process
improvement.

I don't even think that the flood of bug reports is that bad.  Over the
last 60 days I counted at most 14 genuine bug reports on pgsql-bugs,
including those that are wishlist items and those that are old project
lore and would have been duplicates of existing recorded bugs.  So even if
you count in bugs coming in through other channels, this should be
manageable.

-- 
Peter Eisentraut   [EMAIL PROTECTED]


---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings

Re: [HACKERS] What do you want me to do?

[Dave Cramer]

I think we should use the best tool available, he is more than willing
to allow open source projects to use it for free.

Dave
On Fri, 2003-11-07 at 23:19, Tom Lane wrote:
 Andrew Dunstan [EMAIL PROTECTED] writes:
  Dave Cramer wrote:
  Jira is a fantastic bug tracking project management system and is
  available free of charge for open source projects.
 
  Wow, that looks very cool indeed! And they are Aussies to boot! :-)
 
 But they don't seem to be on the free-open-source wavelength.
 PostgreSQL is free, period.  So is all the software we depend upon.
 I don't think we are interested in depending upon code that has this
 sort of verbiage about how you are allowed to use it and what it will
 cost:
 http://www.atlassian.com/software/jira/pricing.jsp
 
   regards, tom lane
 
 ---(end of broadcast)---
 TIP 7: don't forget to increase your free space map settings
 
 


---(end of broadcast)---
TIP 8: explain analyze is your friend

Re: [HACKERS] What do you want me to do?

[Tom Lane]

Peter Eisentraut [EMAIL PROTECTED] writes:
 I don't think we need decicated bug transferrers.  Typically, when someone
 reports a problem by email, the first step is that some developer or other
 expert responds (unless the reporter gets blown away by fellow users as
 clueless :-)).  So the natural extension of this process would be that the
 person doing the analysis records the problem.

Yeah, that sounds like it would work.

I still think it would be a good idea to have one or two people actively
in charge of the overall health of the bug repository --- cross-linking
duplicate bugs, making sure fixed bugs get closed out, in general
correcting misinformation when they find it.  This wouldn't be a large
time commitment AFAICS, but without somebody applying pressure in the
right direction I think that the general quality of information in
the database would inevitably slide downhill.

regards, tom lane

---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster

Re: [HACKERS] What do you want me to do?

[Abhijit Menon-Sen]

 http://www.atlassian.com/software/jira/pricing.jsp

I have no particular opinion on whether to use a free or non-free system
to track bugs, but I'd like to recommend RT as being a very capable and
useful program. It has been used to track Perl 5 and CPAN bugs for some
time now, and it happens to be free (and it can use PostgreSQL :).

http://www.bestpractical.com/rt/

-- ams

---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faqs/FAQ.html

Re: [HACKERS] What do you want me to do?

[Rod Taylor]

 I still think it would be a good idea to have one or two people actively
 in charge of the overall health of the bug repository --- cross-linking
 duplicate bugs, making sure fixed bugs get closed out, in general
 correcting misinformation when they find it.  This wouldn't be a large

I think there are a number of people out there who would be willing to
do this, myself included.

-- 
Rod Taylor pg [at] rbt [dot] ca

Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL


---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings

Re: [HACKERS] What do you want me to do?

[ow]

  http://www.atlassian.com/software/jira/pricing.jsp

Another option is free open source Scarab, http://scarab.tigris.org Actually,
I'd prefer it.














__
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree

---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster

Re: [HACKERS] What do you want me to do?

[Andrew Dunstan]

Tom Lane wrote:

Peter Eisentraut [EMAIL PROTECTED] writes:
 

I don't think we need decicated bug transferrers.  Typically, when someone
reports a problem by email, the first step is that some developer or other
expert responds (unless the reporter gets blown away by fellow users as
clueless :-)).  So the natural extension of this process would be that the
person doing the analysis records the problem.
   

Yeah, that sounds like it would work.

I still think it would be a good idea to have one or two people actively
in charge of the overall health of the bug repository --- cross-linking
duplicate bugs, making sure fixed bugs get closed out, in general
correcting misinformation when they find it.  This wouldn't be a large
time commitment AFAICS, but without somebody applying pressure in the
right direction I think that the general quality of information in
the database would inevitably slide downhill.
 

You have described a good part of my professional life in the last 3 
years ;-) I had a meeting every morning with product/project management 
to review/triage bugs and in turn I would spend hours asking my staff 
What is happening with bug xyz?. I lived off the bug system (bugzilla 
and/or ClearQuest). Getting developers used to it is still a hassle - I 
once had to send out an email that said in effect if you aren't working 
on a defect assigned to you then you aren't doing your job.

In a volunteer project things work somewhat differently, of course, but 
the housekeeping functions are still essential.

cheers

andrew

---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster

[HACKERS] New approach to ye olde cross-datatype indexing problem

[Tom Lane]

Once again it's time to consider that old problem that indexes can't
handle cross-datatype comparisons, for example
SELECT ... WHERE int8col = 42
won't use an index on int8col because 42 is int4.

We have spent a huge amount of time trying to find ways to get the system
to assign the same type to the comparison value as the indexed column has.
So far every such proposal has failed, because of unwanted side-effects on
the semantics of operations unrelated to indexes.  I've become more and
more convinced that that approach is a dead end.

What if we attack the problem head on --- make indexes able to handle
cross-datatype comparison operators directly?  That would solve the
problem without *any* semantic side-effects.  AFAIR we've never seriously
considered doing that; I guess anyone who thought of it dismissed it as
too hard.  But I've been studying the idea for the last day or so and I'm
starting to think that it's eminently practical.

Here's what I'm thinking of: specify that the input datatype of an
operator class (pg_opclass.opcintype) is actually just the type of the
indexed column.  Operators that are members of the opclass must take this
type as their left-hand input, but the right-hand input can be some other
type.  pg_amop gets an additional column that is the right-hand data type
of the operator, and its primary key becomes (opclass, righthandtype,
strategy) rather than just (opclass, strategy).  For example, the btree
opclass for int8 will still use strategy number 1 for 'less than', but
it would now contain entries for int84lt, int82lt, etc in addition to
int8lt. We can still maintain the secondary unique index on (opclass,
operator) --- that is, any particular operator still stands in one unique
relationship to an opclass.  The support procedure catalog pg_amproc
likewise needs to get an additional column that is the right hand side
datatype.  For example, the btree opclass for int8 formerly had one
support procedure btint8cmp(int8, int8) but it will now need additional
entries for btint84cmp(int8, int4), btint82cmp(int8, int2) and so on.

The cross-datatype operators we need for this largely already exist ---
in fact it's their presence in the system catalogs that creates the
problem in the first place.  We'll need to write new functions for the
additional support procedures, but there aren't all that many of them.

The existing CREATE OPERATOR CLASS syntax already works for this approach,
since it's possible to specify the input datatypes of an operator.  We
just need to modify the code to allow multiple instances of the same
operator or function number as long as the input datatypes are different.

Inside the system, the changes needed are really rather minimal.  We will
need to add fields to the ScanKey data structure that specify the strategy
number of the operator being invoked and the righthand datatype (ie, the
actual datatype of the sk_argument datum).  Given that information and
knowledge of the index column's opclass, the actual operator can be looked
up in the pg_amop syscache.  The reason I want to add the strategy number
to ScanKey is that this is something the planner knows already (it finds
it out when it discovers that an operator can be used with the index in
the first place) and it seems silly to require the index access method to
re-discover the strategy number from the operator procedure OID.  Passing
the strategy number directly will save cycles.  Furthermore, it
essentially eliminates the need for the StrategyMap mechanism (istrat.c
and friends), which is a big chunk of vestigial code that I've been
wanting to get rid of for awhile.  The only thing the StrategyMap routines
are really doing for us is providing a procedure-OID-to-strategy-number
reverse lookup mechanism, and we won't need that anymore.  This is a good
thing since the existing StrategyMap data structure falls apart in the
presence of multiple operators with the same strategy number.

Relation cache entries for indexes will still include rd_operator and
rd_support fields indexed by strategy and procedure number.  We will
decree that the cached entries are only for the operators and procedures
whose righthand datatype is the same as the indexed datatype.  This is
reasonable since these will still be the most-used items (for example,
the index access method will need to use them to do internal comparisons
between index items).

The index access methods will need to be careful about whether they are
comparing two index entries (necessarily of the same datatype) or an index
entry against an externally-supplied scankey datum (possibly a different
datatype requiring a different operator).  In the btree code the changes
needed are pretty minimal.  I haven't looked at the other index types yet,
but actually I don't care much whether they can support cross-datatype
operators or not.  If it turns out to be at all hard for them to do it,
we can just say that they don't support it.  Fixing btree will solve 

Re: [HACKERS] New approach to ye olde cross-datatype indexing problem

[Peter Eisentraut]

Tom Lane writes:

 Here's what I'm thinking of: specify that the input datatype of an
 operator class (pg_opclass.opcintype) is actually just the type of the
 indexed column.  Operators that are members of the opclass must take this
 type as their left-hand input, but the right-hand input can be some other
 type.  pg_amop gets an additional column that is the right-hand data type
 of the operator, and its primary key becomes (opclass, righthandtype,
 strategy) rather than just (opclass, strategy).

Yes, that looks to be the right way.

 One way in which we will lose some flexibility is that this design nails
 down forevermore the assumption that the indexed column is on the lefthand
 side of any indexable clause.

I don't see this as a problem, but if it becomes one we can relabel left
operand as indexed operand and right operand as variable operand,
and add a boolean flag telling which is right and left.

-- 
Peter Eisentraut   [EMAIL PROTECTED]


---(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] New approach to ye olde cross-datatype indexing problem

[Tom Lane]

Peter Eisentraut [EMAIL PROTECTED] writes:
 Tom Lane writes:
 One way in which we will lose some flexibility is that this design nails
 down forevermore the assumption that the indexed column is on the lefthand
 side of any indexable clause.

 I don't see this as a problem, but if it becomes one we can relabel left
 operand as indexed operand and right operand as variable operand,
 and add a boolean flag telling which is right and left.

Okay.  I won't put in the bool flag for the moment, but I'll use column
names along the lines of indtype and othertype so that we won't need
to rename the columns if we want to do that in the future.

BTW, I am not planning to remove the possibility of having unary
operators in an opclass.  (We have talked about supporting indexing
of IS NULL/IS NOT NULL queries by treating IS(NOT)NULL as a unary
operator --- while I'm not planning to tackle that now, I don't want
to foreclose the possibility.)  I think I will specify that othertype
for a unary operator should be set equal to the opclass's indtype,
rather than the more-obvious zero.  This will allow the unary operator
to be part of the cached set of operators (which are only going to be
the ones with othertype=indtype).

regards, tom lane

---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [HACKERS] Making PostgreSQL 7.4 (CVS) work properly on OS X 10.3 (7B85)

[Tom Lane]

Bob Ippolito [EMAIL PROTECTED] writes:
 On Nov 8, 2003, at 12:31 AM, Tom Lane wrote:
 I have just in the past couple hours realized that ps_status.c is
 seriously broken on OS X 10.3.

 Er... I meant memcmp.. Have you tried removing the system.c hack?  
 That's what fixed it for me.

AFAICT system.c hasn't got anything to do with the problem that I'm
seeing; it's purely a matter of ps_status.c clobbering argv[] contents
that the dynamic loader depends on for some weird reason.  It looks
like Apple's implementation stores a copy of the original argc count,
and there is a bit of code in the loader that for some reason is
examining each argv string from 0..original_argc-1.  Who knows why :-(
... but where we set save_argv[1] to NULL, we create a null pointer
crash in the loader.  Take that out, no crash.  You would not see this
crash if you started the postmaster with no command-line arguments, btw.

I'm planning to change ps_status so that instead of zeroing
save_argv[1], it makes all the original argv strings be pointers to 
except for argv[0].

As for getting rid of system.c, I am not eager to do that since it would
certainly break compatibility with OS X 10.1.  We could conditionally
compile it out perhaps.  Do you know what #define symbol we could test
for to determine which OS X version we are on?

regards, tom lane

---(end of broadcast)---
TIP 8: explain analyze is your friend

Re: [HACKERS] Making PostgreSQL 7.4 (CVS) work properly on OS X 10.3 (7B85)

[Bob Ippolito]

On Nov 8, 2003, at 1:13 PM, Tom Lane wrote:

Bob Ippolito [EMAIL PROTECTED] writes:
On Nov 8, 2003, at 12:31 AM, Tom Lane wrote:
I have just in the past couple hours realized that ps_status.c is
seriously broken on OS X 10.3.

Er... I meant memcmp.. Have you tried removing the system.c hack?
That's what fixed it for me.
AFAICT system.c hasn't got anything to do with the problem that I'm
seeing; it's purely a matter of ps_status.c clobbering argv[] contents
that the dynamic loader depends on for some weird reason.  It looks
like Apple's implementation stores a copy of the original argc count,
and there is a bit of code in the loader that for some reason is
examining each argv string from 0..original_argc-1.  Who knows why :-(
... but where we set save_argv[1] to NULL, we create a null pointer
crash in the loader.  Take that out, no crash.  You would not see this
crash if you started the postmaster with no command-line arguments, 
btw.

I'm planning to change ps_status so that instead of zeroing
save_argv[1], it makes all the original argv strings be pointers to 
except for argv[0].
It may be causing problems because dyld does this thing called 
@executable_path substitution so it can find dylibs relative to the 
executable.  Also, the WindowServer and several other things 
(CoreFoundation, Foundation) use argv[0] to determine whether the 
executable is inside a bundle or not.

I don't think OS X people would make a big fuss about argv[0] not being 
as useful as it is on other platforms, personally I'd just take it out 
if it's not working.

As for getting rid of system.c, I am not eager to do that since it 
would
certainly break compatibility with OS X 10.1.  We could conditionally
compile it out perhaps.  Do you know what #define symbol we could test
for to determine which OS X version we are on?
See /usr/include/AvailabilityMacros.h

-bob

---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
  http://www.postgresql.org/docs/faqs/FAQ.html

Re: [HACKERS] Making PostgreSQL 7.4 (CVS) work properly on OS X 10.3 (7B85)

[Tom Lane]

Bob Ippolito [EMAIL PROTECTED] writes:
 On Nov 8, 2003, at 1:13 PM, Tom Lane wrote:
 As for getting rid of system.c, I am not eager to do that since it 
 would
 certainly break compatibility with OS X 10.1.  We could conditionally
 compile it out perhaps.  Do you know what #define symbol we could test
 for to determine which OS X version we are on?

 See /usr/include/AvailabilityMacros.h

I don't see anything there that we can use in the form

#ifdef OSX_VERSION_10_2
or
#if OSX_VERSION = something

My 10.2.6 copy already has MAC_OS_X_VERSION_10_3 in it, so they are
obviously not intending that the highest defined symbol of that
series is the OS version.

regards, tom lane

---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [HACKERS] Making PostgreSQL 7.4 (CVS) work properly on OS X 10.3 (7B85)

[Bob Ippolito]

On Nov 8, 2003, at 1:44 PM, Tom Lane wrote:

Bob Ippolito [EMAIL PROTECTED] writes:
On Nov 8, 2003, at 1:13 PM, Tom Lane wrote:
As for getting rid of system.c, I am not eager to do that since it
would
certainly break compatibility with OS X 10.1.  We could conditionally
compile it out perhaps.  Do you know what #define symbol we could 
test
for to determine which OS X version we are on?

See /usr/include/AvailabilityMacros.h
I don't see anything there that we can use in the form

#ifdef OSX_VERSION_10_2
or
#if OSX_VERSION = something
My 10.2.6 copy already has MAC_OS_X_VERSION_10_3 in it, so they are
obviously not intending that the highest defined symbol of that
series is the OS version.
MAC_OS_X_VERSION_MIN_REQUIRED

 * If min OS not specified, assume 10.0
 * Note: gcc driver may set MAC_OS_X_VERSION_MIN_REQUIRED based on 
MACOSX_DEPLOYMENT_TARGET environment variable

Compiling software for 10.3 should setenv MACOSX_DEPLOYMENT_TARGET 10.3

-bob

---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings

[HACKERS] Bug fix for 7.4?

[Michael Meskes]

I just fixed a bug in ecpglib that caused it to misbehave for all
internal array/vector types. They were treated like the external ones.
So ecpg expected them to be listed as '{...}' which surely failed. 

However, this bug fix involves more code changes than I like to just
commit into 7.4 at this point of the release. So the fixes are so far
just committed to HEAD. On the other hand I don't like to release 7.4
with this know bug. 

The only solution I see is someone else looking over the patch resp.
testing it. It worked well with my test suite, but then this may not
catch all side effects.

Michael
-- 
Michael Meskes
Email: Michael at Fam-Meskes dot De
ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED]
Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!

---(end of broadcast)---
TIP 8: explain analyze is your friend

Re: [HACKERS] Making PostgreSQL 7.4 (CVS) work properly on OS X 10.3 (7B85)

[Tom Lane]

Bob Ippolito [EMAIL PROTECTED] writes:
 * I ditched the system.c hack, assuming Apple has fixed them by 10.3 --  
 because it breaks tcl and python if you do.. I did:

After fixing the ps_status problems, I cannot observe any problem, with
or without system.c.  However, I agree that it's a bad idea to propagate
that hack forward when it's no longer needed.  I've #ifdef'd out
system.c for OS X 10.3 and later.  (I was tempted to disable it on
10.2.* as well, but I can only prove system() works in 10.2.6, not
having older OS X handy to test.)

 Ok, that's not quite true, so:
 I edited src/Makefile.global to have
 python_libspec = -framework Python

I'm not going to touch that at this point in the release cycle.  It'll
just have to wait for a future release.

regards, tom lane

---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster

Re: [HACKERS] Making PostgreSQL 7.4 (CVS) work properly on OS X 10.3 (7B85)

[Bob Ippolito]

On Nov 8, 2003, at 3:19 PM, Tom Lane wrote:

Bob Ippolito [EMAIL PROTECTED] writes:
* I ditched the system.c hack, assuming Apple has fixed them by 10.3 
--
because it breaks tcl and python if you do.. I did:
After fixing the ps_status problems, I cannot observe any problem, with
or without system.c.  However, I agree that it's a bad idea to 
propagate
that hack forward when it's no longer needed.  I've #ifdef'd out
system.c for OS X 10.3 and later.  (I was tempted to disable it on
10.2.* as well, but I can only prove system() works in 10.2.6, not
having older OS X handy to test.)
Sounds great

Ok, that's not quite true, so:
I edited src/Makefile.global to have
python_libspec = -framework Python
I'm not going to touch that at this point in the release cycle.  It'll
just have to wait for a future release.
That's fine, does anyone even use plpython?  I only compiled it because 
I knew how to fix it..

-bob

---(end of broadcast)---
TIP 8: explain analyze is your friend

[HACKERS] Question about Threads

[Leon Oosterwijk]

All, 

I'm working on a school project that involves genetic algorithms. We thought
it would be neat to parralelize the genetic algorithm in postgresql's query
optimiser. We used pthreads and are able to spawn threads to deal with the
query optimization, however on exit of the thread the postmaster blows up.
Before we get into details is there any obvious reason postgres doesn't like
to deal with threads? 

Thank you. 

Leon


---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])

[HACKERS] regarding constant values.

[sgupta5]

Hello,

Can you pls explain how the constant values are stored in Postgresql, I
mean using the Const Data Structure.

What does the datum field represent?

Thanks
Shalu

---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faqs/FAQ.html

Re: [HACKERS] bugzilla (Was: What do you want me to do?)

[Andrew Dunstan]

Christopher Kings-Lynne wrote:


The doesn't quite make the best use of PG quote is one of the best
examples of buck-passing I've seen in awhile.  If Bugzilla had been
designed with some thought to DB independence to start with, we'd not
be having this discussion.


You have to laugh at an app that actually uses MySQL's replication to 
get around not having row locks!!!

And it actually has a sanity check feature for 'checking' your 
referential integrity.

I laughed so hard I cried.

And yet we use it at work :P

Bugzilla was put together by a guy who admitted he didn't know much 
about databases, IIRC. It worked and he was in a hurry.

This is a classic story of a piece of software that is far more long 
lasting and far more dirty than was originally intended - I have seen it 
before many times and I expect to see it until I die. I could tell many 
similar stories that would make you laugh/cry even harder, but this 
isn't the place or time :-)

Seriously, I have wondered if it might be a good idea to assemble a 
small hit team that would take some high profile open source projects 
and make sure they worked with Postgres. Bugzilla would be the most 
obvious candidate, but there are certainly others. I suspect that could 
be quite productive, though.

Thoughts?

andrew

---(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] Call for port reports

[Bruce Momjian]

Kurt, this patch added special includes for testing un.h, and I believe
it caused regression failures for the statistics collector.  Is it still
needed?  What platform is this?

---

Kurt Roeckx wrote:
 On Fri, Oct 24, 2003 at 11:37:32AM -0400, Bruce Momjian wrote:
  It is time for people to report their port testing.  Please test against
  current CVS or beta5 and report your 'uname -a'.
 
 I need this small patch so it properly detects I have unix domain
 sockets.  Otherwise no problems.
 
 
 Kurt
 

[ Attachment, skipping... ]

 
 ---(end of broadcast)---
 TIP 4: Don't 'kill -9' the postmaster

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

---(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] Question about Threads

[Leon Oosterwijk]

AgentM, 

The treads are joined back together by the master. I did try to debug, but
have to say I hard a hard time with it. I have tried to debug, but didn't
get very far. Debugging Threads is not my forte. :(  


Here is the code from :
/src/backend/optimizer/geqo/geqo_main.c

for (i=0;ithread_count;i++)
{
geqo_params[i].root = copyObject(root);
geqo_params[i].number_of_rels = number_of_rels;
geqo_params[i].initial_rels = copyObject(initial_rels);

geqo_params[i].root-base_rel_list =
listCopy(root-base_rel_list);
geqo_params[i].root-other_rel_list =
listCopy(root-other_rel_list);
geqo_params[i].root-join_rel_list =
listCopy(root-join_rel_list);
geqo_params[i].root-equi_key_list =
listCopy(root-equi_key_list);
geqo_params[i].root-query_pathkeys =
listCopy(root-query_pathkeys);

geqo_params[i].myid = i;

pthread_create(thread_list[i],
NULL,
(void *(*)(void *))  geqo_single , (void *)
geqo_params[i]);
}

// join all thread and get results
for (i=0;ithread_count;i++)
{
elog(DEBUG1, geqo: trying to join back thread %d, i);
pthread_join(thread_list[i],(void *) results[i]);
// sort results
if (best_so_far == -1)
{
elog(DEBUG1, geqo: thread %d is first thread we
see, i);
best_so_far = i;
}
else
{
if
(results[best_so_far]-cheapest_total_path-total_cost 
results[i]-cheapest_total_path-total_cost)
{
elog(DEBUG1, geqo: thread %d is better than
thread %d , i, best_so_far);
best_so_far = i;

}
}


Leon

 

 -Original Message-
 From: AgentM [mailto:[EMAIL PROTECTED] 
 Sent: Saturday, November 08, 2003 4:01 PM
 To: Leon Oosterwijk
 Subject: Re: [HACKERS] Question about Threads
 
 Are you using joined or detached pthreads? Have you tried debugging?
 
 On Saturday, Nov 8, 2003, at 22:47 Europe/Berlin, Leon 
 Oosterwijk wrote:
 
  All,
 
  I'm working on a school project that involves genetic 
 algorithms. We 
  thought
  it would be neat to parralelize the genetic algorithm in 
 postgresql's 
  query
  optimiser. We used pthreads and are able to spawn threads 
 to deal with 
  the
  query optimization, however on exit of the thread the 
 postmaster blows 
  up.
  Before we get into details is there any obvious reason postgres 
  doesn't like
  to deal with threads?
 
  Thank you.
 
  Leon
 
 AgentM
 [EMAIL PROTECTED]
 
 


---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings

Re: [HACKERS] Making PostgreSQL 7.4 (CVS) work properly on OS X 10.3 (7B85)

[Marko Karppinen]

On 8 Nov 2003, at 22:19, Tom Lane wrote:
After fixing the ps_status problems, I cannot observe any problem, with
or without system.c.  However, I agree that it's a bad idea to 
propagate
that hack forward when it's no longer needed.  I've #ifdef'd out
system.c for OS X 10.3 and later.  (I was tempted to disable it on
10.2.* as well, but I can only prove system() works in 10.2.6, not
having older OS X handy to test.)
As a general rule of thumb, I don't think it's necessary to support
anything other than the latest revision in 10.2.x and 10.3.x at
any time. The revisions are free, they mainly fix bugs, they don't
affect hardware requirements and other software vendors see
requiring them as a non-issue.
This, at the very least, applies to major pgsql versions such
as 7.4 and 7.5 -- you might disagree about a OS version
requirement changing in a point release.
But in my opinion, if system() is fixed in 10.2.6, you can require
Jaguar users to upgrade to that version for 7.4.
mk

---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

[HACKERS] OSR5: Passes without the setsockopt() calls...

[Larry Rosenman]

From my SCO contacts re: the failure on OSR5:


I haven't had time and won't have time to fully diagnose this until
after i get back from vacation. In the mean time, i am attaching a
patch which gets OpenServer 5.0.7 to pass 92 of 93 tests with one
test ignored. Basically, this patch just says if you're on OpenServer
then don't do the setsockopt calls. Not very satisfactory as setsockopt
should work on OSR5.
I know this isn't an acceptable patch, and I'm not sure when my contact
is back from Vacation.
Do we want to hold the release?

LER

--
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
--- ./src/backend/libpq/auth.c.00   2003-09-26 15:27:31.0 +
+++ ./src/backend/libpq/auth.c  2003-11-08 22:54:32.0 +
@@ -480,6 +480,7 @@
 * only if it is defined and SO_PEERCRED isn't.
 */
 #if defined(HAVE_STRUCT_FCRED) || defined(HAVE_STRUCT_SOCKCRED)
+#ifndef _SCO_DS
 
/*
 * Receive credentials on next message receipt, BSD/OS,
@@ -495,6 +496,7 @@
 errmsg(could not enable credential 
reception: %m)));
}
 #endif
+#endif
if (port-raddr.addr.ss_family == AF_UNIX)
sendAuthRequest(port, AUTH_REQ_SCM_CREDS);
 #endif
--- ./src/backend/libpq/pqcomm.c.00 2003-09-25 06:57:59.0 +
+++ ./src/backend/libpq/pqcomm.c2003-11-08 22:55:19.0 +
@@ -312,6 +312,7 @@
continue;
}
 
+#ifndef _SCO_DS
if (!IS_AF_UNIX(addr-ai_family))
{
if ((setsockopt(fd, SOL_SOCKET, SO_REUSEADDR,
@@ -324,8 +325,10 @@
continue;
}
}
+#endif
 
 #ifdef IPV6_V6ONLY
+#ifndef _SCO_DS
if (addr-ai_family == AF_INET6)
{
if (setsockopt(fd, IPPROTO_IPV6, IPV6_V6ONLY,
@@ -339,6 +342,7 @@
}
}
 #endif
+#endif
 
/*
 * Note: This might fail on some OS's, like Linux older than
@@ -548,6 +552,7 @@
}
 
/* select NODELAY and KEEPALIVE options if it's a TCP connection */
+#ifndef _SCO_DS
if (!IS_AF_UNIX(port-laddr.addr.ss_family))
{
int on;
@@ -569,6 +574,7 @@
return STATUS_ERROR;
}
}
+#endif
 
return STATUS_OK;
 }
--- ./src/interfaces/libpq/fe-connect.c.00  2003-10-18 05:02:06.0 +
+++ ./src/interfaces/libpq/fe-connect.c 2003-11-08 22:55:41.0 +
@@ -797,6 +797,7 @@
 static int
 connectNoDelay(PGconn *conn)
 {
+#ifndef _SCO_DS
 #ifdef TCP_NODELAY
int on = 1;
 
@@ -812,6 +813,7 @@
return 0;
}
 #endif
+#endif
 
return 1;
 }
--- ./src/template/sco.00   2003-10-09 03:20:34.0 +
+++ ./src/template/sco  2003-11-06 23:07:14.0 +
@@ -1,2 +1,3 @@
-CC=$CC -b elf
-
+if test $GCC != yes ; then
+CC=$CC -b elf
+fi


pgp0.pgp
Description: PGP signature

[HACKERS] Question for the developers.

[suchindra]

Hi,

 I am Suchindra Katageri and am working as a Software Engineer at
 Linuxlabs, Atlanta, GA.
 
 I am presently working on developing libraries to make postgresql
 run on a cluster. I was wondering if it was possible to force Database
 writes to stable storage, without messing up with the postgres code.
 e.g. force the PostgreSQL to write to stable storage after an INSERT
 command.

 Thanks in advance.
 
-- 
regards,
--suchindra


---(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] Question for the developers.

[Bruce Momjian]

[EMAIL PROTECTED] wrote:
 
 Hi,
 
  I am Suchindra Katageri and am working as a Software Engineer at
  Linuxlabs, Atlanta, GA.
  
  I am presently working on developing libraries to make postgresql
  run on a cluster. I was wondering if it was possible to force Database
  writes to stable storage, without messing up with the postgres code.
  e.g. force the PostgreSQL to write to stable storage after an INSERT
  command.

For stable storage, you mean disk storage?  You need fsync for that,
probably, but we already fsync our write-ahead log (WAL) on every
commit.

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

---(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] Call for port reports

[Bruce Momjian]

I just tested gcc 2.95.3 on BSD/OS i386 and didn't see any change when
using -g3 vs -g in the size of the binaries.

---

Neil Conway wrote:
 On Sat, 2003-10-25 at 21:29, Bruce Momjian wrote:
  configure --enable-debug will use -g for the compile, and with
  optimization.
 
 I'm just curious: would there be any benefit to using -g3 when
 --enable-debug is specified and -g3 is supported by gcc? From the gcc
 man page:
 
-glevel
 
 [...]
 
Request debugging information and also use level to specify how
much information.  The default level is 2.
 
Level 1 produces minimal information, enough for making backtraces
in parts of the program that you don't plan to debug.  This
includes descriptions of functions and external variables, but no
information about local variables and no line numbers.
 
Level 3 includes extra information, such as all the macro defini-
tions present in the program.  Some debuggers support macro expan-
sion when you use -g3.
 
Note that in order to avoid confusion between DWARF1 debug level 2,
and DWARF2, neither -gdwarf nor -gdwarf-2 accept a concatenated
debug level.  Instead use an additional -glevel option to change
the debug level for DWARF1 or DWARF2.
 
 -Neil
 
 

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faqs/FAQ.html

Re: [HACKERS] Question about Threads

[Bruce Momjian]

Leon Oosterwijk wrote:
 All, 
 
 I'm working on a school project that involves genetic algorithms. We thought
 it would be neat to parralelize the genetic algorithm in postgresql's query
 optimiser. We used pthreads and are able to spawn threads to deal with the
 query optimization, however on exit of the thread the postmaster blows up.
 Before we get into details is there any obvious reason postgres doesn't like
 to deal with threads? 

Yes, the backend code is not thread-safe.

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

---(end of broadcast)---
TIP 6: Have you searched our list archives?

   http://archives.postgresql.org

Re: [HACKERS] Call for port reports

[Kurt Roeckx]

On Sat, Nov 08, 2003 at 06:36:38PM -0500, Bruce Momjian wrote:
 
 Kurt, this patch added special includes for testing un.h, and I believe
 it caused regression failures for the statistics collector.  Is it still
 needed?  What platform is this?

It's a linux system with an (old) libc5.  It's still needed for
that platform, but I doubt many people would use it.

On what platfrom does it break?  Is the result of checking for
un.h different?

The stats collector has this code that is relevant:

for (addr = addrs; addr; addr = addr-ai_next)
{
#ifdef HAVE_UNIX_SOCKETS
/* Ignore AF_UNIX sockets, if any are returned. */
if (addr-ai_family == AF_UNIX)
continue;
#endif
if ((pgStatSock = socket(addr-ai_family, SOCK_DGRAM, 0)) = 0)
break;
}


Kurt


---(end of broadcast)---
TIP 8: explain analyze is your friend

Re: [HACKERS] Coding help

[Bruce Momjian]

I guess you are asking how to get the NumericOnly converted to an oid,
and I see from the code that there are very few places where we allow
oid's to be supplied directly.  Most oid's come in as part of our
numberic conversion code.

The only idea I have is to call oidin() to do the conversion from string
to oid.  I see this in copy.c:

loaded_oid = DatumGetObjectId(DirectFunctionCall1(oidin,
   CStringGetDatum(string)));
if (loaded_oid == InvalidOid)
ereport(ERROR,
(errcode(ERRCODE_BAD_COPY_FILE_FORMAT),
 errmsg(invalid OID in COPY data)));

I would give that a try.

---

Christopher Kings-Lynne wrote:
 Hi guys,
 
 I've asked this of a few people now, but I haven't managed to get a 
 straightforward solution.
 
 I'm working on COMMENT ON LARGE OBJECT.
 
 If you could help me with this one, it would be really cool.  Other than
 this, comment on language, conversion, cast and operator class are all done.
 
 This is my grammar snippet.  NumericOnly seems to be the one to use -
 that's what CREATE SEQUENCE uses for its large number support, and I
 have to support large OIDs I presume.  I could also use IntegerOnly 
 perhaps, I don't know:
 
 | COMMENT ON LARGE OBJECT NumericOnly IS comment_text
   {
   CommentStmt *n = makeNode(CommentStmt);
   n-objtype = OBJECT_LARGEOBJECT;
   n-objname = makeList1(makeAConst($5));
   n-objargs = NIL;
   n-comment = $7;
   $$ = (Node *) n;
   }
 
 This is my comment function:
 
 static void
 CommentLargeObject(List *qualname, char *comment)
 {
   /* This is what I cannot figure out - how do I change the Node 
 which is the first element in the qualname to an actual Oid type??? */
   Oidloid = somehow_get_oid_from(lfirst(qualname));
   Oidclassoid;
 
   /* check that the large object exists */
   if (!LargeObjectExists(loid))
   ereport(ERROR,
   (errcode(ERRCODE_UNDEFINED_OBJECT),
   errmsg(large object %u does not exist, loid)));
 
   classoid = get_system_catalog_relid(LargeObjectRelationName);
 
   CreateComments(loid, classoid, 0, comment);
 }
 
 The problem is extracting the oid from the qualname list.  I just can't
 figure it out. I've searched the codebase but there doesn't seem to be
 anywhere else that actually does this, like this.
 
 I've tried all sorts of things, but I can't figure it out...
 
 Thanks for any help,
 
 Chris
 
 
 
 ---(end of broadcast)---
 TIP 4: Don't 'kill -9' the postmaster
 

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings

Re: [HACKERS] Bug fix for 7.4?

[Bruce Momjian]

Yep.  Send patch to patches list and/or have someone who is using this
functionality test it.

---

Michael Meskes wrote:
 I just fixed a bug in ecpglib that caused it to misbehave for all
 internal array/vector types. They were treated like the external ones.
 So ecpg expected them to be listed as '{...}' which surely failed. 
 
 However, this bug fix involves more code changes than I like to just
 commit into 7.4 at this point of the release. So the fixes are so far
 just committed to HEAD. On the other hand I don't like to release 7.4
 with this know bug. 
 
 The only solution I see is someone else looking over the patch resp.
 testing it. It worked well with my test suite, but then this may not
 catch all side effects.
 
 Michael
 -- 
 Michael Meskes
 Email: Michael at Fam-Meskes dot De
 ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED]
 Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!
 
 ---(end of broadcast)---
 TIP 8: explain analyze is your friend
 

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

---(end of broadcast)---
TIP 8: explain analyze is your friend

[HACKERS] How to tell if SQL function gets inlined?

[Joe Conway]

Is there any way, short of using a debugger with a strategically placed 
breakpoint, to tell if a SQL function has been inlined?

Joe

---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
  http://www.postgresql.org/docs/faqs/FAQ.html

Re: [HACKERS] How to tell if SQL function gets inlined?

[Bruce Momjian]

Joe Conway wrote:
 Is there any way, short of using a debugger with a strategically placed 
 breakpoint, to tell if a SQL function has been inlined?

I think you will only see it with debug_print_plan enabled.  You can
change client_min_messages to see that in your psql session.  I think
the parse tree doesn't do the inlining, only the optimizer.

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [HACKERS] Call for port reports

[Tom Lane]

Bruce Momjian [EMAIL PROTECTED] writes:
 I just tested gcc 2.95.3 on BSD/OS i386 and didn't see any change when
 using -g3 vs -g in the size of the binaries.

I saw the same with gcc 2.95.3 on HPUX.  The gcc manual for this version
does claim that -g3 dumps extra info, but perhaps that is only true in
certain object-file formats.

regards, tom lane

---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [HACKERS] How to tell if SQL function gets inlined?

[Tom Lane]

Bruce Momjian [EMAIL PROTECTED] writes:
 Joe Conway wrote:
 Is there any way, short of using a debugger with a strategically placed 
 breakpoint, to tell if a SQL function has been inlined?

 I think you will only see it with debug_print_plan enabled.

If the function is in the WHERE clause then you can see it in EXPLAIN
output.  Functions in the SELECT list you can't see without wading
through EXPLAIN VERBOSE (or equivalently debug_print_plan).

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] [BUGS] postgresql-7.4RC1 - unrecognized privilege type when selecting from information_schema.tables

[Tom Lane]

[EMAIL PROTECTED] writes:
select * from information_schema.tables;
ERROR:  unrecognized privilege type: RERERENCES

 Replacing the word RERERENCES with REFERENCES in
 the predicate has_table_privilege(c.oid,
 'RERERENCES'::text) near the end of the view SQL
 seems to correct the problem.

Good catch.  There are two other places with the same typo :-( (all
copied and pasted no doubt).

I've applied the patch but am loathe to force an initdb this late in
the beta cycle.  Any opinions out there?

regards, tom lane

---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faqs/FAQ.html

Re: [HACKERS] [BUGS] postgresql-7.4RC1 - unrecognized privilege type

[Bruce Momjian]

Tom Lane wrote:
 [EMAIL PROTECTED] writes:
 select * from information_schema.tables;
 ERROR:  unrecognized privilege type: RERERENCES
 
  Replacing the word RERERENCES with REFERENCES in
  the predicate has_table_privilege(c.oid,
  'RERERENCES'::text) near the end of the view SQL
  seems to correct the problem.
 
 Good catch.  There are two other places with the same typo :-( (all
 copied and pasted no doubt).
 
 I've applied the patch but am loathe to force an initdb this late in
 the beta cycle.  Any opinions out there?

Seems if the queries are failing in current, then fixing it can't hurt ---
it changes failed queries for those that do initdb.

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

---(end of broadcast)---
TIP 6: Have you searched our list archives?

   http://archives.postgresql.org

Re: [HACKERS] [BUGS] postgresql-7.4RC1 - unrecognized privilege type

[Marc G. Fournier]

On Sat, 8 Nov 2003, Tom Lane wrote:

 [EMAIL PROTECTED] writes:
 select * from information_schema.tables;
 ERROR:  unrecognized privilege type: RERERENCES

  Replacing the word RERERENCES with REFERENCES in
  the predicate has_table_privilege(c.oid,
  'RERERENCES'::text) near the end of the view SQL
  seems to correct the problem.

 Good catch.  There are two other places with the same typo :-( (all
 copied and pasted no doubt).

 I've applied the patch but am loathe to force an initdb this late in
 the beta cycle.  Any opinions out there?

Annoying as a spelling mistake is (and, from my read of the above, that is
all it is?), I don't thnk it warrants forcing an initdb ... unless I'm
missing a larger scope?


---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faqs/FAQ.html

Re: [HACKERS] [BUGS] postgresql-7.4RC1 - unrecognized privilege type when selecting from information_schema.tables

[Tom Lane]

Marc G. Fournier [EMAIL PROTECTED] writes:
 On Sat, 8 Nov 2003, Tom Lane wrote:
 I've applied the patch but am loathe to force an initdb this late in
 the beta cycle.  Any opinions out there?

 Annoying as a spelling mistake is (and, from my read of the above, that is
 all it is?), I don't thnk it warrants forcing an initdb ... unless I'm
 missing a larger scope?

The problem is that the spelling mistake causes the view to fail in the
right circumstances.  I believe you need to be a non-superuser and to do
select * from information_schema.tables when there is at least one
table that you don't own and have no privileges for.  That's not a very
unusual set of circumstances, so it verges on saying that that view is
unusable without the fix.  information_schema.views and
information_schema.columns have the identical problem.

We do not *have* to force initdb --- any adopters of beta5 or RC1 who
run into this problem can be told to recreate those views with the
corrected definitions.  A quick CREATE OR REPLACE VIEW as superuser
ought to do it.  So it's just an issue of cleanliness of the release.

regards, tom lane

---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings

Re: [HACKERS] [BUGS] postgresql-7.4RC1 - unrecognized privilege type

[Bruce Momjian]

Marc G. Fournier wrote:
 
 
 On Sat, 8 Nov 2003, Tom Lane wrote:
 
  [EMAIL PROTECTED] writes:
  select * from information_schema.tables;
  ERROR:  unrecognized privilege type: RERERENCES
 
   Replacing the word RERERENCES with REFERENCES in
   the predicate has_table_privilege(c.oid,
   'RERERENCES'::text) near the end of the view SQL
   seems to correct the problem.
 
  Good catch.  There are two other places with the same typo :-( (all
  copied and pasted no doubt).
 
  I've applied the patch but am loathe to force an initdb this late in
  the beta cycle.  Any opinions out there?
 
 Annoying as a spelling mistake is (and, from my read of the above, that is
 all it is?), I don't thnk it warrants forcing an initdb ... unless I'm
 missing a larger scope?

It must have a larger affect than just a spelling effect if he is seeing
an error:

 ERROR:  unrecognized privilege type: RERERENCES

I now see the question Tom had was wether we force an initdb.  Seems
this query select * from information_schema.tables; is broken without
it.  I think we should fix it but not force an initdb ---
information_schema is new and I am not sure how many people are using
it.

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings

Re: [HACKERS] [BUGS] postgresql-7.4RC1 - unrecognized privilege type

[Tom Lane]

Bruce Momjian [EMAIL PROTECTED] writes:
 I think we should fix it but not force an initdb ---
 information_schema is new and I am not sure how many people are using
 it.

Yeah, I'm leaning that way too.  We could publicize a script to fix the
problem in any beta5 or RC1 databases that people don't want to
re-initdb.

regards, tom lane

---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [HACKERS] [BUGS] postgresql-7.4RC1 - unrecognized privilege type

[Joe Conway]

Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:

I think we should fix it but not force an initdb ---
information_schema is new and I am not sure how many people are using
it.
Yeah, I'm leaning that way too.  We could publicize a script to fix the
problem in any beta5 or RC1 databases that people don't want to
re-initdb.
I agree, and this brings up a question that I've pondered before. Why do 
we ever *require* and initdb when only metadata has changed (i.e. the 
contents of the system catalogs, not catalog or page structure)?

ISTM that we ought to distinguish between catalog version, meaning 
something structural has changed, and catalog-data version which is 
correctible by running a script.

Joe

---(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] [BUGS] postgresql-7.4RC1 - unrecognized privilege type

[Tom Lane]

Joe Conway [EMAIL PROTECTED] writes:
 I agree, and this brings up a question that I've pondered before. Why do 
 we ever *require* and initdb when only metadata has changed (i.e. the 
 contents of the system catalogs, not catalog or page structure)?

In some cases we have to do it because there is a backend code change
that's dependent on the metadata change; that is, the backend will not
function correctly if you haven't fixed the catalog contents.  The
reverse direction (old backend, new catalogs) is also dangerous.  The
point of having a catalog version number is to ensure that the backend
and catalogs are in sync.

It's possible that we could devise some upgrade procedure that gets from
old backend/old catalogs to new backend/new catalogs without an initdb,
but I tend to think that this is basically the problem pg_upgrade is
supposed to solve.  I'm not eager to spend time on a pg_simple_upgrade
procedure.

regards, tom lane

---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings