Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
> Fixed the pstrdup problem by replacing with strlcpy() to stack-allocated
> variables (rather than palloc + memcpy as proposed in Michael's patch).
+1
> Tom Lane wrote:
>> I don't especially like the Asserts inside spinlocks, either.
> I didn't change these. It doesn't look to me that these asserts are
> worth very much as production code.
OK. If we ever see these hit in the buildfarm I might argue for
reconsidering, but without some evidence of that sort it's not
worth much concern.
>> I'm also rather befuddled by the fact that this code sets and clears
>> walrcv->latch outside the critical sections. If that field is used
>> by any other process, surely that's completely unsafe. If it isn't,
>> why is it being kept in shared memory?
> I think the latch is only used locally. Seems that it was only put in
> shmem to avoid a separate variable ...
Hm, I'm strongly tempted to move it to a separate static variable then.
That's not a bug fix, so maybe it only belongs in HEAD, but is there
value in keeping the branches in sync in this code? It sounded from
your commit message like they were pretty different already :-(
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers