On Thu, Oct 2, 2008 at 6:46 PM, Bob Henkel [EMAIL PROTECTED] wrote:
Have you looked at creating a function in perl and creating a new
connection? Or using a dblink query which can create a new connection?
These two methods work. I have used them to insert to a log table regardless
of the
I stumbled upon LWN article where Patchworks patch management
system was discussed:
http://lwn.net/Articles/298592/
It collects patches from mailing list, plus replies to it,
and shows on a web page. Also keeps track of status.
Sounds exactly like whats needed for Postgres?
Patchworks own
On 02/10 17.29, Peter Eisentraut wrote:
Tom Lane wrote:
I think the right fix would be to convert those .sql files to
input/*.source files and have pg_regress substitute the absolute
directory names in them, like it is done for the backend.
Ugh. I don't think it's acceptable to make
Marko Kreen wrote:
I stumbled upon LWN article where Patchworks patch management
system was discussed:
http://lwn.net/Articles/298592/
It collects patches from mailing list, plus replies to it,
and shows on a web page. Also keeps track of status.
Sounds exactly like whats needed for
The numeric_big regression test was added many years ago for the NUMERIC
implementation but was not put in the default test set because it was
too slow. Now my tests show, it is really not slower than some of the
other slow tests (e.g., stats, tablespace), so perhaps time has caught
up with
Andrew Dunstan wrote:
Stefan Kaltenbrunner wrote:
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
Um, FKs could conflict with each other too, so that by itself isn't
gonna fix anything.
Good point. Looks like we'll need to make a list of can't run in
parallel
Hm, I wonder if we should have made the forks use a fork name instead of a
number. It sure would be nicer to have files name 12345.fsm instead of another
opaque number.
The other reason I thought of this is that if EDB or anyone else uses forks
for a private purpose then it would avoid the whole
On 10/3/08, Gregory Stark [EMAIL PROTECTED] wrote:
Hm, I wonder if we should have made the forks use a fork name instead of a
number. It sure would be nicer to have files name 12345.fsm instead of
another
opaque number.
The other reason I thought of this is that if EDB or anyone else
Peter Eisentraut [EMAIL PROTECTED] writes:
The numeric_big regression test was added many years ago for the NUMERIC
implementation but was not put in the default test set because it was
too slow. Now my tests show, it is really not slower than some of the
other slow tests (e.g., stats,
Marko Kreen [EMAIL PROTECTED] writes:
On 10/3/08, Gregory Stark [EMAIL PROTECTED] wrote:
The other reason I thought of this is that if EDB or anyone else uses forks
for a private purpose then it would avoid the whole issue of conflicts. The
best option right now would be to set aside a range
OK, I have a stupid question- torn pages are a problem, but only during
recovery. Recovery is (I assume) a fairly rare condition- if data
corruption is going to happen, it's most likely to happen during normal
operation. So why not just turn off CRC checksumming during recovery,
or at least
On Fri, Oct 3, 2008 at 3:36 PM, Brian Hurt [EMAIL PROTECTED] wrote:
OK, I have a stupid question- torn pages are a problem, but only during
recovery. Recovery is (I assume) a fairly rare condition- if data
corruption is going to happen, it's most likely to happen during normal
operation. So
Brian Hurt wrote:
OK, I have a stupid question- torn pages are a problem, but only during
recovery. Recovery is (I assume) a fairly rare condition- if data
corruption is going to happen, it's most likely to happen during normal
operation. So why not just turn off CRC checksumming during
* Decibel! [EMAIL PROTECTED] [081002 19:18]:
Well, it would be useful if whenever we magically decided it was time
to write out a page that had only hint-bit updates we generated WAL,
right? Even if it was just a no-op WAL record to ensure we had the
page image in the WAL.
Well, I'm
Andrew Dunstan wrote:
Overall result: baseline: 4h32m parallel: 0h 54m.
Awesome!!
--
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
--
Sent via pgsql-hackers mailing list
I'm just getting back around to this now. I guess I'm wondering if
someone could advise me on the best way of getting closer to a
committable patch.
The original patch just allows additional columns to be appended to
the previous column list (while disallowing all other sorts of
changes,
16 matches
Mail list logo
