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 -
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.
>>
>
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
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 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
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
"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
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
> > 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
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
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
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,
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
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
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
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.
> >
>
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
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
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
"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
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
--
"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
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
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
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
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
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
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
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,
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
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
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
>
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
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
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]>:
>> 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:
> 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
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.
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.
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:
> 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
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 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
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:
> > ! 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
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
>
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:
> > > ! 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.
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
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
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
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
---
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
53 matches
Mail list logo
