On Wed, 2006-08-02 at 18:49 -0400, Tom Lane wrote:
> Simon Riggs <simon@2ndquadrant.com> writes:
> > [I have an outstanding question on how to include LWlock support into
> > the archiver, required to flesh out the feature set, and of course
> > assuming these patches being accepted.]
>
> The archiver is deliberately designed not to be connected to shared
> memory. If you want to change that you'll have to make a very strong
> case why we should give up the safety and security advantages of it.

We should let the user decide.

If archiver_timeout is a server start GUC then we can attach to shared
memory if it is set, if not we avoid that.

If they are in a position to want that functionality they can make that
trade-off.

--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com


---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

Simon Riggs <simon@2ndquadrant.com> writes:
> On Wed, 2006-08-02 at 18:49 -0400, Tom Lane wrote:
>> The archiver is deliberately designed not to be connected to shared
>> memory. If you want to change that you'll have to make a very strong
>> case why we should give up the safety and security advantages of it.

> We should let the user decide.

Really? The way we let the user decide whether to run as root or not?
I don't think we make security-related decisions that way.

You haven't actually explained what you want this for, so the entire
discussion is operating in a vacuum ...

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Tom Lane <tgl@sss.pgh.pa.us> writes:

> Simon Riggs <simon@2ndquadrant.com> writes:
>> On Wed, 2006-08-02 at 18:49 -0400, Tom Lane wrote:
>>> The archiver is deliberately designed not to be connected to shared
>>> memory. If you want to change that you'll have to make a very strong
>>> case why we should give up the safety and security advantages of it.
>
>> We should let the user decide.
>
> Really? The way we let the user decide whether to run as root or not?
> I don't think we make security-related decisions that way.

Well there is also precedent the other way, namely fsync.

I think the key factor is, is it a decision the user may know more about than
we do. In the case of fsync the user may well know that the data isn't
important (yet) such as in the case of an initial database load. In general I
would say security decisions are more prone rather than less to having this
property.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com


---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend