From: "ITAGAKI Takahiro" <[EMAIL PROTECTED]>
> Tom Lane <[EMAIL PROTECTED]> wrote:
>
>> I'm of the opinion that the solution to FSM being fixed-size is to
keep
>> it somewhere else, ie, on disk (possibly with some sort of cache in
>> shared memory for currently-used entries).
>
> What do you think
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 it ...
regards, tom lane
---
ITAGAKI Takahiro <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> wrote:
>> I'm of the opinion that the solution to FSM being fixed-size is to keep
>> it somewhere else, ie, on disk (possibly with some sort of cache in
>> shared memory for currently-used entries).
> What do you think dyn
Tom Lane <[EMAIL PROTECTED]> wrote:
> I'm of the opinion that the solution to FSM being fixed-size is to keep
> it somewhere else, ie, on disk (possibly with some sort of cache in
> shared memory for currently-used entries).
What do you think dynamic allocation from shared_buffers? ie, remove
a
I wrote:
> I'm thinking about generalizing your idea; Adding three parameters
> to control sleeps in each stage.
I sent a patch to -patches that adds 3+1 GUC parameters for checkpoints.
We can use three of them to control sleeps in each stage during checkpoints.
The last is an experimental approac
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
Simon Riggs wrote:
> On Sat, 2007-01-06 at 17:06 -0500, Bruce Momjian wrote:
> > I saw no replies to this.
>
> Me neither.
>
> I take it that means its a very good idea and we should add a TODO
Added to TODO:
* Improve merge join performance by allowing mark/restore of
tuple sources
http:/
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 that will change it to -1024.
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 improvement.
Tom Lane wrote:
> Bill Moran <[EMAIL PROTECTED]> writes:
> > In response to Tom Lane <[EMAIL PROTECTED]>:
> >> and then zero
> >> can be the "off" position, and we need not worry about whether -1 is
> >> -1 byte or -1 kbyte.
>
> > All doing this does is make it impossible to log temp files of 1 by
Bill Moran <[EMAIL PROTECTED]> writes:
> In response to Tom Lane <[EMAIL PROTECTED]>:
>> Hmm, that could be a little bit ugly. Suggestion: redefine the value
>> such that files *greater than* the given size are logged,
> It already is that way, with 0 effectively meaning "log all".
Oh, never min
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 improvement.
Bill Moran <[EMAIL PROTECTED]> writes:
> In response to Tom Lane <[EMAIL PROTECTED]>:
>> and then zero
>> can be the "off" position, and we need not worry about whether -1 is
>> -1 byte or -1 kbyte.
> All doing this does is make it impossible to log temp files of 1 byte.
How you figure that? It
In response to Tom Lane <[EMAIL PROTECTED]>:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> Surely the measurement unit should be kbytes or disk blocks. And why
> >> aren't you using that GUC UNITS infrastructure Peter put in?
>
> > Agreed. I have applied the following pat
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> Surely the measurement unit should be kbytes or disk blocks. And why
> >> aren't you using that GUC UNITS infrastructure Peter put in?
>
> > Agreed. I have applied the following patch to make it kilobytes, and
>
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 improvement.
re
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Surely the measurement unit should be kbytes or disk blocks. And why
>> aren't you using that GUC UNITS infrastructure Peter put in?
> Agreed. I have applied the following patch to make it kilobytes, and
> documented it. I didn't pu
Patch applied.
---
Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > Peter Eisentraut wrote:
> > >> The problem is that this requires two runs even to proof the
> > >> documentation,
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > + A value of zero logs all temporary files, and positive
> > + values log only files whose size is equal or greater than
> > + the specified number of bytes.
>
> Surely the measurement unit should be kbytes or
Bruce Momjian <[EMAIL PROTECTED]> writes:
> + A value of zero logs all temporary files, and positive
> + values log only files whose size is equal or greater than
> + the specified number of bytes.
Surely the measurement unit should be kbytes or disk blocks. And why
aren't
Gregory Stark <[EMAIL PROTECTED]> writes:
> The real problem is that we don't have, and don't particularly want, a memory
> manager for the shared memory.
No, the real problem is that you can't re-size a SysV shared memory
segment on the fly --- there's no portable API for that, anyway.
Therefore
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > So why aren't all patches that are posted to the -patches list in the
> > hold queue?
>
> I think the really short answer to this is that Bruce is behind on
> processing the patches list.
Probably. :-(
--
Bruce Momjian [EMAIL
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> So why aren't all patches that are posted to the -patches list in the
> hold queue?
I think the really short answer to this is that Bruce is behind on
processing the patches list.
regards, tom lane
---(e
Bill Moran wrote:
> In response to Tom Lane <[EMAIL PROTECTED]>:
>
> > Bill Moran <[EMAIL PROTECTED]> writes:
> > > Andrew Dunstan <[EMAIL PROTECTED]> wrote:
> > >>> Might be more robust to say
> > >>> if (trace_temp_files >= 0)
> >
> > > I specified in the GUC config that minimum allowable value
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> ...continuing this discussion about setting HEAP_XMIN_COMMITTED...
>> BTW, a sufficient counterexample for that kluge is that neither SPI or
>> SQL-function execution use a separate portal for invoked commands.
> What would the best/acceptable way be to
Hi, I've been studying some nested tables properties, and I use PostgreSQL
as my default DBMS.
The question is...
Are there some advances for the implementation of this propertie in any
upcoming version of PostgreSQL?
I'll be waiting for your answers.
Thanks
--
"Bruce Momjian" <[EMAIL PROTECTED]> writes:
> Josh Berkus wrote:
>> All,
>>
>> Hey, is there any good reason why FSM is sized by a static GUC variable?
>> Why couldn't we just automatically have the system use as much memory as
>> it needs for FSM, provided that it's not more than some reason
Alvaro Herrera wrote:
> Bruce Momjian wrote:
> > Alvaro Herrera wrote:
> > > Bruce Momjian wrote:
> > >
> > > > The hold queue has patches that still need discussion, or ideas for
> > > > patches, so it is more than just patches ready for application, and
> > > > moving the whole thing at once wou
Josh Berkus wrote:
> All,
>
> Hey, is there any good reason why FSM is sized by a static GUC variable?
> Why couldn't we just automatically have the system use as much memory as
> it needs for FSM, provided that it's not more than some reasonable limit,
> like 15% of shared memory?
>
> Seems
All,
Hey, is there any good reason why FSM is sized by a static GUC variable?
Why couldn't we just automatically have the system use as much memory as
it needs for FSM, provided that it's not more than some reasonable limit,
like 15% of shared memory?
Seems like that would eliminate one area
Bruce Momjian wrote:
> Alvaro Herrera wrote:
> > Bruce Momjian wrote:
> >
> > > The hold queue has patches that still need discussion, or ideas for
> > > patches, so it is more than just patches ready for application, and
> > > moving the whole thing at once would overwhelm patch reviewers.
> >
>
Alvaro Herrera wrote:
> Bruce Momjian wrote:
>
> > The hold queue has patches that still need discussion, or ideas for
> > patches, so it is more than just patches ready for application, and
> > moving the whole thing at once would overwhelm patch reviewers.
>
> So why aren't all patches that are
On Sun, 2007-01-07 at 11:29 -0500, Tom Lane wrote:
> I wrote:
> > ... The active-portal kluge that you've just
> > mentioned is nothing but a kluge, proving that you thought of some cases
> > where it would fail. But I doubt you thought of everything.
New patch submitted to -patches on different
Bruce Momjian wrote:
> The hold queue has patches that still need discussion, or ideas for
> patches, so it is more than just patches ready for application, and
> moving the whole thing at once would overwhelm patch reviewers.
So why aren't all patches that are posted to the -patches list in the
Zeugswetter Andreas ADI SD wrote:
>
> > > I'm confused, I thought the difference between the pgpatches queue
> and
> > > the pgpatches_hold queue is the release the patch is targeted for.
> If
> > > there's a third queue for patches that need review before being
> added to
> > > another queue,
Lukas Kahwe Smith wrote:
> Andrew Dunstan wrote:
>
> > The latter does not exist, AFAIK. Before feature freeze for cycle X, we
> > don't usually hold patches for release X+1, as I understand it.
> >
> > In general, we should try to hold patches as little amount of time as
> > possible. That way t
Hi everyone,
Here's a prototype for what I had in mind, the sections that will
probably be of most interest are pgsql and bizgres.
This link shows all tracked repositories:
http://folio.dyndns.org/repository/report
This link shows all tracked patches for pgsql:
http://folio.dyndns.org/patch/rep
> > I'm confused, I thought the difference between the pgpatches queue
and
> > the pgpatches_hold queue is the release the patch is targeted for.
If
> > there's a third queue for patches that need review before being
added to
> > another queue, could we have that visible somewhere, so that we k
Tom Lane wrote:
> This is closely related to the discussion a couple weeks ago about how
> a LEFT JOIN could produce nulls in an output column that was labeled as
> having a non-null-domain type. We haven't figured out what is a sane
> behavior for that case, either. I'm beginning to think that
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> Perhaps a means to mark the record as being null, other than setting all
> the fields to null?
We could probably bypass the call of the domain input function, thereby
avoiding the elog, but the point remains: if we do that, then we have
a NOT-NULL-const
Jim C. Nasby wrote:
> On Sat, Jan 06, 2007 at 04:56:12PM -0500, Bruce Momjian wrote:
>> > > I am open to new names.
>> >
>> > patches-8_3 ? Anything coming in after FF then goes to patches-8_4.
>>
>> The problem there is that the web site references these, so changing the
>> URL for every release i
On Mon, Jan 08, 2007 at 10:40:16PM -0600, Michael Glaesemann wrote:
>
> On Jan 8, 2007, at 19:25 , Jim C. Nasby wrote:
>
> >Actually, I see point in both... I'd think you'd want to know if a
> >patch
> >worked against the CVS checkout it was written against.
>
> Regardless, it's unlikely that
On Mon, Jan 08, 2007 at 10:27:15AM -0500, Tom Lane wrote:
> "Jonathan Hull" <[EMAIL PROTECTED]> writes:
> > The key feature for the error is that when a result structure (eg : pg_foo)
> > is defined with a domain type that is not null, only PG 8.2 errors if the
> > result is an empty set.
>
> The
On Sat, Jan 06, 2007 at 04:56:12PM -0500, Bruce Momjian wrote:
> > > I am open to new names.
> >
> > patches-8_3 ? Anything coming in after FF then goes to patches-8_4.
>
> The problem there is that the web site references these, so changing the
> URL for every release is odd, plus right now both
Dave Page wrote:
> Andreas Pflug wrote:
>
>> Not much function to "re-create" here, single
>> exception is extracting cluster wide data, the -g option, that's why I
>> mentioned scripting. But apparently this didn't get into pgadmin svn any
>> more, so I need to retract this proposal.
>>
>
Andreas Pflug wrote:
> Not much function to "re-create" here, single
> exception is extracting cluster wide data, the -g option, that's why I
> mentioned scripting. But apparently this didn't get into pgadmin svn any
> more, so I need to retract this proposal.
Eh? Your SCRIPT code is still there -
53 matches
Mail list logo
