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 - or
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.
Eh? Your
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 queues
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 problem is
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 the patch
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 know
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 they don't
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 posted
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.
So why aren't
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
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 reasonable limit,
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 is -1.
I'd still tend
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
---(end
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
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 you
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 put '-1kB'
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:
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
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 byte.
How you
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:
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
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?
--
Peter
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
What is the
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 approach
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 dynamic
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
31 matches
Mail list logo
