OK, here's the final version of SET WITHOUT CLUSTER. Has docs +
regression test.
Chris
Index: doc/src/sgml/ref/alter_table.sgml
===
RCS file: /projects/cvsroot/pgsql-server/doc/src/sgml/ref/alter_table.sgml,v
retrieving revision 1.6
Tom Lane wrote:
A couple hours' poking at the patch yielded the attached two diffs
Thanks Tom!
and the realization that list_difference_private cannot work, because
its first call to list_append_auto will crash due to new_list being NIL.
Yeah, I noticed an analogous problem in list_union(), I'd bee
Neil Conway <[EMAIL PROTECTED]> writes:
> BTW, should I take your lack of comment on linitial() as "no objection"?
Make it "no better idea" ;-)
A couple hours' poking at the patch yielded the attached two diffs
and the realization that list_difference_private cannot work, because
its first call t
On Sun, May 23, 2004 at 17:32:36 -0400,
Tom Lane <[EMAIL PROTECTED]> wrote:
>
> slower. (The datatype conversions induced inside get_next_S are likely
> to outweigh any savings from counting by ints, on most modern hardware.)
You aren't even guarenteed that integer operations are faster. On th
Tom Lane wrote:
I'm surprised you did that much work and did not fix things to
distinguish ListCell * from List * ... we're gonna have to make
another pass over all these places to do that.
That would mean changing _every_ usage of foreach(), and a bunch of
other places besides; plus, once one cha
Matthew T. O'Connor wrote:
> This weekend I am trying to fix up all known the pg_autovacuum issues
> that should be resolved for 7.4.3. I am aware of only two issues: temp
> table issues, and unchecked send_query() calls, if I am forgetting
> something, please let me know.
>
> 1) temp table issu
Neil Conway <[EMAIL PROTECTED]> writes:
> I've attached the latest list rewrite patch (gzip'ed, against current
> sources). Unfortunately, the compatibility API we defined earlier wasn't
> that effective: it was more efficient for me to look at more or less
> every lfirst() call site in the back
Patch applied. Thanks.
---
Magnus Hagander wrote:
> This patch fixes the find_my_exec code for pgstat backends. Required for
> TZ stuff (and possibly others) to work in the pgstat backends.
>
> //Magnus
Content-Descripti
Tom Lane wrote:
Er, doesn't that change the behavior?
I don't believe so. There is an if statement earlier that assigns
opt->footers to footers is the former is non-NULL. In other words:
if (opt->footers)
footers = opt->footers;
else if (...)
footers = xyz();
else
footers = NULL;
Ther
Neil Conway <[EMAIL PROTECTED]> writes:
> printTable(opt->title, headers, cells,
> !footers ? (const char *const *) footers : (const char
> *const *) (opt->footers),
> align, &opt->topt, fout);
> printTable(opt->title, headers, cells,
>
As the subject says -- I've applied this patch to HEAD.
-Neil
Index: src/bin/psql/common.c
===
RCS file: /Users/neilc/local/cvs/pgsql-server/src/bin/psql/common.c,v
retrieving revision 1.86
diff -c -r1.86 common.c
*** src/bin/psql/comm
Hackers,
I attach a updated nested transactions patch. Hopefully the list server
will actually distribute it this time. I'd really like to get some
testing and comment. Does this actually work on the scenarios where
those of you who would be using it expect it to work?
In this patch, relcache
Manfred Koizar <[EMAIL PROTECTED]> writes:
> This patch implements the new tuple sampling method as discussed on
> -hackers and -performance a few weeks ago.
Applied with minor editorializations. AFAICS get_next_S() needs to be
called with the number of tuples already processed, which means you w
>> The other thought is that you're not going to have much use
>of this if
>> you don't have pgstat anyway - how are you going to find out which
>> backends actually exist?
>
>Uh, what about ps(1)?
Well, if you ran run ps(1), then you can probably run kill(1) too. The
main point of this patch was
On Sun, 23 May 2004 13:16:49 -0400, Tom Lane <[EMAIL PROTECTED]> wrote:
>> $ gcc --version
>> 2.7.2.1
>
>Man, that's ancient.
Don't say that before you have seen my bike :-)
>How do you feel about upgrading?
This is on my notebook. I'm a little afraid of changing major parts of
the system. Onc
Manfred Koizar <[EMAIL PROTECTED]> writes:
> On Sun, 23 May 2004 11:40:29 -0400, Tom Lane <[EMAIL PROTECTED]> wrote:
>> both using gcc?
> Mine is quite old:
> $ gcc --version
> 2.7.2.1
Man, that's ancient. What we're probably looking at here is a bug in
the #include search algorithm in that vers
"Magnus Hagander" <[EMAIL PROTECTED]> writes:
> The other thought is that you're not going to have much use of this if
> you don't have pgstat anyway - how are you going to find out which
> backends actually exist?
ps, perhaps? Anyway I agree with Neil that it'd be better not to have a
dependency
Manfred Koizar <[EMAIL PROTECTED]> writes:
> Here is what I get without that change:
> gcc -O2 -g -Wall -Wmissing-prototypes -Wmissing-declarations
> -I/m/u2/home/fred/pgsrc/SNAP/tst04a/src/interfaces/libpq
> -I../../../src/include -I/m/u2/home/fred/pgsrc/SNAP/tst04a/src/include
> -D_GNU_SOURCE -
Manfred Koizar <[EMAIL PROTECTED]> writes:
> On Sun, 23 May 2004 02:39:41 -0400, Tom Lane <[EMAIL PROTECTED]> wrote:
>> I'm not quite
>> sure what --without-docdir should mean ... if it's not a complete no-op
>> it seems like it ought to specify not installing docs at all.
> --without-docdir
Manfred Koizar <[EMAIL PROTECTED]> writes:
> Yesterday's snapshot couldn't be compiled from a separate build
> directory, and after configure --without-docdir ... make install failed,
> because it tried to mkdir /postgresql/html.
> The enclosed patch fixes these problems, at least for me.
The src/
Magnus Hagander wrote:
The other thought is that you're not going to have much use of this if
you don't have pgstat anyway - how are you going to find out which
backends actually exist?
Uh, what about ps(1)?
-Neil
---(end of broadcast)---
TIP 2: you c
This patch implements the new tuple sampling method as discussed on
-hackers and -performance a few weeks ago.
"Large DB" -hackers 2004-04-02
"query slows down with more accurate stats" -perform 2004-04-13
"Tuple sampling" -hackers 2004-04-19
Servus
Manfred
diff -rcN ../base/src/backend/commands
>> Per previous discussions, here are two functions to send INT and TERM
>> signals to other backends.They permit only INT and TERM, and permits
>> sending only to postgresql backends (as registered in pgstat).
>
>Why does this depend on pgstat? ISTM it would be better to use the
>per-backend PGPR
23 matches
Mail list logo
