Let me add that most entries that illict a quick patch or TODO item do
not come in through the bugs list, but are rather problems people post
to ther lists, or are the result of discussions.
---
Gregory Stark wrote:
> Andrew
Andrew Dunstan wrote:
>
> I have just noticed that psql's \timing does not apply to internal
> commnds like \copy, which surprised me a bit. Is there any reason why it
> should not apply at least in the case of \copy, which after all does
> real work, as opposed to to the client housekeeping an
"Matthew T. O'Connor" wrote:
Sorry, I should have explained more.
> What is this based on? That is, based on what information is it
> deciding to reduce the naptime?
If there are some vacuum or analyze jobs, the naptime is shortened
(i.e, autovacuum is accelerated). And if there are no jobs,
Martijn van Oosterhout wrote:
> If you want the latter, the approach would be to keep pgsql-bugs and
> when a real issue comes up, bounce it to the bug tracker. Any
> subsequent email discussion should then get logged in the bug report.
That's what I want. I don't want the bug tracking system to
Andrew Dunstan wrote:
> What we are talking about here is bug triage.
I think we are actually talking about bug *tracking*.
> One sensible way to do this would be to have a group of suitably
> qualified volunteers who could perform this function on a roster
> basis, for, say, a week or a two at a
Gregory Stark wrote:
> The Debian system would be basically zero operational change.
> pgsql-bugs would continue to exist exactly as it does now except it
> would go through debbugs.
Debbugs is fine and all, but they don't seem to publish their code on a
regular basis.
--
Peter Eisentraut
http:
Alvaro Herrera wrote:
ITAGAKI Takahiro wrote:
In the case of a heavily update workload, the default naptime (60 seconds)
is too long to keep the number of dead tuples low. With my patch, the naptime
will be adjusted around 3 seconds at the case of pgbench (scale=10, 80 tps)
with default other a
Hi Nagayasu san and folks,
I have a question about pgstatindex.
Satoshi Nagayasu <[EMAIL PROTECTED]> wrote:
> Attached patch has been cleaned up,
> and modified to be able to work with CVS HEAD.
Index leaf pages are ordered just after REINDEX.
[1] [2] [3]
After full-split, they will be the fol
> Tom Lane <[EMAIL PROTECTED]> writes:
>
> > I think this is excessive concern for bit-shaving.
>
> Egads. bit-shaving is *important*. If it's 8 bytes you
> could just use a char(4) and store 4 character text codes
> instead. The whole reason to want this feature is
> precisely for bit-shaving.
Tom Lane <[EMAIL PROTECTED]> writes:
> If you're gonna fix it at 4 bytes, then I strongly suggest
> that the value identifiers actually be OIDs assigned
> through the standard OID-generating mechanism, and that
> the pg_enum table have the structure
...
> The advantage of doing this is that you
ITAGAKI Takahiro wrote:
> In the case of a heavily update workload, the default naptime (60 seconds)
> is too long to keep the number of dead tuples low. With my patch, the naptime
> will be adjusted around 3 seconds at the case of pgbench (scale=10, 80 tps)
> with default other autovacuum paramet
Hi hackers,
There is a comment in autovacuum.c:
| XXX todo: implement sleep scale factor that existed in contrib code.
and the attached is a patch to implement it.
In contrib code, sleep scale factor was used to adjust naptime only to
lengthen the naptime. But I changed the behavior to be able to
Tom Lane <[EMAIL PROTECTED]> writes:
> I think this is excessive concern for bit-shaving. Make the on-disk
> representation be 8 bytes instead of 4, then you can store the OID
> directly and have no need for the separate identifier concept. This
> in turn eliminates one index, one syscache, and
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> What we are talking about here is bug triage.
Really? We have a problem with too many bug reports and need a tool to help
triage them? That's the first I've heard of that.
Think about what tasks you do now and what tool would make it easier. Don't
tr
On Wed, Aug 16, 2006 at 06:48:09PM -0400, Gregory Stark wrote:
> "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
>
> > On Tue, Aug 15, 2006 at 07:55:28PM +0200, Peter Eisentraut wrote:
> >
> > > It would not be hard to create an "auto explain analyze" mode that
> > > implicitly runs EXPLAIN ANALYZE al
Tom Dunstan <[EMAIL PROTECTED]> writes:
> Andrew Dunstan wrote:
>> I'm inclined to say let's keep it simple and stay with a fixed 4-byte
>> global size.
> Fair enough. I'm ok with 4 bytes; 8 seemed a bit gratuitous.
If you're gonna fix it at 4 bytes, then I strongly suggest that the
value identi
On Wed, Aug 16, 2006 at 04:13:43PM -0400, Tom Lane wrote:
> Tom Dunstan <[EMAIL PROTECTED]> writes:
> > I thought the runtime one was kinda cute, actually, but you would have
> > to have duplicate functions for the differently sized types, eg.
> > enum1_out, enum2_out etc since otherwise you woul
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> On Tue, Aug 15, 2006 at 07:55:28PM +0200, Peter Eisentraut wrote:
>
> > It would not be hard to create an "auto explain analyze" mode that
> > implicitly runs EXPLAIN ANALYZE along with every query and logs the
> > result. On its face, it sounds like
On Wed, 2006-08-16 at 17:09 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > Wise one: what should my pg_proc look like?
>
> > DATA(insert OID = 2850 ( pg_xlogfile_name_offsetPGNSP PGUID 12 f f t f
> > i 1 2249 "25" "25 25 23" "i o o" _null_ pg_xlogfile_name_offset -
> > _n
On Wed, 16 Aug 2006, Robert Treat wrote:
I'm not sure I follow this, since currently anyone can email the bugs
list or use the bugs -> email form from the website. Are you looking to
increase the barrier for bug reporting?
Any garbage (ie. spam) is generally filtered before it hits the -bugs
Simon Riggs <[EMAIL PROTECTED]> writes:
> Wise one: what should my pg_proc look like?
> DATA(insert OID = 2850 ( pg_xlogfile_name_offset PGNSP PGUID 12 f f t f
> i 1 2249 "25" "25 25 23" "i o o" _null_ pg_xlogfile_name_offset -
> _null_ ));
Oh, as far as that goes, the array columns need to
On Wed, 2006-08-16 at 16:51 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > but my initdb fails with
>
> > creating template1 database in a/base/1 ... FATAL: cache lookup failed
> > for type 26
>
> Um ... when did you last "cvs update"? That was the behavior up till I
> fix
Simon Riggs <[EMAIL PROTECTED]> writes:
> but my initdb fails with
> creating template1 database in a/base/1 ... FATAL: cache lookup failed
> for type 26
Um ... when did you last "cvs update"? That was the behavior up till I
fixed array_in for bootstrap mode, yesterday afternoon ...
On Wed, 2006-08-16 at 11:45 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > We want a single row output, with two columns, yes?
> > Presumably:
> > xlogfilenameTEXT
> > offset INTEGER
>
> Sounds right to me. int4 should be wide enough for practical xlog
>
Tom Dunstan <[EMAIL PROTECTED]> writes:
> I thought the runtime one was kinda cute, actually, but you would have
> to have duplicate functions for the differently sized types, eg.
> enum1_out, enum2_out etc since otherwise you wouldn't know what sized
> parameter you were just handed.
I'm not s
Jim C. Nasby wrote:
On Tue, Aug 15, 2006 at 10:43:12PM -0700, Josh Berkus wrote:
Tom,
These days I doubt there's anyone around the project who refuses to use
a web browser at all. However, I still personally find it much more
convenient to read and respond to mailing-list postings th
On Wed, 2006-08-16 at 08:51 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > On Tue, 2006-08-15 at 18:42 -0400, Tom Lane wrote:
> >> So let's fix pg_xlogfile_name_offset() to have two OUT parameters
> >> instead of returning a smushed-together string.
>
> > I'll do this, but I'
Andrew Dunstan wrote:
Even more radical: do it at runtime. You could assign the typlen
(stored width) of an enum type at creation time on the basis of the
largest identifier it contains. This might be a bit too weird because
enums created earlier would have a size advantage over those created
On Wed, Aug 16, 2006 at 11:12:11AM +0800, Christopher Kings-Lynne wrote:
> >Trac does support PostgreSQL...
> >
> >The thing I don't understand at this point is what exactly is the
> >nature of the integration with the SCM.
> >
> >I don't see it being likely that there will be a deep integration of
(I had a private bet with myself that Tom Lane would object to the "bit
shaving" ;-) )
Tom Lane wrote:
Ok, I'll run one more idea up the flagpole before giving up on a 4 byte
on disk representation. :) How about assigning a unique 4 byte id to
each enum value, and storing that on disk. This
Chris Mair <[EMAIL PROTECTED]> writes:
> attached is the new and fixed version of the patch for selecting
> large result sets from psql using cursors.
The is_select_command bit is wrong because it doesn't allow for left
parentheses in front of the SELECT keyword (something entirely
reasonable when
Simon Riggs <[EMAIL PROTECTED]> writes:
> We want a single row output, with two columns, yes?
> Presumably:
> xlogfilenameTEXT
> offset INTEGER
Sounds right to me. int4 should be wide enough for practical xlog
segment sizes.
regards, tom lane
---
Volkan YAZICI <[EMAIL PROTECTED]> writes:
> On Aug 11 12:51, Greg Sabino Mullane wrote:
>> Prepared statements are not visible nor survivable outside of your
>> session, so this doesn't really make sense. If your application needs
>> the information, it can get it at prepare time.
> What about per
On Tue, Aug 15, 2006 at 10:43:12PM -0700, Josh Berkus wrote:
> Tom,
>
> > These days I doubt there's anyone around the project who refuses to use
> > a web browser at all. However, I still personally find it much more
> > convenient to read and respond to mailing-list postings than to have to
> >
Tom Dunstan <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I think this is excessive concern for bit-shaving. Make the on-disk
>> representation be 8 bytes instead of 4, then you can store the OID
>> directly and have no need for the separate identifier concept.
> That's all true. It's a bit de
I have just noticed that psql's \timing does not apply to internal
commnds like \copy, which surprised me a bit. Is there any reason why it
should not apply at least in the case of \copy, which after all does
real work, as opposed to to the client housekeeping and info functions
that most psq
On Wed, Aug 16, 2006 at 09:14:47AM -0400, Andrew Dunstan wrote:
> What we are talking about here is bug triage. Weeding out misreports,
> duplicates etc. is a prime part of this function. It is essential to the
> health of any functioning bug tracking system. All it takes is
> resources. Is it w
On Aug 16 11:37, Tom Lane wrote:
> Volkan YAZICI <[EMAIL PROTECTED]> writes:
> > On Aug 11 12:51, Greg Sabino Mullane wrote:
> >> Prepared statements are not visible nor survivable outside of your
> >> session, so this doesn't really make sense. If your application needs
> >> the information, it ca
Tom Lane wrote:
Tom Dunstan <[EMAIL PROTECTED]> writes:
On disk, enums will occupy 4 bytes: the high 22 bits will be an enum
identifier, with the bottom 10 bits being the enum value. This allows
1024 values for a given enum, and 2^22 different enum types, both of
which should be heaps. The exact
Volkan YAZICI <[EMAIL PROTECTED]> writes:
> On Aug 16 11:37, Tom Lane wrote:
>> I think this viewpoint has pretty much carried the day, so the
>> PQdescribe functions should remain separate. However, it still seems
>> to me that it'd be a shame if PQdescribePrepared couldn't return the
>> statemen
-hackers,
I'm working on a vacuum verbose log analyzer for a few weeks now. My
goal is to allow a more systematic study of this log output to help
improve the vacuum strategy.
To do so, I spent a few hours studying the vacuum code and especially
the way it logs what it's doing.
What surprises m
Tom Dunstan <[EMAIL PROTECTED]> writes:
> Andrew and I got together and worked out a more detailed idea of how we
> want to add enums to the postgresql core. This follows on from his
> original enumkit prototype last year [1]. Here's a more formal proposal
> / design with what we came up with. C
On Aug 16 03:09, Volkan YAZICI wrote:
> WARNING: problem in alloc set ExprContext: detected write past chunk
> end in block 0x8462f00, chunk 0x84634c8
> WARNING: cache reference leak: cache pg_type (34), tuple 2/7 has
> count 1
Excuse me for bugging the list. I've solved the problem. I should lo
"Jie Zhang" <[EMAIL PROTECTED]> writes:
> On 8/15/06 6:18 AM, "Tom Lane" <[EMAIL PROTECTED]> wrote:
>> Well, as I said, I don't think there's justification for exposing a
>> bitmap index's internal data formats to the rest of the system like
>> that: it's not very future-proof and I don't see that
Martijn van Oosterhout wrote:
On Wed, Aug 16, 2006 at 02:28:53PM +0200, Peter Eisentraut wrote:
Am Mittwoch, 16. August 2006 14:10 schrieb Robert Treat:
I'm not sure I follow this, since currently anyone can email the bugs list
or use the bugs -> email form from the website. Are you lo
Simon Riggs <[EMAIL PROTECTED]> writes:
> On Tue, 2006-08-15 at 18:42 -0400, Tom Lane wrote:
>> So let's fix pg_xlogfile_name_offset() to have two OUT parameters
>> instead of returning a smushed-together string.
> I'll do this, but I'm conscious that this is a cosmetic change.
Well, it's cosmeti
On Wed, Aug 16, 2006 at 02:28:53PM +0200, Peter Eisentraut wrote:
> Am Mittwoch, 16. August 2006 14:10 schrieb Robert Treat:
> > I'm not sure I follow this, since currently anyone can email the bugs list
> > or use the bugs -> email form from the website. Are you looking to
> > increase the barrie
On Wednesday 16 August 2006 00:52, Peter Eisentraut wrote:
> Tom Lane wrote:
> > that the bug tracker would have to have a reasonable "output" email
> > capability, but I'd not necessarily insist on being able to "input"
> > to it by mail. Red Hat's present bugzilla system could be described
> > t
Am Mittwoch, 16. August 2006 14:10 schrieb Robert Treat:
> I'm not sure I follow this, since currently anyone can email the bugs list
> or use the bugs -> email form from the website. Are you looking to
> increase the barrier for bug reporting?
Only a small fraction of the new posts on pgsql-bugs
Hi,
I've been trying to implement INOUT/OUT functionality in PL/scheme. When
I return a record type tuple, postmaster complains with below warnings:
WARNING: problem in alloc set ExprContext: detected write past chunk
end in block 0x8462f00, chunk 0x84634c8
WARNING: cache reference leak: cache
hi all!
seahorse is struggling to submit buildfarm reports for a few days now.
there seems to a rather weird thing going on since what appears to
happen is that the build fails during "make check" with a crashing
postmaster but that crash is also hanging the buildfarm-script and so it
fails to sub
We forgot to mention that we'll need to implement domains over enums and
arrays of enums too.
cheers
andrew
Tom Dunstan wrote:
> Hi guys
>
> Andrew and I got together and worked out a more detailed idea of how we
> want to add enums to the postgresql core. This follows on from his
> original e
On 8/15/06 6:18 AM, "Tom Lane" <[EMAIL PROTECTED]> wrote:
> Gavin Sherry <[EMAIL PROTECTED]> writes:
>> On Mon, 14 Aug 2006, Tom Lane wrote:
>>> Correct me if I'm wrong, but isn't the patch's present hacking on the
>>> executor intended to make it happen like this?
>
>> Not really. It reads ahe
53 matches
Mail list logo
