I've got the CREATE TABLE AS restructuring almost finished, but came
across something that I could use some advice on. The current code
stores the "into" relation (and whether or not that relation has OIDs)
in the Query struct. This is ugly[1], but I'm not sure how to fix it.
The main reason Query
Gavin Sherry wrote:
> On Sun, 17 Oct 2004, Tom Lane wrote:
>
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > o remove non-portable TABLESPACE clause from CREATE TABLE and
> > > use a new default_tablespace SET variable
> >
> > I'm coming around to the conclusion that this is simply a bad
(Tom: this is not as severe a problem as I first thought)
If a client sends a V3 message that is sufficiently large to cause a
memory allocation failure on the backend when allocating space to read
the message, the backend gets out of sync with the protocol stream.
For example, sending this:
FE
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > o remove non-portable TABLESPACE clause from CREATE TABLE and
> > use a new default_tablespace SET variable
>
> I'm coming around to the conclusion that this is simply a bad idea.
>
> The problem with having such a SET vari
This has been fixed in current CVS.
---
Christopher Kings-Lynne wrote:
> There is a confusing bug in tablespaces. Here is examples:
>
> OK, let's create a table with the 3 possible tablespaces of indexes:
>
> test=# creat
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > o fix ambiguity for objects using default tablespaces
>
> > CREATE TABLE test(a int4) tablespace loc;
> > CREATE UNIQUE INDEX test_a_idx3 ON test(a) tablespace pg_default;
>
> > Index test_a_idx3 has a tablespace valu
On Mon, 2004-10-18 at 12:03, Tom Lane wrote:
> > We've always used -Wmissing-prototypes.
>
> We've always used both.
My apologies -- I don't know where I got the opposite impression.
> Hmm, it looks like -Wmissing-prototypes may be a superset of
> -Wmissing-declarations --- it seems to say that
Neil Conway <[EMAIL PROTECTED]> writes:
>>> -Wmissing-declarations ("Warn if a global function is defined without a
>>> previous declaration.")
>>
>> Hm? We have always used that one.
> We've always used -Wmissing-prototypes.
We've always used both. See Makefile.global.in:
ifeq ($(GCC), yes)
Neil Conway <[EMAIL PROTECTED]> writes:
> On Mon, 2004-10-18 at 04:13, Tom Lane wrote:
>> Do you have any actual evidence for that opinion? ISTM this is
>> dependent on a large set of assumptions about the CPU's bus behavior,
>> boiling down to the conclusion that an extra conditional branch is
>>
On Mon, 2004-10-18 at 03:50, Tom Lane wrote:
> > -Wmissing-declarations ("Warn if a global function is defined without a
> > previous declaration.")
>
> Hm? We have always used that one.
We've always used -Wmissing-prototypes. The documentation states that
-Wmissing-prototypes instructs GCC to:
On Mon, 2004-10-18 at 04:13, Tom Lane wrote:
> Do you have any actual evidence for that opinion? ISTM this is
> dependent on a large set of assumptions about the CPU's bus behavior,
> boiling down to the conclusion that an extra conditional branch is
> cheaper than a locked bus cycle.
I think the
On Sun, 17 Oct 2004, Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > o remove non-portable TABLESPACE clause from CREATE TABLE and
> > use a new default_tablespace SET variable
>
> I'm coming around to the conclusion that this is simply a bad idea.
I feel the same way fo
Bruce Momjian <[EMAIL PROTECTED]> writes:
> o remove non-portable TABLESPACE clause from CREATE TABLE and
> use a new default_tablespace SET variable
I'm coming around to the conclusion that this is simply a bad idea.
The problem with having such a SET variable is that it plays hob
Troels Arvin <[EMAIL PROTECTED]> writes:
> On Sun, 17 Oct 2004 18:08:00 -0400, Tom Lane wrote:
>> These do NOT mean the same thing.
> I'm having a hard time seeing the difference between DETERMINISTIC and
> IMMUTABLE.
Well, the spec is somewhat self-contradictory on the point, but I think
their i
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
I'm not sure if there is some nicely portable way around this. Any
suggestions?
Now that I think about it, we already had an open issue with tsearch2,
which is that the way it's doing this, a relocatable installation is
impossible
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
The problem is that on Windows, $(datadir) is typically a virtual Msys
path (or least typically it is for me) which is not understood by a
running backend,
Huh? Explain that in English please ... because I would think that what
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> I'm not sure if there is some nicely portable way around this. Any
> suggestions?
Now that I think about it, we already had an open issue with tsearch2,
which is that the way it's doing this, a relocatable installation is
impossible.
I think the most
On Sun, 17 Oct 2004 18:08:00 -0400, Tom Lane wrote:
>> I suggest that DETERMINISTIC be added as a synonym for IMMUTABLE and that
>> "NOT DETERMINISTIC" be added as an alias for VOLATILE in PostgreSQL's
>> grammar for CREATE FUNCTION.
>
> These do NOT mean the same thing.
I'm having a hard time s
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> The problem is that on Windows, $(datadir) is typically a virtual Msys
> path (or least typically it is for me) which is not understood by a
> running backend,
Huh? Explain that in English please ... because I would think that what
you are suggesting
Troels Arvin <[EMAIL PROTECTED]> writes:
> I suggest that DETERMINISTIC be added as a synonym for IMMUTABLE and that
> "NOT DETERMINISTIC" be added as an alias for VOLATILE in PostgreSQL's
> grammar for CREATE FUNCTION.
These do NOT mean the same thing.
regards, tom lane
Hello,
While reviewing PostgreSQL 8's SQL:2003 conformance (see the documentation
mailing list), I've come across a - possibly - easy-to-implement
conformance improvement for CREATE FUNCTION:
SQL:2003 uses the word DETERMINISTIC where PostgreSQL uses IMMUTABLE.
And SQL:2003 uses "NOT DETERMINISTI
The makefile for tsearch2 has this rule:
tsearch2.sql: tsearch.sql.in
sed -e 's,MODULE_PATHNAME,$$libdir/$(MODULE_big),g' \
-e 's,DATA_PATH,$(datadir)/contrib,g' $< >$@
The problem is that on Windows, $(datadir) is typically a virtual Msys
path (or least typically it is for me) which is
Tom Lane wrote:
I believe that the term "bitmap index" is also used with a different
meaning wherein it actually does describe a particular kind of on-disk
index structure, with one bit per table row.
IMHO building in-memory bitmaps (the first idea) is a very good idea to
pursue for Postgres. I'm
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Does anyone have a clue why?
Evidently your sscanf isn't setting errno for overflow --- look at
seg_atof() in segparse.y.
This code shows several other signs of severe brain death, actually,
like leaking 256 bytes on each call for
Bruce Momjian <[EMAIL PROTECTED]> writes:
> o fix ambiguity for objects using default tablespaces
> CREATE TABLE test(a int4) tablespace loc;
> CREATE UNIQUE INDEX test_a_idx3 ON test(a) tablespace pg_default;
> Index test_a_idx3 has a tablespace value of zero. pg_get_ind
<[EMAIL PROTECTED]> writes:
> If the resource owner is always responsible for releasing locked
> buffers, who releases the locks if the backend crashes?
The ensuing system reset takes care of that.
regards, tom lane
---(end of broadcast)---
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Does anyone have a clue why?
Evidently your sscanf isn't setting errno for overflow --- look at
seg_atof() in segparse.y.
This code shows several other signs of severe brain death, actually,
like leaking 256 bytes on each call for an error message buf
Seeing as I've missed the last N messages... I'll just reply to this
one, rather than each of them in turn...
Tom Lane <[EMAIL PROTECTED]> wrote on 16.10.2004, 18:54:17:
> I wrote:
> > Josh Berkus writes:
> >> First off, two test runs with OProfile are available at:
> >> http://khack.osdl.org/st
I am seeing this (among other things) when running the seg contrib
module regression:
***
*** 418,425
ERROR: bad seg representation
DETAIL: syntax error at or near "e"
SELECT '1e700'::seg AS seg;
! ERROR: syntax error
! DETAIL: numeric value 1e700 unrepresentable
--
-- t
I have annotated the open items:
---
PostgreSQL 8.0 Open Items
=
Current version at http://candle.pha.pa.us/cgi-bin/pgopenitems.
Change
Neil Conway <[EMAIL PROTECTED]> writes:
> Currently x86 is the only platform on which we do this -- ISTM that all
> the other platforms that implement spinlocks via atomic operations could
> benefit from this technique.
Do you have any actual evidence for that opinion? ISTM this is
dependent on
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Do we want to backport tighter security for plperl? In particular,
> insisting on Safe.pm >= 2.09 and removing the :base_io set of ops?
I'd vote not: 7.4.5 => 7.4.6 is not an update that people would expect
to break their plperl code ...
Neil Conway <[EMAIL PROTECTED]> writes:
> Recent versions of GCC support some additional warning flags that I
> think would be useful to enable for building PostgreSQL:
> -Wmissing-declarations ("Warn if a global function is defined without a
> previous declaration.")
Hm? We have always used t
Greg Stark <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> writes:
>> I think the cleanest solution is probably to add a
>> state flag indicating whether ParseComplete should generate a PGresult
>> or not.
> Adding a flag is going to be enough for synchronous queries. But it
> seems lik
Currently, the assembly for TAS() on x86 does a non-locking test before
using an atomic operation to attempt to acquire the spinlock:
__asm__ __volatile__(
" cmpb$0,%1 \n"
" jne 1f \n"
" lock\n"
Andrew Dunstan wrote:
Tom Lane wrote:
If anyone has any pending 7.4 fixes, getting them in in the next
few days would be a Good Plan.
Do we want to backport tighter security for plperl? In particular,
insisting on Safe.pm >= 2.09 and removing the :base_io set of ops?
And it would also be n
Tom Lane wrote:
If anyone has any pending 7.4 fixes, getting them in in the next
few days would be a Good Plan.
Do we want to backport tighter security for plperl? In particular,
insisting on Safe.pm >= 2.09 and removing the :base_io set of ops?
cheers
andrew
---(end
Recent versions of GCC support some additional warning flags that I
think would be useful to enable for building PostgreSQL:
-Wmissing-declarations ("Warn if a global function is defined without a
previous declaration.")
-Wdeclaration-after-statement (Recent versions of GCC allow declarations
38 matches
Mail list logo
