Re: [PATCHES] [HACKERS] msvc, build and install with cygwin in the PATH

Andrew Dunstan schrieb: Hannes Eder wrote: -open($D, "dir /b $subdirs $spec |") || croak "Could not list $spec\n"; +open($D, "cmd /c dir /b $subdirs $spec |") || croak "Could not list $spec\n"; What the heck are we doing here anyway? We should be doing this a la Perl - calling out

Re: [PATCHES] [HACKERS] msvc, build and install with cygwin in the PATH

On Wed, May 30, 2007 at 12:09:05PM +0200, Hannes Eder wrote: > Andrew Dunstan schrieb: > >Hannes Eder wrote: > >>-open($D, "dir /b $subdirs $spec |") || croak "Could not list > >>$spec\n"; > >>+open($D, "cmd /c dir /b $subdirs $spec |") || croak "Could not > >>list $spec\n"; > >> > > > >

Re: [PATCHES] [HACKERS] msvc, build and install with cygwin in the PATH

Magnus Hagander schrieb: Are you actually *running* the script from inside cygwin? How else does it pick up the wrong command processor? I run the script within cmd.exe, but cygwin´s /usr/bin directory is in my PATH, therefor cygwin dir executable is in the PATH (/usr/bin/dir). Instead of ru

Re: [PATCHES] [pgsql-patches] Ctid chain following enhancement

On 5/29/07, Zdenek Kotala <[EMAIL PROTECTED]> wrote: I'm looking on your patch. I have one comment: If you have old tid and new tid you can easy compare if new tid points to different page? And if page is still same there is no reason to Unlock it and lock again. I think add inner loop somethi

Re: [PATCHES] [HACKERS] msvc, build and install with cygwin in the PATH

On Wed, May 30, 2007 at 01:56:24PM +0200, Hannes Eder wrote: > Magnus Hagander schrieb: > >Are you actually *running* the script from inside cygwin? How else does it > >pick up the wrong command processor? > > > I run the script within cmd.exe, but cygwin´s /usr/bin directory is in > my PATH, th

Re: [PATCHES] [pgsql-patches] Ctid chain following enhancement

Pavan Deolasee napsal(a): On 5/29/07, *Zdenek Kotala* <[EMAIL PROTECTED] > wrote: I'm looking on your patch. I have one comment: If you have old tid and new tid you can easy compare if new tid points to different page? And if page is still same there is

Re: [PATCHES] On patching without write access to CVS

Updated patch with suggested wording applied, attached. I did not modify FAQ_DEV.html because this doesn't seem to be an FAQ-level issue. --- Andrew Hammond wrote: > On May 14, 12:57 am, [EMAIL PROTECTED] (Peter Eisentraut)

Re: [PATCHES] [DOCS] OS/X startup scripts

Patch applied and moved to a separate osx directory. Thanks. --- David Fetter wrote: > Folks, > > The attached tarball should be unpacked in contrib/startup-scripts, > and supplants PostgreSQL.darwin and StartupParameters

Re: [PATCHES] WIP: 2nd-generation buffer ring patch

Tom Lane wrote: Updated version of Heikki's buffer ring patch, as per my comments here: http://archives.postgresql.org/pgsql-patches/2007-05/msg00449.php The COPY IN part of the patch is not there, pending resolution of whether we think it adds enough value to be worth uglifying heap_insert's AP

Re: [PATCHES] Seq scans status update

Tom Lane wrote: Heikki Linnakangas <[EMAIL PROTECTED]> writes: A heapscan would pin the buffer only once and hence bump its count at most once, so I don't see a big problem here. Also, I'd argue that buffers that had a positive usage_count shouldn't get sucked into the ring to begin with. Tru

Re: [PATCHES] WIP: 2nd-generation buffer ring patch

Heikki Linnakangas <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> The COPY IN part of the patch is not there, pending resolution of >> whether we think it adds enough value to be worth uglifying >> heap_insert's API for. > I ran a series of tests, and it looks like it's not worth it. Great, I'l

