Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> I believe Itagaki-san's motivation for tackling this in the LDC patch
> was the fact that it can fsync the same file many times, and in the
> worst case go to an endless loop, and adding delays inside the loop
> makes it much more likely. After th
Tom Lane wrote:
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
Ok. Perhaps we should not use the canceled-flag but just remove the
entry from pendingOpsTable like we used to when mdsync_in_progress isn't
set.
I'm not thrilled about that; it seems overly intricate, and won't the
LDC patch make
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Ok. Perhaps we should not use the canceled-flag but just remove the
> entry from pendingOpsTable like we used to when mdsync_in_progress isn't
> set.
I'm not thrilled about that; it seems overly intricate, and won't the
LDC patch make it mostly us
Tom Lane wrote:
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
My first thought is that the cycle_ctr just adds extra complexity. The
canceled-flag really is the key in Takahiro-san's patch, so we don't
need the cycle_ctr anymore.
We don't have to have it in the sense of the code not working
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> My first thought is that the cycle_ctr just adds extra complexity. The
> canceled-flag really is the key in Takahiro-san's patch, so we don't
> need the cycle_ctr anymore.
We don't have to have it in the sense of the code not working without it,
b
Tom Lane wrote:
I wrote:
Actually, on second look I think the key idea here is Takahiro-san's
introduction of a cancellation flag in the hashtable entries, to
replace the cases where AbsorbFsyncRequests can try to delete entries.
What that means is mdsync() doesn't need an outer retry loop at al
I wrote:
> I fooled around with this idea and came up with the attached patch.
> It seems to do what's intended but could do with more eyeballs and
> testing before committing. Comments please?
Earlier I said that I didn't want to back-patch this change, but on
looking at the CVS history I'm reco
I wrote:
> Actually, on second look I think the key idea here is Takahiro-san's
> introduction of a cancellation flag in the hashtable entries, to
> replace the cases where AbsorbFsyncRequests can try to delete entries.
> What that means is mdsync() doesn't need an outer retry loop at all:
I foole
I wrote:
> This patch looks fairly sane to me; I have a few small gripes about
> coding style but that can be fixed while applying. Heikki, you were
> concerned about the cycle-ID idea; do you have any objection to this
> patch?
Actually, on second look I think the key idea here is Takahiro-san's
Patch committed. Thanks.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
> On 4/6/07, Tatsuo Ishii <[EMAIL PROTECTED]> wrote:
> >
> >
> > BTW, is anybody working on enabling the fill factor to the tables used
> > by pgbench? 8.3 will introduce HOT, and I think adding the feature
> > will make it easier to tes
On 4/6/07, Tatsuo Ishii <[EMAIL PROTECTED]> wrote:
BTW, is anybody working on enabling the fill factor to the tables used
by pgbench? 8.3 will introduce HOT, and I think adding the feature
will make it easier to test HOT.
Please see if the attached patch looks good. It adds a new -F option
w
Peter Eisentraut wrote:
> Mike Rylander wrote:
>> A related question, however: Will the XML features being included in
>> 8.3 support namespace prefix registration?
>
> That is certainly the plan.
Let me bounce my ostrich (sp?) head up here and say, thanks for your
work on this Peter.
Joshua D.
Mike Rylander wrote:
> A related question, however: Will the XML features being included in
> 8.3 support namespace prefix registration?
That is certainly the plan.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of broadcast)---
On 3/22/07, Tom Lane <[EMAIL PROTECTED]> wrote:
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Peter Eisentraut wrote:
>> I was hoping that we're deprecating contrib/xml2, so I wouldn't add more
>> features to it.
> Author states:
>> I understand that XML support is planned and at least partially
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Peter Eisentraut wrote:
>> I was hoping that we're deprecating contrib/xml2, so I wouldn't add more
>> features to it.
> Author states:
>> I understand that XML support is planned and at least partially
>> implemented for 8.3, but many production insta
Dave Page wrote:
> Bruce Momjian wrote:
> > Peter Eisentraut wrote:
> >> I was hoping that we're deprecating contrib/xml2, so I wouldn't add more
> >> features to it.
> >
> > Author states:
> >
> >> I understand that XML support is planned and at least partially
> >> implemented for 8.3, but man
Bruce Momjian wrote:
> Peter Eisentraut wrote:
>> I was hoping that we're deprecating contrib/xml2, so I wouldn't add more
>> features to it.
>
> Author states:
>
>> I understand that XML support is planned and at least partially
>> implemented for 8.3, but many production instances will be unab
Peter Eisentraut wrote:
> Bruce Momjian wrote:
> > 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.
>
> I was ho
Bruce Momjian wrote:
> 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.
I was hoping that we're deprecating contrib/xml2,
Applying newest version of this patch now; still needs documentation.
---
Nikolay Samokhvalov wrote:
> On 3/5/07, Nikolay Samokhvalov <[EMAIL PROTECTED]> wrote:
> > On 3/4/07, Nikolay Samokhvalov <[EMAIL PROTECTED]> wrote:
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.
---
Mi
On Mon, 2007-02-26 at 23:07 -0500, Tom Lane wrote:
> "Simon Riggs" <[EMAIL PROTECTED]> writes:
> > On Mon, 2007-02-26 at 18:14 -0500, Tom Lane wrote:
> >> What does this accomplish other than adding syntactic sugar over a
> >> feature that really doesn't work well anyway?
>
> > This patch doesn't
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am playing with this now ... sorry for delay ...
- --On Wednesday, February 28, 2007 12:58:04 -0500 Tom Lane <[EMAIL PROTECTED]>
wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
>> Joshua D. Drake wrote:
>>> We should add this to the mailing list
3:23 PM
To: John Bartlett
Cc: pgsql-hackers@postgresql.org; pgsql-patches@postgresql.org; 'Heikki
Linnakangas'
Subject: Re: [HACKERS] [PATCHES] - WIP Patch Updatable Cursor
On Wed, 28 Feb 2007, John Bartlett wrote:
> Hi,
>
> A list of ctids is stored in the file.
I would have
FAST PostgreSQL wrote:
> On Thu, 1 Mar 2007 04:28, Bruce Momjian wrote:
>> I have added this to the developer's FAQ to clarify the situtation of
>> posting a patch:
>>
>> PostgreSQL is licensed under a BSD license. By posting a patch
>> to the public PostgreSQL mailling lists, you are givi
On Thu, 1 Mar 2007 04:28, Bruce Momjian wrote:
> I have added this to the developer's FAQ to clarify the situtation of
> posting a patch:
>
> PostgreSQL is licensed under a BSD license. By posting a patch
> to the public PostgreSQL mailling lists, you are giving the PostgreSQL
> Global
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Joshua D. Drake wrote:
>> We should add this to the mailing list signup pages and the welcome
>> pages to the lists.
> Yep, good idea. Marc?
For -patches and -hackers, I agree. It seems a bit legalistic and
off-putting for the general lists, though.
Bruce Momjian wrote:
> I have added this to the developer's FAQ to clarify the situtation of
> posting a patch:
>
> PostgreSQL is licensed under a BSD license. By posting a patch
> to the public PostgreSQL mailling lists, you are giving the PostgreSQL
> Global Development Group the no
Joshua D. Drake wrote:
> Bruce Momjian wrote:
> > I have added this to the developer's FAQ to clarify the situtation of
> > posting a patch:
> >
> > PostgreSQL is licensed under a BSD license. By posting a patch
> > to the public PostgreSQL mailling lists, you are giving the PostgreSQL
>
I have added this to the developer's FAQ to clarify the situtation of
posting a patch:
PostgreSQL is licensed under a BSD license. By posting a patch
to the public PostgreSQL mailling lists, you are giving the PostgreSQL
Global Development Group the non-revokable right to distribute
> > Not that I think that anyone owning both a law degree and a computer
> > in 2007 should legitimately be able to plead innocence here. FAST
> > Australia's lawyers are making themselves look like idiots, and the
> > same for every other company tacking on such notices. I think the
> > real bot
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> Well the problem is, it isn't the guy that sent the patch that is the
> idiot. That guys has zero control over the matter, the signature is
> going to be tacked on at the MTA level.
Sure, I know that and you know that. The problem we have to worry a
Tom Lane wrote:
> "Joshua D. Drake" <[EMAIL PROTECTED]> writes:
>> ... In regards to your idea of a filter, there is no reason why
>> we couldn't install a filter that checks for signatures with specific
>> legal words and strips said signature automatically, responding to the
>> sender that we did
> Not that I think that anyone owning both a law degree and a computer
> in 2007 should legitimately be able to plead innocence here. FAST
> Australia's lawyers are making themselves look like idiots, and the
> same for every other company tacking on such notices. I think the
> real bottom line
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> ... In regards to your idea of a filter, there is no reason why
> we couldn't install a filter that checks for signatures with specific
> legal words and strips said signature automatically, responding to the
> sender that we did so.
The problem is t
>> Yes, I do. If there is an explicit claim, like an email footer or a
>> copyright in the code, we do try to nail that down.
>
> AFAICT, the footer in question tries to make it illegal for us even to
> have the message in our mail archives. If I were running the PG lists,
> I would install fil
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Neil Conway wrote:
>> For the case in question, sure, requiring some clarification from FJ
>> would be reasonable. But more broadly, my point is that I think you're
>> fooling yourself if you think that requiring a disclaimer or explicit
>> transfer of co
On Wed, 28 Feb 2007, John Bartlett wrote:
> Hi,
>
> A list of ctids is stored in the file.
I would have thought these would be stored in memory. If the set got
large, you'd use a temporary file the way other systems which overflow to
disk do?
>
> The file is used to store the ctids during an upd
Neil Conway wrote:
> On Tue, 2007-02-27 at 16:20 -0800, Joshua D. Drake wrote:
> > Thus we may literally not have rights to the code. Do you really want to
> > go down the path of in 2 years, Fujitsu (No offense Fujitsu), but you
> > are the topic) decides that the code they provided is owned by th
On Tue, 2007-02-27 at 16:20 -0800, Joshua D. Drake wrote:
> Thus we may literally not have rights to the code. Do you really want to
> go down the path of in 2 years, Fujitsu (No offense Fujitsu), but you
> are the topic) decides that the code they provided is owned by them and
> they didn't give u
Neil Conway wrote:
> On Tue, 2007-02-27 at 14:52 -0800, Joshua D. Drake wrote:
>> Gonna have to concur with that. Not that the sig is legally binding
>> anyway, we do need to have a disclaimer in the email stating that you
>> are assigning to PGDG
>
> I think it's pretty silly to start caring abou
Neil Conway wrote:
> On Tue, 2007-02-27 at 14:52 -0800, Joshua D. Drake wrote:
> > Gonna have to concur with that. Not that the sig is legally binding
> > anyway, we do need to have a disclaimer in the email stating that you
> > are assigning to PGDG
>
> I think it's pretty silly to start caring a
On Tue, 2007-02-27 at 14:52 -0800, Joshua D. Drake wrote:
> Gonna have to concur with that. Not that the sig is legally binding
> anyway, we do need to have a disclaimer in the email stating that you
> are assigning to PGDG
I think it's pretty silly to start caring about this now. Do you think
tha
Bruce Momjian wrote:
> FYI, I am not going to be comfortable accepting a final patch that
> contains this email signature:
>
> This is an email from Fujitsu Australia Software Technology Pty Ltd, ABN
> 27 003 693 481. It is confidential to the ordinary user of the email
> address
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> On Mon, 2007-02-26 at 18:14 -0500, Tom Lane wrote:
>> What does this accomplish other than adding syntactic sugar over a
>> feature that really doesn't work well anyway?
> This patch doesn't intend to implement group commit. I've changed the
> meaning of
Based on this patch review, I am removing the patch from the patch
queue and requiring a resubmission.
---
Tom Lane wrote:
> Dhanaraj M <[EMAIL PROTECTED]> writes:
> > Sorry for resubmitting this patch.
> > Just now I found
Pavel Stehule wrote:
> >OK, where are we on this patch?
>
> without changes. This task have to do anybody who better know PostgreSQL
> cache system than me.
How about you submit a version without any caching, but which works
correctly; and we worry about optimizations later?
I can update and
Pavel Stehule wrote:
> >OK, where are we on this patch?
>
> without changes. This task have to do anybody who better know PostgreSQL
> cache system than me.
How about you submit a version without any caching, but which works
correctly; and we worry about optimizations later?
> >---
OK, where are we on this patch?
without changes. This task have to do anybody who better know PostgreSQL
cache system than me.
Regards
Pavel
---
Pavel Stehule wrote:
>
>
> >
> >"Pavel Stehule" <[EMAIL PROTECTED]> wr
Full_page_compress is not intended to use with PITR slave, but for the
case to keep both online backup and archive log for archive recovery,
which is very popular PostgreSQL operation now.
I've just posted my evaluation for the patch as a reply for another
thread of the same proposal (sorry, I cre
OK, where are we on this patch?
---
Pavel Stehule wrote:
>
>
> >
> >"Pavel Stehule" <[EMAIL PROTECTED]> writes:
> > >> This patch doesn't seem to cope with cases where the supplied tuple has
> > >> the wrong number of colu
Tom Lane wrote:
> Koichi Suzuki <[EMAIL PROTECTED]> writes:
>> Tom Lane wrote:
>>> Doesn't this break crash recovery on PITR slaves?
>
>> Compressed archive log contains the same data as full_page_writes off
>> case. So the influence to PITR slaves is the same as full_page_writes off.
>
> Right
Koichi Suzuki <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Doesn't this break crash recovery on PITR slaves?
> Compressed archive log contains the same data as full_page_writes off
> case. So the influence to PITR slaves is the same as full_page_writes off.
Right. So what is the use-case f
Tom Lane wrote:
> Koichi Suzuki <[EMAIL PROTECTED]> writes:
>> Here's an idea and a patch for full page writes improvement.
>
>> Idea:
>> (1) keep full page writes for ordinary WAL, make them available during
>> the crash recovery, -> recovery from inconsistent pages which can be
>> made at the cr
FYI, Neil has corrected this in CVS HEAD.
---
Tom Lane wrote:
> Neil Conway <[EMAIL PROTECTED]> writes:
> > On Mon, 2006-09-04 at 15:19 -0400, Tom Lane wrote:
> >> AFAICT it's just junk. It happens to be the input times
> >
Roman Kononov wrote:
> On 12/27/2006 01:15 PM, Tom Lane wrote:
> > I'm not convinced that you're fixing things so much as doing your best
> > to destroy IEEE-compliant float arithmetic behavior.
> >
> > I think what we should probably consider is removing CheckFloat4Val
> > and CheckFloat8Val alto
On Fri, 2007-01-12 at 11:44 -0500, Bruce Momjian wrote:
> I think the right approach is to look at our existing code and come up
> with places we want them, and add them in one shot. Doing thing
> in small parts doesn't work too well with a project this size.
Will do.
--
Simon Riggs
Simon Riggs wrote:
> On Thu, 2007-01-11 at 12:37 -0500, Bruce Momjian wrote:
>
> > The trace probe was incorrect
>
> Yes, incomplete, no doubt. On that point you were 100% right to reject.
>
> > and kind of at an odd place. I don't
> > think we want to go down the road of throwing trace in eve
On Thu, Jan 11, 2007 at 11:10:38PM +, Simon Riggs wrote:
> On Thu, 2007-01-11 at 17:06 +, Gregory Stark wrote:
> > Having a CRC in WAL but not in the heap seems kind of pointless.
>
> Yes...
>
> > If your
> > hardware is unreliable the corruption could anywhere.
>
> Agreed.
I thought
On Thu, 2007-01-11 at 17:06 +, Gregory Stark wrote:
> Having a CRC in WAL but not in the heap seems kind of pointless.
Yes...
> If your
> hardware is unreliable the corruption could anywhere.
Agreed.
Other DBMS have one setting for the whole server; I've never seen
separate settings for W
On Thu, 2007-01-11 at 12:35 -0500, Tom Lane wrote:
> "Simon Riggs" <[EMAIL PROTECTED]> writes:
> >> Tom Lane wrote:
> >>> The TRACE is in the wrong place no? I thought it was going to be after
> >>> the stat() operation so it could pass the file size.
>
> > We had that discussion already. If you
On Thu, 2007-01-11 at 12:37 -0500, Bruce Momjian wrote:
> The trace probe was incorrect
Yes, incomplete, no doubt. On that point you were 100% right to reject.
> and kind of at an odd place. I don't
> think we want to go down the road of throwing trace in everwhere, do we?
> I would like to se
On Thu, Jan 11, 2007 at 12:35:25PM -0500, Tom Lane wrote:
> I think the real criterion has to be "is this probe useful to
> developers?". I'm entirely uninterested in adding probes that are
> targeted towards DBAs, as this one would have been --- if we think
> there's a problem that a DBA would ha
Simon Riggs wrote:
> > > Also, I dunno much about DTrace, but I had the idea that you can't
> > > simply throw a PG_TRACE macro into the source and think you are done
> > > --- isn't there a file of probe declarations to add to? Not to mention
> > > the documentation of what probes exist.
> >
> >
"Simon Riggs" <[EMAIL PROTECTED]> writes:
>> Tom Lane wrote:
>>> The TRACE is in the wrong place no? I thought it was going to be after
>>> the stat() operation so it could pass the file size.
> We had that discussion already. If you only pass it after the stat()
> then you cannot use DTrace, exc
On Tue, 2007-01-09 at 17:16 -0500, Bruce Momjian wrote:
> Tom Lane wrote:
> > > /* reset flag so that die() interrupt won't cause
> > > problems */
> > > vfdP->fdstate &= ~FD_TEMPORARY;
> > > + PG_TRACE1(temp__file__cleanup, vfdP->fileName);
> >
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Oh, sorry, had the wrong context in mind. I'm still not very impressed
> with the idea --- a CRC check will catch many kinds of problems, whereas
> this approach catches exactly one kind of problem.
Well in fairness I tossed in a throwaway comment at the
Gregory Stark <[EMAIL PROTECTED]> writes:
> "Tom Lane" <[EMAIL PROTECTED]> writes:
>> You understand wrong ... a tuple sitting on disk is normally read
>> directly from the shared buffer, and I don't think we want to pay for
>> copying it.
> "xlog records"
Oh, sorry, had the wrong context in mind
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Gregory Stark <[EMAIL PROTECTED]> writes:
>> "Tom Lane" <[EMAIL PROTECTED]> writes:
>>> Pretty much not happening; or are you volunteering to fix every part of
>>> the system to tolerate injections of inserted data anywhere in a stored
>>> datum?
>
>> I was
Gregory Stark <[EMAIL PROTECTED]> writes:
> "Tom Lane" <[EMAIL PROTECTED]> writes:
>> Pretty much not happening; or are you volunteering to fix every part of
>> the system to tolerate injections of inserted data anywhere in a stored
>> datum?
> I was thinking to do it at a low level as the xlog re
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Gregory Stark <[EMAIL PROTECTED]> writes:
>> What did you think about protecting against torn writes using id numbers
>> every
>> 512 bytes.
>
> Pretty much not happening; or are you volunteering to fix every part of
> the system to tolerate injections of
Gregory Stark <[EMAIL PROTECTED]> writes:
> What did you think about protecting against torn writes using id numbers every
> 512 bytes.
Pretty much not happening; or are you volunteering to fix every part of
the system to tolerate injections of inserted data anywhere in a stored
datum?
"Tom Lane" <[EMAIL PROTECTED]> writes:
> "Simon Riggs" <[EMAIL PROTECTED]> writes:
>> COPY XLogInsert() #1 on oprofile results at 17% CPU
>> (full_page_writes = on)
>
> But what portion of that is actually CRC-related? XLogInsert does quite
> a lot.
>
> Anyway, I can't see de
On Thu, 2007-01-11 at 09:01 -0500, Tom Lane wrote:
> "Simon Riggs" <[EMAIL PROTECTED]> writes:
> > COPYXLogInsert() #1 on oprofile results at 17% CPU
> > (full_page_writes = on)
>
> But what portion of that is actually CRC-related? XLogInsert does quite
> a lot.
>
> A
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> COPY XLogInsert() #1 on oprofile results at 17% CPU
> (full_page_writes = on)
But what portion of that is actually CRC-related? XLogInsert does quite
a lot.
Anyway, I can't see degrading the reliability of the system for a gain
i
On Wed, 2007-01-10 at 23:32 -0500, Bruce Momjian wrote:
> Simon Riggs wrote:
> > On Fri, 2007-01-05 at 22:57 -0500, Tom Lane wrote:
> > > Jim Nasby <[EMAIL PROTECTED]> writes:
> > > > On Jan 5, 2007, at 6:30 AM, Zeugswetter Andreas ADI SD wrote:
> > > >> Ok, so when you need CRC's on a replicate (b
Tom Lane wrote:
Bruce Momjian <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
Has anyone bothered to measure the overhead added by having to mask to
fetch or store the natts value? This is not a zero-cost improvement.
Tom, how should this be tested? I assume some loop of the same query
over an
Simon Riggs wrote:
> On Fri, 2007-01-05 at 22:57 -0500, Tom Lane wrote:
> > Jim Nasby <[EMAIL PROTECTED]> writes:
> > > On Jan 5, 2007, at 6:30 AM, Zeugswetter Andreas ADI SD wrote:
> > >> Ok, so when you need CRC's on a replicate (but not on the master) you
> >
> > > Which sounds to me like a goo
Tom Lane wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> ... why is NAMEDATALEN exported at all?)
>
> > I think because it used to be used in libpq's notification structure.
>
> Yeah, you're probably right. Maybe we should take it out of
> postgres_ext.h and move i
On 1/10/07, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
What about a Mingw or VC++ psql with a BCC libpq? Is it possible to
link something like that?
It would be nice to have the libpq at least able to pass the regression
tests.
you can use microsoft/mingw compiled DLL files but not library fi
On Sat, Jan 06, 2007 at 09:20:53PM -0500, Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Simon Riggs wrote:
> >> Reason for no documentation was that CREATE INDEX and CREATE TABLE AS
> >> SELECT already use this optimisation, but to my knowledge neither was/is
> >> documented on th
Peter Eisentraut wrote:
> Bruce Momjian wrote:
> > The rule re-runs the makefile for the specific target, and the target
> > modifies HTML.index, or it is only the HTML rule that modifies that.
>
> Only the html rule modifies HTML.index.
>
> > That was a question I had. If that is true, it has t
Bruce Momjian wrote:
> The rule re-runs the makefile for the specific target, and the target
> modifies HTML.index, or it is only the HTML rule that modifies that.
Only the html rule modifies HTML.index.
> That was a question I had. If that is true, it has to be:
>
> %-A4.tex-ps: %.sgml $(
Alvaro Herrera wrote:
> Bruce Momjian wrote:
> > Tom Lane wrote:
> > > Gavin Sherry <[EMAIL PROTECTED]> writes:
> > > > Can we be sure that a BCC build libpq is even safe to use given the
> > > > problems seen when using psql?
> > >
> > > Well, I'd not trust it a lot, but surely we have to get it
Bruce Momjian wrote:
> Tom Lane wrote:
> > Gavin Sherry <[EMAIL PROTECTED]> writes:
> > > Can we be sure that a BCC build libpq is even safe to use given the
> > > problems seen when using psql?
> >
> > Well, I'd not trust it a lot, but surely we have to get it to build
> > before anyone can debug
Peter Eisentraut wrote:
> Am Mittwoch, 10. Januar 2007 01:41 schrieb Bruce Momjian:
> > Peter Eisentraut wrote:
> > > Bruce Momjian wrote:
> > > > > ? %-A4.tex-ps: %.sgml $(ALLSGML) stylesheet.dsl bookindex.sgml
> > > > > ? $(JADE.tex.call) -V texdvi-output -V '%paper-type%'=A4 -o $@ $<
> > > >
Heikki Linnakangas wrote:
> Bruce Momjian wrote:
> > Tom Lane wrote:
> >> Bruce Momjian <[EMAIL PROTECTED]> writes:
> >>> Patch applied. Thanks.
> >>> I added a comment about the unused bits in the header file.
> >> Has anyone bothered to measure the overhead added by having to mask to
> >> fetch
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> What? I'm completely lost here. What does log_temp_files have to do with
> the bits on the tuple header?
Nothing, it looks like Bruce replied to the wrong message at one point
while these two threads were active ...
regards
Nice, thanks a lot.
Tom Lane wrote:
Teodor Sigaev <[EMAIL PROTECTED]> writes:
Just a freshing for clean applying..
http://www.sigaev.ru/misc/user_defined_typmod-0.11.gz
Applied with some revisions, and pg_dump support and regression tests
added.
regards, tom lane
---
Tom Lane wrote:
Bruce Momjian <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
Has anyone bothered to measure the overhead added by having to mask to
fetch or store the natts value? This is not a zero-cost improvement.
I haven't tested it. Agreed, it does add an AND operation to places
where t_n
Am Mittwoch, 10. Januar 2007 01:41 schrieb Bruce Momjian:
> Peter Eisentraut wrote:
> > Bruce Momjian wrote:
> > > > ? %-A4.tex-ps: %.sgml $(ALLSGML) stylesheet.dsl bookindex.sgml
> > > > ? $(JADE.tex.call) -V texdvi-output -V '%paper-type%'=A4 -o $@ $<
> > > > + ifndef DRAFT
> > > > + [EMAIL P
Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian <[EMAIL PROTECTED]> writes:
Patch applied. Thanks.
I added a comment about the unused bits in the header file.
Has anyone bothered to measure the overhead added by having to mask to
fetch or store the natts value? This is not a zero-cost imp
Peter Eisentraut wrote:
> Bruce Momjian wrote:
> > > ! draft:
> > > ! ifndef DRAFT
> > > ! ifneq ($(MAKECMDGOALS), draft)
>
> How could this condition ever match?
On first call, 'draft' might be set, but in the recursive call, this
code will not be reached because DRAFT iss set.
Peter Eisentraut wrote:
> Bruce Momjian wrote:
> > > + ifndef DRAFT
> > > + [EMAIL PROTECTED] -s HTML.index.start HTML.index || $(MAKE) $*
> > > + endif
>
> Why are you using $*? This isn't a pattern rule.
>
Sorry, my mistake. Here is an patch to fix that.
--
Bruce Momjian [EMAIL PROTECT
Peter Eisentraut wrote:
> Bruce Momjian wrote:
> > > ? %-A4.tex-ps: %.sgml $(ALLSGML) stylesheet.dsl bookindex.sgml
> > > ? $(JADE.tex.call) -V texdvi-output -V '%paper-type%'=A4 -o $@ $<
> > > + ifndef DRAFT
> > > + [EMAIL PROTECTED] -s HTML.index.start HTML.index || $(MAKE) $*
> > > + endif
>
Bruce Momjian wrote:
> > ! draft:
> > ! ifndef DRAFT
> > ! ifneq ($(MAKECMDGOALS), draft)
How could this condition ever match?
> > ! # Call ourselves with the DRAFT value set. This seems to be the only
> > ! # way to set gmake variables in a rule.
> > ! [EMAIL PROTECTED](MAKE) DRAFT="Y" $(MAKEC
Bruce Momjian wrote:
> > + ifndef DRAFT
> > + [EMAIL PROTECTED] -s HTML.index.start HTML.index || $(MAKE) $*
> > + endif
Why are you using $*? This isn't a pattern rule.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of broadcast)--
Bruce Momjian wrote:
> > %-A4.tex-ps: %.sgml $(ALLSGML) stylesheet.dsl bookindex.sgml
> > $(JADE.tex.call) -V texdvi-output -V '%paper-type%'=A4 -o $@ $<
> > + ifndef DRAFT
> > + [EMAIL PROTECTED] -s HTML.index.start HTML.index || $(MAKE) $*
> > + endif
What is the point of that?
--
Pete
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
>
> > SHOW ALL has:
>
> >log_temp_files | -1 | Log
> > the use of temporary files larger than th
>
> Yeah, but if you do "SET log_temp_files = -1", does it still say that?
> I'm worried
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Has anyone bothered to measure the overhead added by having to mask to
>> fetch or store the natts value? This is not a zero-cost improvement.
> Tom, how should this be tested? I assume some loop of the same query
> over and over aga
101 - 200 of 759 matches
Mail list logo
