Peter Eisentraut wrote:
I have reworked your build rules so they look more like the idioms that we
already use for other similar cases. This should fix the troubles you
describe and others.
There are a couple of problems with your updated patch:
1) utils/probes.h needs to be generated befo
Peter Eisentraut wrote:
Robert Lor wrote:
Please find the patch attached per this thread
http://archives.postgresql.org/pgsql-hackers/2008-02/msg00912.php
Why do we have two dtrace calls in the makefiles now?
The build process for Mac OS X is different than that of Solaris. The
dtrace
Robert Lor wrote:
> 2) Need help figuring out how to copy src/backend/util/probes.d from src
> tree to
> bld tree at build time. It works fine if compilation is done in the src
> tree.
I have reworked your build rules so they look more like the idioms that we
already use for other similar cases.
Neil Conway <[EMAIL PROTECTED]> writes:
> On Wed, 2008-02-27 at 15:07 -0500, Tom Lane wrote:
>> Negative refcount does not prove that the SRF itself hasn't
>> still got a pointer to the tupdesc.
> That sounds quite bizarre. The SRF has already finished execution at
> this point, so keeping a point
Robert Lor wrote:
> Please find the patch attached per this thread
> http://archives.postgresql.org/pgsql-hackers/2008-02/msg00912.php
Why do we have two dtrace calls in the makefiles now? I understand you added
the "new" mechanism to support Mac OS X, but doesn't Solaris support that
mechanism
Referring to tuplesort.c andtuplestore.c
BACKGROUND: Starting from dumptuples() [ tuplesort.c ] write functions move
the tuple from a buffer to another in order to finally write it in a logical
tape. Is there a way (even the most inefficient way) to use current
read/write functions prov
Robert Lor wrote:
> 3) Note on src/backend/Makefile
> The current rule below does not work. After expansion, utils/probes.d
> needs
> to come right after -s, but currently it shows up at the end after
> all the .o files.
I fixed that part. Note again that a buildfarm animal testing the dtra
On Wed, 2008-02-27 at 15:07 -0500, Tom Lane wrote:
> Negative refcount does not prove that the SRF itself hasn't
> still got a pointer to the tupdesc.
That sounds quite bizarre. The SRF has already finished execution at
this point, so keeping a pointer to the tupledesc around would only make
sense
Neil Conway <[EMAIL PROTECTED]> writes:
> On Tue, 2008-02-26 at 00:17 -0800, Neil Conway wrote:
>> You didn't comment on my proposed solution (FreeTupleDesc() iff refcount
>> == -1).
I still find that entirely unsafe, particularly for something you
propose to back-patch into stable branches. Nega
On Tue, 2008-02-26 at 12:09 -0800, Neil Conway wrote:
> I'd like to apply this change to back branches reasonably soon, so if
> you have a better way to do the FreeTupleDesc() hack, let me know.
Barring any objections, I'll apply this to HEAD and back branches
tonight or tomorrow.
-Neil
--
Alvaro Herrera wrote:
Perhaps you need a $< there:
$(DTRACE) $(DTRACEFLAGS) -G -s $< $(call expand_subsys,$^) -o $@
However I think you would also need to $(filter-out) the $< from $^.
Your suggestion with $(filter-out ...) works. Thanks!
Attached is the updated patch.
Regards,
-R
Robert Lor wrote:
> 3) Note on src/backend/Makefile
> The current rule below does not work. After expansion, utils/probes.d
> needs
> to come right after -s, but currently it shows up at the end after all
> the .o files.
>
> utils/probes.o: utils/probes.d $(SUBDIROBJS)
> $(DTRACE) $
Please find the patch attached per this thread
http://archives.postgresql.org/pgsql-hackers/2008-02/msg00912.php
Notes to committer.
1) Please remove src/include/pg_trace.h as it's no longer needed
2) Need help figuring out how to copy src/backend/util/probes.d from src
tree to
bld tree at bu
Magnus Hagander wrote:
I've tested on Vista and XP, but additional testing would be useful
(Andrew, Magnus?). Please apply to head, 8.3 and 8.2
Other than Heikkis comments:
We obviously need to test-build on mingw, so if someone can do that, pleae
do. If not, I'll try to get my VM up an
On Thu, Feb 21, 2008 at 03:02:07PM +, Dave Page wrote:
> The attached patch fixes problems reported primarily on Vista, but
> also on some Windows 2003 and XP installations in which initdb reports
> that it cannot find postgres.exe.
>
> This occurs because of security-related changes implement
15 matches
Mail list logo
