On Sat, 20 Apr 2002, Tom Lane wrote:
> >> I believe we do want to distinguish three states: live tuple, dead
> >> tuple, and empty space. Otherwise there will be cases where you're
> >> forced to move data immediately to collapse empty space, when there's
> >> not a good reason to except that yo
On Sun, Apr 21, 2002 at 03:46:07PM +0900, Curt Sampson wrote:
> On Sat, 20 Apr 2002, Tom Lane wrote:
>
> > Martijn van Oosterhout <[EMAIL PROTECTED]> writes:
> > > 2. If not, would patches be accepted to correct the situation?
> >
> > Go for it.
>
> Yes, please! I'd be happy to review and update
> Having per-transaction command IDs might allow us to reduce the
range of
> the t_cmin and t_cmax fields. Unfortunately, probably by not all
that
> much, since one doesn't want to limit the number of commands within
a
> single transaction to something as silly as 65536.
If you can figure out how
Curt Sampson <[EMAIL PROTECTED]> writes:
> If this is the case, would it be possible to number the commands
> per-transaction, rather than globally?
They are.
regards, tom lane
---(end of broadcast)---
TIP 4: Don't 'kill -9
I'm trying to (finally) get my rather extensive patches (mostly
addressing int8 versions of date/time storage) applied but am now having
trouble with the regression tests.
I'm sure this has been on the list, but I'm not recalling the
explanation or workaround. My guess is that it is related to co
Thomas Lockhart writes:
> I'm sure this has been on the list, but I'm not recalling the
> explanation or workaround. My guess is that it is related to collation
> troubles with the new locale-always-enabled feature. I've tended to
> never enable this stuff in the past.
>
> The first symptom is fa
> > The first symptom is failures in the char regression test...
> initdb --no-locale
Ooh. Thanks, that fixes it. Where would I have found this in the docs? I
was looking in the wrong place (in configure/build) rather than at
initdb. Should we have something in the release notes? I see (now that
"Rod Taylor" <[EMAIL PROTECTED]> writes:
> Is everyone Ok with the above? Or do we go about making an pg_fkey
> type table for tracking this stuff?
In general there ought to be a pg_constraint table that records all
types of constraints (not only foreign keys). We blew it once already
by making
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]]
> Sent: 19 April 2002 19:54
> To: Rod Taylor
> Cc: Hackers List
> Subject: Re: Really annoying comments...
>
>
> "Rod Taylor" <[EMAIL PROTECTED]> writes:
> > COMMENT ON DATABASE db IS 'Comment';
> > Now switch databases
Dave Page <[EMAIL PROTECTED]> writes:
>> I'm more inclined to rip it out ;-).
> Eeep! pgAdmin handles comments coming from multiple pg_description tables
> and it works very well (IMHO) in the pgAdmin UI. By all means make them work
> more sensibly in whatever way seems most appropriate - I'll
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]]
> Sent: 21 April 2002 19:45
> To: Dave Page
> Cc: Rod Taylor; Hackers List
> Subject: Re: [HACKERS] Really annoying comments...
>
>
> Dave Page <[EMAIL PROTECTED]> writes:
> >> I'm more inclined to rip it out ;-).
>
>
On Sun, 21 Apr 2002, Sander Steffann wrote:
> At the moment all our DBs are on one partition.
Not really, no. It's easy to put in a symlink to put a database on
another partition. It's easy for any object, for that matter, so long as
it's not the sort of thing that gets deleted and re-created by
Curt Sampson <[EMAIL PROTECTED]> writes:
> Yes, this uses a bit more CPU, but I think it's going to be a pretty
> trivial amount. It's a short list, and since you're touching the data
> anyway, it's going to be in the CPU cache. The real cost you'll pay is
> in the time to access the area of memor
On Sun, 21 Apr 2002, Tom Lane wrote:
> At this point you're essentially arguing that it's faster to recompute
> the list of item sizes than it is to read it off disk. Given that the
> recomputation would require sorting the list of item locations (with
> up to a couple hundred entries --- more t
I've applied patches to implement an int64-based data/time storage
scheme. I've also accumulated some other minor fixes, which result in an
initdb being required (sorry!).
Note that the *default* timestamp type is now TIMESTAMP WITHOUT TIME
ZONE. This is what we discussed previously for the trans
This makes the most sense. One could assume a user who doesn't have
access to a particular database shouldn't know what it's for either.
So making the comments global could be problematic in some cases.
I'll enforce this and send in a patch.
--
Rod
- Original Message -
From: "Dave Page"
btw, I've updated the regression tests and results for my platform, but
other platforms (e.g. Solaris) will need their results files updated...
- Thomas
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http:/
OK I know it's been beaten nearly to death, but no clear action has come
of it quite yet. We all seem to agree that there is some non-optimal
way in which the planner handles edge cases (cost wise). I don't
believe that there are any fundamental type faults in any of the logic
because we'd h
I'm seeing half a dozen gcc warnings as a result of these patches.
Do you want to fix 'em, or shall I?
regards, tom lane
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lo
> I'm seeing half a dozen gcc warnings as a result of these patches.
> Do you want to fix 'em, or shall I?
Where are they? I haven't noticed anything in the files I have changes;
are the warnings elsewhere?
- Thomas
---(end of broadcast)-
Thomas Lockhart <[EMAIL PROTECTED]> writes:
>> I'm seeing half a dozen gcc warnings as a result of these patches.
>> Do you want to fix 'em, or shall I?
> Where are they?
With fairly vanilla configure options, I get
make[3]: Entering directory `/home/postgres/pgsql/src/backend/parser'
gcc -O1 -
> > I'm seeing half a dozen gcc warnings as a result of these patches.
> Where are they?
More specifically, the *only* compiler warning I see (other than the
usual yacc/lex symbol warnings) is that a routine in gram.y,
set_name_needs_quotes(), is defined but not used. Don't know where that
routin
> With fairly vanilla configure options, I get...
Please be specific on the options and platform. I do *not* see these
warnings here with my "fairly vanilla configure options" ;)
Can't fix what I can't see, and we should track down what interactions
are happening to get these variables exposed..
Thomas Lockhart <[EMAIL PROTECTED]> writes:
> btw, I've updated the regression tests and results for my platform, but
> other platforms (e.g. Solaris) will need their results files updated...
I committed a fix for HPUX's horology file, and did some extrapolation
to produce a Solaris version; some
Thomas Lockhart <[EMAIL PROTECTED]> writes:
>> With fairly vanilla configure options, I get...
> Please be specific on the options and platform.
HPUX 10.20,
./configure --with-CXX --with-tcl --enable-cassert
regards, tom lane
---(end of broadcast
Thomas Lockhart wrote:
>>With fairly vanilla configure options, I get...
>
>
> Please be specific on the options and platform. I do *not* see these
> warnings here with my "fairly vanilla configure options" ;)
>
> Can't fix what I can't see, and we should track down what interactions
> are happ
Thomas Lockhart <[EMAIL PROTECTED]> writes:
> More specifically, the *only* compiler warning I see (other than the
> usual yacc/lex symbol warnings) is that a routine in gram.y,
> set_name_needs_quotes(), is defined but not used. Don't know where that
> routine came from, and afaik I didn't accide
> >> With fairly vanilla configure options, I get...
> > Please be specific on the options and platform.
> HPUX 10.20,
> ./configure --with-CXX --with-tcl --enable-cassert
Boy, how plain-vanilla. *My* configure line is all of
./configure --prefix=/home/thomas/local
But I do override some parame
Joe Conway <[EMAIL PROTECTED]> writes:
> but did *not* get the INT64CONST warning that Tom did. I'm using an
> updated Red Hat 7.2 box.
Probably it depends on compiler version? I'm using gcc 2.95.3.
regards, tom lane
---(end of broadcast)---
Thomas Lockhart <[EMAIL PROTECTED]> writes:
> I'm still not sure why the INT64CONST conflict does not show up as a
> warning on my machine, but looking at the code I'm not sure why we would
> ever have had two versions in the first place. Anyone want to take
> responsibility for consolidating it i
Tom Lane wrote:
> Joe Conway <[EMAIL PROTECTED]> writes:
>
>>but did *not* get the INT64CONST warning that Tom did. I'm using an
>>updated Red Hat 7.2 box.
>
>
> Probably it depends on compiler version? I'm using gcc 2.95.3.
>
could be:
[postgres@jec-linux pgsql]$ gcc -v
Reading specs from
> I think it was originally needed only for the CRC code, so we put it
> there to begin with. Clearly should be in a more widely used place now.
> Do you have any opinion whether c.h or int8.h is the Right Place?
> I'm still dithering about that.
In looking at the code, istm that the versions sh
Thomas Lockhart wrote:
>
> btw, I've updated gram.y and variable.c to suppress the reported
> warnings (which I *still* don't see here; that is very annoying).
>
FWIW, I'm still seeing:
gram.y:99: warning: `set_name_needs_quotes' declared `static' but never
defined
Joe
-
[EMAIL PROTECTED] (Thomas Lockhart) writes:
> Log message:
> Remove the definition for set_name_needs_quotes() on the assumption that
> it is now obsolete. Need some regression test cases to prove otherwise...
I agree that we don't want to reinstate that hack on the gram.y side.
Howev
> FWIW, I'm still seeing:
> gram.y:99: warning: `set_name_needs_quotes' declared `static' but never
> defined
Ack. Sloppy patching. Should be fixed now...
- Thomas
---(end of broadcast)---
TIP 2: you can get off all lists at once
> I agree that we don't want to reinstate that hack on the gram.y side.
> However, it seems to me way past time that we did what needs to be done
> with variable.c --- ie, get rid of it. All these special-cased
> variables should be folded into GUC.
Or in some cases into pg_database? We might wa
Thomas Lockhart writes:
> But I do override some parameters in my Makefile.custom:
>
> CFLAGS+= -g -O0 -DUSE_ASSERT_CHECKING
If you use -O0 then you miss most of the interesting warnings.
--
Peter Eisentraut [EMAIL PROTECTED]
---(end of broadcast)---
> > But I do override some parameters in my Makefile.custom:
> > CFLAGS+= -g -O0 -DUSE_ASSERT_CHECKING
> If you use -O0 then you miss most of the interesting warnings.
?? Not in this case. afaik -O0 suppresses most optimizations (and hence
does not reorder instructions, which is why I use it for
Michael Loftis <[EMAIL PROTECTED]> writes:
> Also I'd also like to know if there is a way to get the planner to burp
> out all the possible plans it considered before selecting a final plan
> or do I need to do a little surgery to get that done?
You can define OPTIMIZER_DEBUG but the interface
Thomas Lockhart <[EMAIL PROTECTED]> writes:
> But I do override some parameters in my Makefile.custom:
> CFLAGS+= -g -O0 -DUSE_ASSERT_CHECKING
>> If you use -O0 then you miss most of the interesting warnings.
> ?? Not in this case. afaik -O0 suppresses most optimizations
In particular, you don't
Thomas Lockhart <[EMAIL PROTECTED]> writes:
>> However, it seems to me way past time that we did what needs to be done
>> with variable.c --- ie, get rid of it. All these special-cased
>> variables should be folded into GUC.
> Or in some cases into pg_database? We might want some of this to trav
...
> Ah, but we *have* that ability right now; see Peter's recent changes
> to support per-database and per-user GUC settings. The functionality
> available for handling GUC-ified variables is now so far superior to
> plain SET that it's really foolish to consider having any parameters
> that ar
Thomas Lockhart wrote:
>>FWIW, I'm still seeing:
>>gram.y:99: warning: `set_name_needs_quotes' declared `static' but never
>>defined
>
>
> Ack. Sloppy patching. Should be fixed now...
>
> - Thomas
Yup, did the trick.
Thanks,
Joe
---(end of broadca
...
> In particular, you don't get "unused variable" and "variable may not
> have been set before being used" warnings at -O0, because the
> control-flow analysis needed to emit those warnings is not done at -O0.
Right. The point is that I don't get those (apparently) with -O2 either,
with my par
Tom Lane wrote:
>Michael Loftis <[EMAIL PROTECTED]> writes:
>
>>Also I'd also like to know if there is a way to get the planner to burp
>>out all the possible plans it considered before selecting a final plan
>>or do I need to do a little surgery to get that done?
>>
>
>You can define OPTIMIZ
Thomas Lockhart wrote:
>>>But I do override some parameters in my Makefile.custom:
>>>CFLAGS+= -g -O0 -DUSE_ASSERT_CHECKING
>>>
>>If you use -O0 then you miss most of the interesting warnings.
>>
>
>?? Not in this case. afaik -O0 suppresses most optimizations (and hence
>does not reorder instru
Michael Loftis <[EMAIL PROTECTED]> writes:
> IE I'd like to have the information come back as say a notice or maybe
> as extra information for an EXPLAIN for my purposes, but unless there is
> interest, consensus on how it should be done, and a TODO item made of
> it, I won't be making a patch
...
> regression=# set seed to 1,2;
> server closed the connection unexpectedly
> (crash is due to assert failure)
Now that I look, the assert is one I put in explicitly to catch multiple
arguments! I wasn't sure what the behavior *should* be, though I could
have done worse than simply checking f
Hmm. In looking at SET, why couldn't we develop this as an extendable
capability a la pg_proc? If PostgreSQL knew how to link up the set
keyword with a call to a subroutine, then we could go ahead and call
that routine generically, right? Do the proposals on the table call for
this kind of impleme
Thomas Lockhart <[EMAIL PROTECTED]> writes:
> Hmm. In looking at SET, why couldn't we develop this as an extendable
> capability a la pg_proc?
Well, my thoughts were along the line of providing specialized parsing
subroutines tied to specific GUC variables. There already are
parse_hook and assig
Thomas Lockhart writes:
> Not sure. Peter would like to change the SET DATESTYLE support if I
> remember correctly. But I've gotten the impression, perhaps wrongly,
> that this extends to changing features in dates and times beyond style
> settings. If it is just the two-dimensional nature of the
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> The only thing that I had suggested on occasion was that if nontrivial
> work were to be put into SET DATESTYLE, we might want to consider if a
> certain amount of "cleanup" could be done at the same time. For example,
> the particular date styles ha
...
> If you're suggesting setting up an actual database table, I'm not
> sure I see the point. Any system parameter is going to have to be
> tied to backend code that knows what to do with the parameter, so
> it's not like you can expect to do anything useful purely by adding
> table entries. T
> > > The first symptom is failures in the char regression test...
> > initdb --no-locale
>
> Ooh. Thanks, that fixes it. Where would I have found this in the docs? I
> was looking in the wrong place (in configure/build) rather than at
> initdb. Should we have something in the release notes? I se
I read a thread about table lock timeout but don't
know whether anything has been done about it.
Here is what I'd like to do:
I don't want my transactions to be on hold for too
long so I'd like to use a syntax I use on INFORMIX already:
SET LOCK MODE TO [WAIT [second] | NOT
WAIT]
I'm using
> and two macros:
>
> RECURSE_OVER_CHILDREN(relid);
> AlterTableDoSomething(childrel,...);
> RECURSE_OVER_CHILDREN_END;
>
> (this seems more straightforward than passing the text of the function
> call as a macro parameter).
The above all looks fine. The other stuff I wouldn't really know a
> Right. The point is that I don't get those (apparently) with -O2 either,
> with my particular compiler. Hmm. Actually, I *do* get those if I make
> sure that some of the other options are set too; my quick test added -O2
> but left out some of the -w switches. OK, never mind...
btw, now that I'
Tom Lane writes:
[ All the rest looks good to me. ]
> Databases have two grantable rights: CREATE allows creating new regular
> (permanent) schemas within the database, while TEMP allows creation of
> a temp schema (and thus temp tables).
Couldn't the temp schema be permanent (and unremovable),
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane writes:
>> Databases have two grantable rights: CREATE allows creating new regular
>> (permanent) schemas within the database, while TEMP allows creation of
>> a temp schema (and thus temp tables).
> Couldn't the temp schema be permanent (an
On FreeBSD/Alpha, current CVS:
gmake -C common SUBSYS.o
gmake[4]: Entering directory `/home/chriskl/pgsql/src/backend/access/common'
gcc -pipe -O -g -Wall -Wmissing-prototypes -Wmissing-declarations -I../../..
/../src/include -c -o heaptuple.o heaptuple.c -MMD
In file included from ../../../../
> On FreeBSD/Alpha, current CVS:
...
> ../../../../src/include/utils/int8.h:35: warning: `INT64CONST' redefined
> ../../../../src/include/utils/pg_crc.h:85: warning: this is the location of
> the previous definition
afaict this is OK (that is, the compiled code should work) until we get
the defin
61 matches
Mail list logo