Re: [PATCHES] boolean <=> text explicit casts

On Mon, 2007-28-05 at 15:38 -0400, Tom Lane wrote: > More generally, I'm really hoping to get rid of bespoke text<->whatever > cast functions in favor of using datatypes' I/O functions. To what > extent can we make the boolean I/O functions serve for this? It seems > relatively painless on the in

Re: [PATCHES] Seq scans status update

On Tue, 2007-05-29 at 17:43 -0700, Jeff Davis wrote: > > Hmm. But we probably don't want the same buffer in two different > > backends' rings, either. You *sure* the sync-scan patch has no > > interaction with this one? > > > > I will run some tests again tonight, I think the interaction needs

Re: [PATCHES] Seq scans status update

Heikki Linnakangas <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> One other question: I see the patch sets the threshold for switching >> from normal to ring-buffer heapscans at table size = NBuffers. Why >> so high? I'd have expected maybe at most NBuffers/4 or NBuffers/10. >> If you don't wan

Re: [PATCHES] boolean <=> text explicit casts

Neil Conway wrote: > Attached is a revised version of this patch that modifies boolin() to > ignore leading and trailing whitespace. This makes text => boolean > trivial, but boolean => text is still distinct from boolout(). I'm not sure what your rationale was for creating lower-case words inste

Re: [PATCHES] Seq scans status update

Jeff Davis wrote: On Tue, 2007-05-29 at 17:43 -0700, Jeff Davis wrote: Hmm. But we probably don't want the same buffer in two different backends' rings, either. You *sure* the sync-scan patch has no interaction with this one? I will run some tests again tonight, I think the interaction needs

Re: [PATCHES] boolean <=> text explicit casts

On Wed, 2007-30-05 at 21:23 +0200, Peter Eisentraut wrote: > I'm not sure what your rationale was for creating lower-case words > instead of upper case, except for it looks nicer. Is there a technical > reason? There's no real technical reason: the standard says upper-case, but PG's general phi

Re: [PATCHES] COPY-able csv log outputs

Your patch has been added to the PostgreSQL unapplied patches list at: http://momjian.postgresql.org/cgi-bin/pgpatches It will be applied as soon as one of the PostgreSQL committers reviews and approves it. --- Gr

Re: [PATCHES] Seq scans status update

Heikki Linnakangas <[EMAIL PROTECTED]> writes: > I just ran a quick test with 4 concurrent scans on a dual-core system, > and it looks like we do "leak" buffers from the rings because they're > pinned at the time they would be recycled. Yeah, I noticed the same in some tests here. I think there

Re: [PATCHES] OS X startup script patch

Patch attached and applied. Thanks. --- Les Hill wrote: > Hi, > > I recently built and installed postgres 8.2.4 on my MBP (10.4.9). > Thanks for the great work! > > The existing startup script worked with one tweak, the

Re: [PATCHES] Seq scans status update

On Wed, 2007-05-30 at 15:56 -0400, Tom Lane wrote: > In > the sync-scan case the idea seems pretty bogus anyway, because the > actual working set will be N backends' rings not just one. I don't follow. Ideally, in the sync-scan case, the sets of buffers in the ring of different scans on the same r

Re: [PATCHES] Seq scans status update

Jeff Davis <[EMAIL PROTECTED]> writes: > On Wed, 2007-05-30 at 15:56 -0400, Tom Lane wrote: >> In the sync-scan case the idea seems pretty bogus anyway, because the >> actual working set will be N backends' rings not just one. > I don't follow. Ideally, in the sync-scan case, the sets of buffers i

Re: [PATCHES] Seq scans status update

On Wed, 2007-05-30 at 17:45 -0400, Tom Lane wrote: > According to Heikki's explanation here > http://archives.postgresql.org/pgsql-patches/2007-05/msg00498.php > each backend doing a heapscan would collect its own ring of buffers. > You might have a few backends that are always followers, never lea