On Wed, 3 Mar 2004, Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > For tablespaces on OS's that don't support it, I think we will have to
> > store the path name in the file and read it via the backend. Somehow we
> > should cache those lookups.
>
> My feeling is that we need not
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > For tablespaces on OS's that don't support it, I think we will have to
> > store the path name in the file and read it via the backend. Somehow we
> > should cache those lookups.
>
> My feeling is that we need not support tablespaces
Bruce Momjian <[EMAIL PROTECTED]> writes:
> For tablespaces on OS's that don't support it, I think we will have to
> store the path name in the file and read it via the backend. Somehow we
> should cache those lookups.
My feeling is that we need not support tablespaces on OS's without
symlinks.
Gavin Sherry wrote:
> On Tue, 2 Mar 2004, Bruce Momjian wrote:
>
> > Gavin Sherry wrote:
> > > Actually, I think that's a pretty good idea :-). I'd solves a bunch of
> > > issues in the backend (postmaster start up can recurse through
> > > $PGDATA/tablespaces looking for postmaster.pid files) and
Andrew Dunstan wrote:
>
> I haven't had any other feedback on this patch that I posted. However,
> I'm a bit dissatisfied with it for a couple of reasons:
>
> . when a connection is logged we don't yet know the user and database,
> because we haven't processed the initial packet yet. That cause
Joe Conway <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> facing the possibility of an out-of-WAL-space panic. I suspect that we
>> cannot really do anything about that, but it's annoying. Any bright
>> ideas out there?
> Maybe specify an archive location (that of course could be on a separate
On Tue, 2 Mar 2004, Bruce Momjian wrote:
> Gavin Sherry wrote:
> > Actually, I think that's a pretty good idea :-). I'd solves a bunch of
> > issues in the backend (postmaster start up can recurse through
> > $PGDATA/tablespaces looking for postmaster.pid files) and will also assist
> > admins wit
Gavin Sherry wrote:
> Actually, I think that's a pretty good idea :-). I'd solves a bunch of
> issues in the backend (postmaster start up can recurse through
> $PGDATA/tablespaces looking for postmaster.pid files) and will also assist
> admins with complex configurations (perhaps).
Why are you ask
Josh Berkus wrote:
> #3: ALTER TABLE CHANGE TABLESPACE:
> This is strictly in the class of "would be a very nice & useful feature if
> it's not too difficult". ?
>
> Given how painful it is to drop & replace a table with multiple dependencies
> (on some databases, only possible by droping
Tom Lane wrote:
> "scott.marlowe" <[EMAIL PROTECTED]> writes:
> > Is possible / reasonable / smart and or dumb to look at implementing the
> > tablespaces as riding atop the initlocation handled stuff.
>
> In my mind, one of the main benefits of this work will be that we'll be
> able to get *rid*
Greg Stark wrote:
>
> > > I am expecting to hear some bleating about this from people whose
> > > preferred platforms don't support symlinks ;-). However, if we don't
>
> Well, one option would be to have the low level filesystem storage (md.c?)
> routines implement a kind of symlink themselves.
Tom Lane wrote:
One of the things that bothers me about the present PITR design is that
it presumes that individual WAL log segments can be kept until the
external archiver process feels like writing them somewhere. If there's
no guarantee that that happens within X amount of time, then you can't
Tom Lane wrote:
> Gavin Sherry <[EMAIL PROTECTED]> writes:
> >> Speaking of locking, can we do anything to prevent people from shooting
> >> themselves in the foot by changing active tablespaces? Are we even
> >> going to have a DROP TABLESPACE command, and if so what would it do?
>
> > Ahh. I fo
Tom Lane wrote:
> Gavin Sherry <[EMAIL PROTECTED]> writes:
> > A table space is a directory structure. The directory structure is as
> > follows:
> > [EMAIL PROTECTED] /path/to/tblspc]$ ls
> > OID1/ OID2/
> > OID1 and OID2 are the OIDs of databases which have created a table space
> > against
On Tue, 2 Mar 2004, Bruce Momjian wrote:
> Gavin Sherry wrote:
> > The actual creation of the table space will be done with:
> >
> > CREATE TABLE SPACE LOCATION ;
>
> Seems you should use CREATE TABLESPACE (no space) so it is more distinct
> from CREATE TABLE.
Oops. Typo.
>
> --
> Bruce M
Uhm. oops. I'll just crawl back under this rock for a bit longer before I
speak on this topic again. sorry.
--
greg
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
Joshua D. Drake wrote:
> > Is it possible to put WALs and CLOGs into different tablespaces? (maybe
> > different RAID systems). Some companies want that ...
>
> You can do this now, but it would be nice to be able to have it actually
> configurable versus the hacked linked method.
Agreed, but b
Gavin Sherry wrote:
> The actual creation of the table space will be done with:
>
> CREATE TABLE SPACE LOCATION ;
Seems you should use CREATE TABLESPACE (no space) so it is more distinct
from CREATE TABLE.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROT
Richard Huxton wrote:
> On Thursday 26 February 2004 10:07, Gavin Sherry wrote:
> >
> > CREATE TABLESPACE tbl1 LOCATION '/var/'
> >
> > which will result in something like '/var/123443' is a bad idea. Then
> > again, the user should know better. Comments?
>
> The LOCATION should have the same owne
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Right. This is in fact not a fatal situation, as long as you don't
>> run out of preallocated WAL space.
> Clearly running out of pre-allocated WAL space is likely to be the next
> issue. Running out of space in the first place is l
Greg Stark wrote:
So in this case if argL or argR are functions or other expressions with
unknown types it tries to figure out how to interpret them to produce the type
it's looking for. In other words, what type those expressions are depends on
what the expression expects. What would you do with "
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> How about allowing the specification on schemas and databases of
> different default tablespaces for TEMP, TABLE and INDEX?? Is there any
> point to that?
TEMP tables are not local to any particular schema, so it wouldn't make
sense to have
Greg Stark <[EMAIL PROTECTED]> writes:
> That would be nice and simple and clean, except that postgres's type system
> doesn't work that way. It works backwards from every other language. Instead
> of every variable and function return value having a rigid type and forcing
> the interpretation of t
I recently had to figure out what was different between the "live" schema
and the schema in cvs at work. This was a really painful process, and it
occurred to me that it wouldn't be terribly hard to write a perl program
to do it (I wound up using vim and diff). Is there interest in such a tool?
I c
I've been looking at implementing table spaces for 7.5. Some notes and
implementation details follow.
Ah sorry, other things you might need to consider:
Privileges on tablespaces:
GRANT USAGE ON TABLESPACE tbsp TO ...;
Different disk settings for different tablespaces (since they will
likely be
How easy is to to get cursor access to the indexes and fine grained
control of the transaction system, are their fairly clean internal
APIs I can leverage.
I'm not sure 'PostgreSQL' and 'fairly clean internal API' go together :P
Chris
---(end of broadcast)-
A table space parameter will be added to DDL commands which create
physical database objects (CREATE DATABASE/INDEX/TABLE/SEQUENCE) and to
CREATE SCHEMA. The associated routines, as well as the corresponding DROP
commands will need to be updated. Adding the ability to ALTER
TABLESPACE seems a lit
Joe Conway <[EMAIL PROTECTED]> writes:
> I wrestled with the same issue last year.
>
> Offhand I don't know how hard it would be to do, but I wonder if when we see:
>
>argL IN (argR)
>
> we might be able to determine if argL and argR are of the same type or if argR
> is an array of argL, a
hi all
Are there any other docs about tsearch2 except for the 3 docs in \contrib\tsearch2\docs
i want some tech docs on tsearch2 thank all
---(end of broadcast)---
TIP 8: explain analyze is your friend
On Tue, 2 Mar 2004, Robert Treat wrote:
> Wouldn't a FK on both tables be the appropriate schema? With the FK on
> contract being deffered?
Unfortunately, it appears that an FK must reference a unique column. So this:
ALTER TABLE contract ADD CONSTRAINT contract_must_have_a_plan
FOR
Tom Lane [mailto:[EMAIL PROTECTED]
> "Simon Riggs" <[EMAIL PROTECTED]> writes:
> > You're absolutely right about the not-knowing when you're out of
space
> > issue. However, if the xlog has been written then it is not
desirable,
> > but at least acceptable that the checkpoint/bgwriter cannot comple
Tom Lane wrote:
[ wanders away trying to remember that quote about "foolish consistency" ]
http://www.bartleby.com/59/3/foolishconsi.html
"A foolish consistency is the hobgoblin of little minds"
A great person does not have to think consistently from one day to the
next. This remark comes from
Joe Conway <[EMAIL PROTECTED]> writes:
> But then we need to decide, what happens when we see:
>argL IN (argR1, argR2, ...)
> and argRn data type is an array of argL data type? Do we check all the
> argRn elements individually and return true if any of them equal argL?
> I'd guess so.
This s
Dennis Bjorklund wrote:
The only reason I brought it up was that to me ANY and IN are pretty much
the same kind of operator. Up until now I thought that IN really was the
same as =ANY, but it isn't. I don't like that but of course I have to
accept it. I would rather have had some elem function/oper
On Tue, 2 Mar 2004, Joe Conway wrote:
> regression=# select 1 where array[1] in (array[1]);
> ?column?
> --
> 1
> (1 row)
>
> regression=# select 1 where array[1] in (array[1,2]);
> ?column?
> --
> (0 rows)
The only reason I brought it up was that to me ANY and IN ar
Tom Lane wrote:
> Jonathan Scott <[EMAIL PROTECTED]> writes:
> > I checked my system, and bison is reporting itself as 1.875. I am using SuSE 9.0,
> > and I did have to upgrade to get that configuration message to go away, AND to
> > make it compile.
>
> > Could you recommend a way I could get
Christopher Kings-Lynne wrote:
> > Why? You can reconstruct it with a simple "ANALYZE" command. Dumping
> > and restoring would mean nailing down cross-version assumptions about
> > what it contains, which doesn't seem real forward-looking...
>
> I seem to recall that people like that kind of th
"Greg Patnude" <[EMAIL PROTECTED]> writes:
> It would be really sweet in postgreSQL if we could apply the
> equivalent of a printf(columnname) to the table definition -- MS
> Access has what they call an "input mask" and it comes in really
> handy -- however -- I havent used Access for anthing seri
Dear Stephan,
> > Although it is POSSIBLE that this is fine, it is much more PROBABLE that
> > it is a bug, hence I just suggest to issue a mere simple basic plain
> > user-friendly little warning, what is quite different from issuing an
> > error. [...] Why not allowing that kind of approach in
On Tue, Mar 02, 2004 at 09:45:03 -0500,
Robert Treat <[EMAIL PROTECTED]> wrote:
>
> Wouldn't a FK on both tables be the appropriate schema? With the FK on
> contract being deffered?
No, since he only cares that there is at least one plan for a contract,
not a particular plan. You can do somet
On Tue, 2 Mar 2004, Fabien COELHO wrote:
>
> Hello Stephan,
>
> > > CREATE TABLE foo(fid INT4 NOT NULL PRIMARY KEY, ...);
> > > CREATE TABLE bla(fid INT2 REFERENCES foo, ...);
> > >
> > > The application will be fine till you enter fid=32767, and
> > > it inserts will fail in bla with fid=32768. M
Tom Lane wrote:
I don't have a strong opinion about "IN array", but am worried that
allowing it would create ambiguity about which interpretation is meant.
Is the left-hand side supposed to be compared against the whole array or
each array member?
That was exactly the problem. IN (array) does work
Hello Stephan,
> > CREATE TABLE foo(fid INT4 NOT NULL PRIMARY KEY, ...);
> > CREATE TABLE bla(fid INT2 REFERENCES foo, ...);
> >
> > The application will be fine till you enter fid=32767, and
> > it inserts will fail in bla with fid=32768. Much later on.
>
> Which is fine if bla is meant to store
On Tue, 2 Mar 2004, Fabien COELHO wrote:
>
> Hello again,
>
> I turn the discussion to the dev list as it seems more appropriate.
>
> So about the proposed patch to warn if foreign key type do not match the
> target key:
>
> > Stephan Szabo <[EMAIL PROTECTED]> writes:
> > > I'm really not sure tha
On Monday 01 March 2004 22:59, Curt Sampson wrote:
> On Mon, 1 Mar 2004, Tom Lane wrote:
> > Curt Sampson <[EMAIL PROTECTED]> writes:
> > > Can you explain how to do this? There is no reference to a plan in the
> > > contract table; the constraint just checks to see that, if a contract
> > > exists
but on postgres ftps mirrors are only full-packet, -base, -dosc, -opt, and
-test , where can be -devel or -libs ? ( use -base ? )
On Mon, 1 Mar 2004, Martin Marques wrote:
> El Lun 01 Mar 2004 11:11, ivan escribió:
> > hi,
> >
> > is there same packets (or sources to compile) only for client-sy
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
On 2 Mar 2004, Dave Cramer wrote:
> I can find rpms for rh8, rhel 3 but not rh9; is there some reason why
> they aren't necessary? Are rhel 3 binaries compatible with rh9?
Yes, you can install rhel3 binaries on rh9.
Regards,
- --
Devrim GUNDU
I can find rpms for rh8, rhel 3 but not rh9; is there some reason why
they aren't necessary? Are rhel 3 binaries compatible with rh9?
--
Dave Cramer
519 939 0336
ICQ # 14675561
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go
> "Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> > sizes all look about right, if someone wants to download and confirm?
>
> The full gz and bz2 tarballs match what I have here. Didn't check the
> partial tarballs.
I have tested postgresql-7.3.6.tar.gz. All regression tests
passed. This is Lin
Chad kirjutas R, 27.02.2004 kell 14:53:
> Is it possible for Postgres Btrees to support access by logical row number ?
WHat do you mean by "logical row number" ?
Hannu
---(end of broadcast)---
TIP 7: don't forget to increase your free
Hello again,
I turn the discussion to the dev list as it seems more appropriate.
So about the proposed patch to warn if foreign key type do not match the
target key:
> Stephan Szabo <[EMAIL PROTECTED]> writes:
> > I'm really not sure that it makes sense to warn for the fk cases where the
> > se
51 matches
Mail list logo
