When pmState == PM_RECOVERY_CONSISTENT we run
SignalAutovacWorkers(SIGTERM);
at normal shutdown
This currently does nothing, but since there aren't ever going to be any
AVworkers at this time we should be explicitly skipping this. That
should avoid misunderstanding the code and avoid any future s
Simon Riggs writes:
> When pmState == PM_RECOVERY_CONSISTENT we run
> SignalAutovacWorkers(SIGTERM);
> at normal shutdown
> This currently does nothing, but since there aren't ever going to be any
> AVworkers at this time we should be explicitly skipping this. That
> should avoid misunderstanding
On fre, 2009-09-04 at 17:49 -0400, Tom Lane wrote:
> I have just discovered that this commit
> http://archives.postgresql.org/pgsql-committers/2008-03/msg00316.php
> which was alleged to improve our dtrace support on non-Solaris operating
> systems, actually disabled it completely:
You might want
Peter Eisentraut writes:
> On fre, 2009-09-04 at 17:49 -0400, Tom Lane wrote:
>> I have just discovered that this commit
>> http://archives.postgresql.org/pgsql-committers/2008-03/msg00316.php
>> which was alleged to improve our dtrace support on non-Solaris operating
>> systems, actually disabled
Heikki Linnakangas writes:
> Greg Stark wrote:
>> Just make the textual representation of "char" be \xxx (or perhaps we
>> could switch to \xHH now) if the value isn't a printable ascii
>> character. As long as "char" reads that in properly it doesn't matter
>> if it's not a reasonable multibyte c
Robert Haas writes:
> I guess my point is that for node types that dump their output into a
> tuplestore anyway, it doesn't seem like cost_nestloop() should charge
> n * the startup cost. I believe that at least function, CTE, and
> worktable scans fall into this category. No?
Yeah, probably.
I wrote:
> It might be sufficient to have cost_nestloop just hardwire the knowledge
> that certain inner path types have a different behavior here --- that
> is, for a rescan there is zero start cost and some very low per-tuple
> cost, independent of the path's nominal cost values (which would now
On Sat, Sep 5, 2009 at 8:39 PM, Tom Lane wrote:
> I wrote:
>> It might be sufficient to have cost_nestloop just hardwire the knowledge
>> that certain inner path types have a different behavior here --- that
>> is, for a rescan there is zero start cost and some very low per-tuple
>> cost, independe
Here we go again. Following Tom's advice to not insert crocks in
add_path(), I've instead introduced a noopjoin path type which ignores
its inner side. This could possibly be simplified to just a "noop"
path that doesn't even include an outer side, but the way I've done it
here doesn't really cos
