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
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
Greg Stark [EMAIL PROTECTED] writes:
Updated patch. Fixed a few minor things, added documentation and regression
tests. Unfortunately I can't test the regression tests because I get a
segmentation fault earlier in the same file due to a GIN index build. So I
haven't updated the expected
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
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
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 10:09 +0100, Simon Riggs wrote:
On Thu, 2006-08-03 at 19:03 +0100, Simon Riggs wrote:
On Thu, 2006-08-03 at 13:38 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
WIP archive_timeout.
All we need to do is add LWLock support to archiver.
Tom Lane [EMAIL PROTECTED] writes:
Greg Stark [EMAIL PROTECTED] writes:
Updated patch. Fixed a few minor things, added documentation and regression
tests. Unfortunately I can't test the regression tests because I get a
segmentation fault earlier in the same file due to a GIN index build.
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, 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,
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
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
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
16 matches
Mail list logo
