On Sat, Sep 24, 2011 at 22:23, Robert Haas wrote:
> It's not the reviewer's job to convince Tom of anything in particular,
> but I think it's helpful for them to state their opinion, whatever it
> may be (agreeing with Tom, disagreeing with Tom, or whatever).
My opinion is that this can be made s
On Sat, Sep 24, 2011 at 1:51 PM, Jeff Janes wrote:
> It seems like everyone agrees that this feature is wanted, but Tom is
> still very much opposed to the general approach to implement it, as
> being too dangerous.
> Is it the reviewer's job to try to convince him otherwise?
It's not the reviewe
On Fri, Sep 9, 2011 at 2:51 AM, Marti Raudsepp wrote:
> On Thu, Sep 8, 2011 at 03:22, Robert Haas wrote:
>> On Wed, Sep 7, 2011 at 5:24 PM, Alvaro Herrera
>> wrote:
>>> I remember we had bugs whereby an encoding conversion would fail,
>>> leading to elog trying to report this problem, but this a
On Thu, Sep 8, 2011 at 03:22, Robert Haas wrote:
> On Wed, Sep 7, 2011 at 5:24 PM, Alvaro Herrera
> wrote:
>> I remember we had bugs whereby an encoding conversion would fail,
>> leading to elog trying to report this problem, but this attempt would
>> also incur a conversion step, failing recursi
On Wed, Sep 7, 2011 at 5:24 PM, Alvaro Herrera
wrote:
> Excerpts from Marti Raudsepp's message of mié sep 07 18:09:32 -0300 2011:
>> On Wed, Sep 7, 2011 at 22:42, Alvaro Herrera
>> wrote:
>> > A mishandled encoding conversion could be problematic, so that needs to
>> > be carefully considered (p
Excerpts from Marti Raudsepp's message of mié sep 07 18:09:32 -0300 2011:
> On Wed, Sep 7, 2011 at 22:42, Alvaro Herrera
> wrote:
> > A mishandled encoding conversion could be problematic, so that needs to
> > be carefully considered (perhaps just shut off unconditionally).
>
> Are you referring
Robert Haas writes:
> On Wed, Sep 7, 2011 at 4:15 PM, Tom Lane wrote:
>> Keep in mind that in the postmaster, elog(ERROR) *is* a crash.
> Right... but a function that returns -1 to indicate that something
> didn't work should be OK, as long as whatever it does is otherwise
> extremely boring.
T
On Wed, Sep 7, 2011 at 22:42, Alvaro Herrera wrote:
> A mishandled encoding conversion could be problematic, so that needs to
> be carefully considered (perhaps just shut off unconditionally).
Are you referring to log file encoding or something else? The log file
is already potentially mixed-enco
On Wed, Sep 7, 2011 at 4:15 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Sep 7, 2011 at 3:42 PM, Alvaro Herrera
>> wrote:
>>> A mishandled encoding conversion could be problematic, so that needs to
>>> be carefully considered (perhaps just shut off unconditionally).
>
>> It's not really
Robert Haas writes:
> On Wed, Sep 7, 2011 at 3:42 PM, Alvaro Herrera
> wrote:
>> A mishandled encoding conversion could be problematic, so that needs to
>> be carefully considered (perhaps just shut off unconditionally).
> It's not really a problem for the postmaster if something just plain
> ol
On Wed, Sep 7, 2011 at 4:00 PM, Tom Lane wrote:
> Alvaro Herrera writes:
>> Excerpts from Robert Haas's message of mar sep 06 19:57:07 -0300 2011:
>>> TBH, I'm very unclear what could cause the postmaster to go belly-up
>>> copying a bounded amount of data out of shared memory for logging
>>> pur
On Wed, Sep 7, 2011 at 3:42 PM, Alvaro Herrera
wrote:
>> TBH, I'm very unclear what could cause the postmaster to go belly-up
>> copying a bounded amount of data out of shared memory for logging
>> purposes only. It's surely possible to make the code safe against any
>> sequence of bytes that mig
Alvaro Herrera writes:
> Excerpts from Robert Haas's message of mar sep 06 19:57:07 -0300 2011:
>> TBH, I'm very unclear what could cause the postmaster to go belly-up
>> copying a bounded amount of data out of shared memory for logging
>> purposes only. It's surely possible to make the code safe
Excerpts from Robert Haas's message of mar sep 06 19:57:07 -0300 2011:
> On Tue, Sep 6, 2011 at 6:05 PM, Tom Lane wrote:
> > Robert Haas writes:
> >> On Tue, Sep 6, 2011 at 5:34 PM, Tom Lane wrote:
> >>> And I doubt
> >>> that the goal is worth taking risks for.
> >
> >> I am unable to count the
On Tue, Sep 6, 2011 at 6:05 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Sep 6, 2011 at 5:34 PM, Tom Lane wrote:
>>> And I doubt
>>> that the goal is worth taking risks for.
>
>> I am unable to count the number of times that I have had a customer
>> come to me and say "well, the backend
Robert Haas wrote:
> Tom Lane wrote:
>> Marti Raudsepp writes:
>>> This patch adds the backend's current running query to the
>>> "backend crash" message.
>>
>> Sorry, this patch is entirely unacceptable. We cannot have the
>> postmaster's functioning depending on the contents of shared
>> memo
Robert Haas writes:
> On Tue, Sep 6, 2011 at 5:34 PM, Tom Lane wrote:
>> And I doubt
>> that the goal is worth taking risks for.
> I am unable to count the number of times that I have had a customer
> come to me and say "well, the backend crashed". And I go look at
> their logs and I have no id
On Wed, Sep 7, 2011 at 00:34, Tom Lane wrote:
> No, I don't think your attempts to validate the data are
> adequate, nor do I believe they can be made adequate.
Can you think of any concrete situations that would fail the current validation?
As far as I can tell, the only pointer I'm following f
On Tue, Sep 6, 2011 at 5:34 PM, Tom Lane wrote:
> Marti Raudsepp writes:
>> This patch adds the backend's current running query to the "backend
>> crash" message.
>
> Sorry, this patch is entirely unacceptable. We cannot have the
> postmaster's functioning depending on the contents of shared mem
Marti Raudsepp writes:
> This patch adds the backend's current running query to the "backend
> crash" message.
Sorry, this patch is entirely unacceptable. We cannot have the
postmaster's functioning depending on the contents of shared memory
still being valid ... most especially not when we know
On Tue, Sep 6, 2011 at 4:52 PM, Marti Raudsepp wrote:
> This patch adds the backend's current running query to the "backend
> crash" message.
>
> The crashing query is often a good starting point in debugging the
> cause, and much more easily accessible than core dumps.
>
> Example output:
> LOG:
Hi list,
This patch adds the backend's current running query to the "backend
crash" message.
The crashing query is often a good starting point in debugging the
cause, and much more easily accessible than core dumps.
Example output:
LOG: server process (PID 31451) was terminated by signal 9: Kil
22 matches
Mail list logo
