On Tue, 2006-08-15 at 18:42 -0400, Tom Lane wrote:
I wrote:
It'd definitely be nicer that way, but given the current limitations of
bootstrap mode I see no non-kluge way to make a built-in function have
OUT parameters. (Hint: array_in doesn't work in bootstrap mode.)
Actually, that
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 ahead on the bitmap
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
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
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
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
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
that way ---
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 barrier for
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 cosmetic, but
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
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 it's buying
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 look
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.
-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
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
statement's output
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
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 can get it at
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
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
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 depressing
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
go and
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 persistent
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
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
(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
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
the
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, 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'm conscious
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
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 sure
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 look like
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
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
segment
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 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
fixed array_in
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 -
_null_ ));
Oh,
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 an obviously
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 wouldn't
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 identifiers
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 along with every
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
try
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 one
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
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 can
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.
Well, and
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
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
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
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
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 be
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
51 matches
Mail list logo
