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
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
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
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
*
*
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
Bruce Momjian pgman@candle.pha.pa.us 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
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
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
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 commands
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
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
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 appropriate
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
[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 obsoleted
Bruce Momjian pgman@candle.pha.pa.us 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
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us 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
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 the
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
Martijn van Oosterhout kleptog@svana.org 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
Tom Lane wrote:
Martijn van Oosterhout kleptog@svana.org 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
Bruce Momjian pgman@candle.pha.pa.us 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,
[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 unless
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us 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
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
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.
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
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
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
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
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 syntax
30 matches
Mail list logo
