Tom Lane wrote:
> Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> > Compatibility problems? CREATE INDEX isn't an SQL standard command is it?
>
> No, but it'll cause unnecessary cross-version compatibility issues for
> us.
It is true it isn't SQL standard, but I think our CREATE INDEX synt
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> When do you reckon 8.1.3 will be released?
We haven't really thought about it yet ... if you're desperate for that
tsearch2 patch, you could pull REL8_1_STABLE branch tip from CVS and use
that ...
regards, tom lane
---
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> Compatibility problems? CREATE INDEX isn't an SQL standard command is it?
No, but it'll cause unnecessary cross-version compatibility issues for
us.
regards, tom lane
---(end of broadcast)-
If you want it to be dumped by pg_dump (which is debatable IMHO) then
it MUST NOT be a syntax extension, it has to be driven by a GUC
variable, else we have compatibility problems with the dumps. We just
went through this with WITH/WITHOUT OIDS.
Compatibility problems? CREATE INDEX isn't an SQ
Hey guys,
When do you reckon 8.1.3 will be released? That has the massive speedup
on GiST index creation, right?
I'm planning on a major upgrade soon, but the greatest time in reload is
taken up by index creation time, so I'll hang out for 8.1.3.
Any ETA?
Chris
-
Hannu Krosing <[EMAIL PROTECTED]> writes:
> Does ALTER TABLE SET TABLESPACE lock the table
It had better ... see nearby discussion about relaxing locking for
TRUNCATE. Exactly the same problem that at commit we'd be cutting
the ground out from under any concurrent query.
Does ALTER TABLE SET TABLESPACE lock the table while copying data to new
location ?
If so, then does it lock the whole table, or just the tuples belonging
to currently copied 1G file ?
Hannu
---(end of broadcast)---
TIP 9: In ve
Tom Lane wrote:
> Bruce Momjian writes:
> > FYI, the shared memory address was originally relocatable by using
> > offsets to address it from the child, but now that we use fork() on
> > Unix, it isn't an issue, and Win32 seems to be OK.
>
> In the worst case we could go back to using offsets eve
[EMAIL PROTECTED] (Tom Lane) writes:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
>> Hmm, yeah, sounds useful. There's one implementation issue to notice
>> however, and it's that the autovacuum process dies and restarts for each
>> iteration, so there's no way for it to remember previous state un
Bruce Momjian writes:
> FYI, the shared memory address was originally relocatable by using
> offsets to address it from the child, but now that we use fork() on
> Unix, it isn't an issue, and Win32 seems to be OK.
In the worst case we could go back to using offsets everywhere, but I'm
really relu
Tom Lane wrote:
> Martijn van Oosterhout writes:
> > Hmm, are there no other ways that this problem can manifest itself?
> > ISTM that we're relying completely on the kernel to map it in the same
> > place each time. Maybe one day someone changes the startup procedure to
> > allocate some more mem
Martijn van Oosterhout writes:
> Hmm, are there no other ways that this problem can manifest itself?
> ISTM that we're relying completely on the kernel to map it in the same
> place each time. Maybe one day someone changes the startup procedure to
> allocate some more memory and it gets mapped som
On Wed, Feb 01, 2006 at 10:59:39AM -0500, Bruce Momjian wrote:
> * Attach process to shared data structures. If testing
> * EXEC_BACKEND on Linux, you must run this as root
> * before starting the postmaster:
> *
> * echo 0 >/proc/sys/kernel/ran
Tom Lane wrote:
> Bruce Momjian writes:
> >> - Should indexes remember their fillfactors when they are created?
> >> The last fillfactors will be used on next reindex.
>
> > They should remember, for sure, and REINDEX should use it. It think
> > this is similar to the ALTER TABLE ALTER [ COLUMN
Bruce Momjian writes:
>> - Should indexes remember their fillfactors when they are created?
>> The last fillfactors will be used on next reindex.
> They should remember, for sure, and REINDEX should use it. It think
> this is similar to the ALTER TABLE ALTER [ COLUMN ] ... SET STATISTICS
> func
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Hmm, yeah, sounds useful. There's one implementation issue to notice
> however, and it's that the autovacuum process dies and restarts for each
> iteration, so there's no way for it to remember previous state unless
> it's saved somewhere permanent, as
[EMAIL PROTECTED] (Alvaro Herrera) writes:
> Chris Browne wrote:
>
>> It strikes me as a slick idea for autovacuum to take on that
>> behaviour. If the daily backup runs for 2h, then it is quite futile
>> to bother vacuuming a table multiple times during that 2h period when
>> none of the tuples
FYI, this will be fixed in 8.1.3.
---
Jaime Casanova wrote:
> Hi,
>
> in my machine (win xp) i was trying to start psql (8.1.1) with
> log_min_messages to debug5 (just to see the messages :) but even the
> service start i c
ITAGAKI Takahiro wrote:
> Hi Hackers,
>
> I'm trying the following TODO item:
> [Indexes]
> - Add fillfactor to control reserved free space during index creation
>
> I have already made an patch and it seemed to work well.
Great.
> And now, I need advice on some issues.
>
> - Is it appr
Alvaro Herrera wrote:
Chris Browne wrote:
It strikes me as a slick idea for autovacuum to take on that
behaviour. If the daily backup runs for 2h, then it is quite futile
to bother vacuuming a table multiple times during that 2h period when
none of the tuples obsoleted during the 2h period wil
Chris Browne wrote:
> It strikes me as a slick idea for autovacuum to take on that
> behaviour. If the daily backup runs for 2h, then it is quite futile
> to bother vacuuming a table multiple times during that 2h period when
> none of the tuples obsoleted during the 2h period will be able to be
>
matthew@zeut.net ("Matthew T. O'Connor") writes:
> Legit concern. However one of the things that autovacuum is supposed to
> do is not vacuum tables that don't need it. This can result in an overal
> reduction in vacuum overhead. In addition, if you see that autovacuum is
> firing off vacuum com
My guess is that there is some really fast assembler for memory copy on
AIX, and only libc memset() has it. If you want, we can make
MEMSET_LOOP_LIMIT in c.h a configure value, and allow template/aix to
set it to zero, causing memset() to be always used.
Are you prepared to make this optimizatio
Kevin Grittner wrote:
> We found a bug in the code from my first patch. Since it was a low
> frequency, non-destructive type of problem for us, I was able to take my
> time and look over the task a little more closely. Attached is a patch
> which should come close to implementing the TODO. In pa
Bruce Momjian writes:
> Is it only implicit casts you are worried about? Do we have any of
> those left? All functions that take cidr also have an inet version, so
> I don't see how an implicit cast to cidr could happen.
The cast to cidr isn't implicit anymore anyway. What I currently have
it
Peter Eisentraut wrote:
> Bruce Momjian wrote:
> > I agree. Let's do the zeroing and see if people complain about it.
>
> I'm complaining. Losing data on a cast is not common behavior.
[ Sorry for the delay.]
OK, that's clear. :-)
I looked around to see if I could find any places where we im
Added code comment:
/*
* Attach process to shared data structures. If testing
* EXEC_BACKEND on Linux, you must run this as root
* before starting the postmaster:
*
* echo 0 >/proc/sys/kernel/randomize_va_space
*
* T
Hello,
Propably not. But You can use this patch
http://gorda.di.uminho.pt/community/pgsqlhooks/
regards
Pavel Stehule
HEY!!!
Are You going to implement some system triggers like in ORACLE i.e. "on
login" trigger
??
--
Best regards
LaroG
---(end of broadcast)-
HEY!!!
Are You going to implement some system triggers like in ORACLE i.e. "on
login" trigger
??
--
Best regards
LaroG
---(end of broadcast)---
TIP 6: explain analyze is your friend
Oops. 8.0, 8.1 and dev failed on Snake last night :-(
/D
-Original Message-
From: PG Build Farm [mailto:[EMAIL PROTECTED]
Sent: Wed 2/1/2006 2:08 AM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: PGBuildfarm member snake Branch REL8_0_STABLE Status changed from OK
to Make failure
30 matches
Mail list logo
