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 s
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
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 Postgre
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 u
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 whol
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 anyon
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., sta
"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 asi
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 t
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.
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 durin
* 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,
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 (pgsql-hackers@postgr
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, includin
15 matches
Mail list logo
