On 7/15/07, Heikki Linnakangas [EMAIL PROTECTED] wrote:
Actually
storing InvalidOffsetNumber in lp_off is a bit bogus in the first place
since lp_off is unsigned, and InvalidOffsetNumber is -1, so I fixed that
as well.
I see InvalidOffsetNumber as 0 in off.h:26
#define
Andrew Dunstan wrote:
Here is my latest version of this patch. The good news is that it now
seems to work on Windows. Please review carefully (esp Magnus, Dave, Tom).
Hi Andrew,
I've eyeballed the code quite thoroughly and given it a whirl under
VC++. The only problem I found was that the
On Mon, Jul 23, 2007 at 03:36:21PM +0200, Magnus Hagander wrote:
I've been debugging some really weird crashes in libpq on win32, and I
think I've finally found the reason for the heap corruption that shows up
in msvc debug mode.
When run in debug mode, the runtime for msvc will *zero-pad
Dave Page wrote:
Andrew Dunstan wrote:
Here is my latest version of this patch. The good news is that it now
seems to work on Windows. Please review carefully (esp Magnus, Dave, Tom).
Hi Andrew,
I've eyeballed the code quite thoroughly and given it a whirl under
VC++. The only
http://www.sigaev.ru/misc/tsearch_core-0.58.gz
Changes since 0.52 version:
1) Introduce dictionary's template which contains only methods of dictionary and
can be managed only by superuser.
CREATE TEXT SEARCH DICTIONARY dictname
TEMPLATE dicttmplname
[OPTION opt_text ]
;
CREATE
Magnus Hagander [EMAIL PROTECTED] writes:
Actually coding up a patch for that was just a bunch of simple
search/replace ops. Attached is one that appears to work fine for me.
Was there any reason why this wasn't done before, or just nobody had the
time? If there was a reason, please let me
Simon Riggs wrote:
Alvaro,
As you note above there is some linkage between bit map indexes and
clustered indexes, so it seems like we'll either get both or neither.
I notice the GIT patch is being listed as under review by Alexey and
yourself. Are you actively working on this, or is
Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
Actually coding up a patch for that was just a bunch of simple
search/replace ops. Attached is one that appears to work fine for me.
Was there any reason why this wasn't done before, or just nobody had the
time? If there was a
Andrew Dunstan [EMAIL PROTECTED] writes:
Here is my latest version of this patch. The good news is that it now
seems to work on Windows. Please review carefully (esp Magnus, Dave, Tom).
The GUC arrangements for this patch are utterly broken. The reason for
the separation between
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Here is my latest version of this patch. The good news is that it now
seems to work on Windows. Please review carefully (esp Magnus, Dave, Tom).
The GUC arrangements for this patch are utterly broken.
As always I submit to
Simon Riggs [EMAIL PROTECTED] writes:
Thanks for reading. Updated version in new patch.
What was the reasoning for basing walwriter.c on autovacuum (which needs
to be able to execute transactions) rather than bgwriter (which does
not)? The shutdown logic in particular seems all wrong; you can't
On Mon, 2007-07-23 at 18:59 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
Thanks for reading. Updated version in new patch.
What was the reasoning for basing walwriter.c on autovacuum (which needs
to be able to execute transactions) rather than bgwriter (which does
not)?
Simon Riggs wrote:
Autovac is the most clean implementation of a special process, so seemed
like a good prototype. I'd thought I'd combed out any pointless code
though.
What, you mean there's pointless code in autovac? Hey, be sure to let
me know about it!
--
Alvaro Herrera
Simon Riggs wrote:
Here's v23, including all suggested changes, plus some reworking of the
transaction APIs to reduce the footprint of the patch.
What's the thing about doing the flush twice in a couple of comments in
calls to XLogBackgroundFlush? Are they just leftover comments from
older
Simon Riggs [EMAIL PROTECTED] writes:
On Mon, 2007-07-23 at 18:59 -0400, Tom Lane wrote:
The shutdown logic in particular seems all wrong; you can't have
a process connected to shared memory that is going to outlive the
postmaster.
It seemed to work cleanly when I tested it initially, but
Alvaro Herrera [EMAIL PROTECTED] writes:
What's the thing about doing the flush twice in a couple of comments in
calls to XLogBackgroundFlush? Are they just leftover comments from
older code?
I was wondering that too --- they looked like obsolete comments to me.
My current thinking BTW is
I wrote:
(BTW, in case you can't tell from the drift of my questions, I've
separated the patch into add background wal writer and add async
commit, and am working on the first half.)
I've committed the first half of that. Something that still needs
investigation is what the default
17 matches
Mail list logo