Applied.
---
On Wed, Aug 29, 2012 at 08:51:40AM -0400, Bruce Momjian wrote:
> On Wed, Aug 29, 2012 at 12:56:26AM -0400, Tom Lane wrote:
> > Bruce Momjian writes:
> > > On Wed, Aug 29, 2012 at 12:24:26AM -0400, Alvaro Herrer
On Wed, Aug 29, 2012 at 12:56:26AM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > On Wed, Aug 29, 2012 at 12:24:26AM -0400, Alvaro Herrera wrote:
> >> It's a pretty strange line wrap you got in this version of the patch.
> >> Normally we just let the string run past the 78 char limit, without
Bruce Momjian writes:
> On Wed, Aug 29, 2012 at 12:24:26AM -0400, Alvaro Herrera wrote:
>> It's a pretty strange line wrap you got in this version of the patch.
>> Normally we just let the string run past the 78 char limit, without
>> cutting it in any way. And moving the start of the string to t
On Wed, Aug 29, 2012 at 12:24:26AM -0400, Alvaro Herrera wrote:
> Excerpts from Bruce Momjian's message of mar ago 28 22:21:27 -0400 2012:
> > On Tue, Aug 28, 2012 at 04:25:36PM -0400, Tom Lane wrote:
> > > Bruce Momjian writes:
> > > > Updated patch attached which just reports the file as empty.
Excerpts from Bruce Momjian's message of mar ago 28 22:21:27 -0400 2012:
> On Tue, Aug 28, 2012 at 04:25:36PM -0400, Tom Lane wrote:
> > Bruce Momjian writes:
> > > Updated patch attached which just reports the file as empty. I assume
> > > we don't want the extra text output for pg_ctl like we d
Bruce Momjian writes:
> On Tue, Aug 28, 2012 at 04:25:36PM -0400, Tom Lane wrote:
>> The backend side of this looks mostly sane to me (but drop the \n,
>> messages are not supposed to contain those). But the feof test proposed
> Removed. I thought we needed to add \n so that strings >80 would w
On Tue, Aug 28, 2012 at 04:25:36PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > Updated patch attached which just reports the file as empty. I assume
> > we don't want the extra text output for pg_ctl like we do for the
> > backend.
>
> The backend side of this looks mostly sane to me (but
Bruce Momjian writes:
> Updated patch attached which just reports the file as empty. I assume
> we don't want the extra text output for pg_ctl like we do for the
> backend.
The backend side of this looks mostly sane to me (but drop the \n,
messages are not supposed to contain those). But the fe
On Mon, Aug 27, 2012 at 10:17:43PM -0400, Bruce Momjian wrote:
> Seems pg_ctl would also need some cleanup if we change the error
> message and/or timing.
>
> I am thinking we should just change the error message in the postmaster
> and pg_ctl to say the file is empty, and call it done (no hint me
On Mon, Aug 27, 2012 at 09:59:10PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > On Mon, Aug 27, 2012 at 07:39:35PM -0400, Tom Lane wrote:
> >> I could get behind that, but I don't think the delay should be more than
> >> 100ms or so.
>
> > I took Alvaro's approach of a sleep. The file test
Bruce Momjian writes:
> On Mon, Aug 27, 2012 at 07:39:35PM -0400, Tom Lane wrote:
>> I could get behind that, but I don't think the delay should be more than
>> 100ms or so.
> I took Alvaro's approach of a sleep. The file test was already in a
> loop that went 100 times. Basically, if the lock
On Mon, Aug 27, 2012 at 07:39:35PM -0400, Tom Lane wrote:
> Alvaro Herrera writes:
> > How about having it sleep for a short while, then try again?
>
> I could get behind that, but I don't think the delay should be more than
> 100ms or so. It's important for the postmaster to acquire the lock (o
Alvaro Herrera writes:
> How about having it sleep for a short while, then try again?
I could get behind that, but I don't think the delay should be more than
100ms or so. It's important for the postmaster to acquire the lock (or
not) pretty quickly, or pg_ctl is going to get confused. If we ke
Robert Haas writes:
> On Mon, Aug 27, 2012 at 4:29 PM, Tom Lane wrote:
>> Perhaps something like:
>>
>> FATAL: lock file "foo" is empty
>> HINT: This may mean that another postmaster was starting at the
>> same time. If not, remove the lock file and try again.
> The problem with this is that i
Excerpts from Robert Haas's message of lun ago 27 18:02:06 -0400 2012:
> On Mon, Aug 27, 2012 at 4:29 PM, Tom Lane wrote:
> > Bruce Momjian writes:
> >> I have developed the attached patch to report a zero-length file, as you
> >> suggested.
> >
> > DIRECTORY_LOCK_FILE is entirely incorrect there
On Mon, Aug 27, 2012 at 4:29 PM, Tom Lane wrote:
> Bruce Momjian writes:
>> I have developed the attached patch to report a zero-length file, as you
>> suggested.
>
> DIRECTORY_LOCK_FILE is entirely incorrect there.
>
> Taking a step back, I don't think this message is much better than the
> exis
Bruce Momjian writes:
> I have developed the attached patch to report a zero-length file, as you
> suggested.
DIRECTORY_LOCK_FILE is entirely incorrect there.
Taking a step back, I don't think this message is much better than the
existing behavior of reporting "bogus data". Either way, it's not
On Fri, Jan 6, 2012 at 08:28:48AM -0500, Michael Beattie wrote:
> On Fri, Jan 6, 2012 at 6:13 AM, Magnus Hagander wrote:
>
> On Thu, Jan 5, 2012 at 23:19, Tom Lane wrote:
> > Magnus Hagander writes:
> >> On Thu, Jan 5, 2012 at 17:13, Tom Lane wrote:
> >>> I think link(2) would
On Fri, Jan 6, 2012 at 6:13 AM, Magnus Hagander wrote:
> On Thu, Jan 5, 2012 at 23:19, Tom Lane wrote:
> > Magnus Hagander writes:
> >> On Thu, Jan 5, 2012 at 17:13, Tom Lane wrote:
> >>> I think link(2) would create race conditions of its own. I'd be
> >>> inclined to suggest that maybe we s
On Thu, Jan 5, 2012 at 23:19, Tom Lane wrote:
> Magnus Hagander writes:
>> On Thu, Jan 5, 2012 at 17:13, Tom Lane wrote:
>>> I think link(2) would create race conditions of its own. I'd be
>>> inclined to suggest that maybe we should just special-case a zero length
>>> postmaster.pid file as me
Magnus Hagander writes:
> On Thu, Jan 5, 2012 at 17:13, Tom Lane wrote:
>> I think link(2) would create race conditions of its own. I'd be
>> inclined to suggest that maybe we should just special-case a zero length
>> postmaster.pid file as meaning "okay to proceed". In general, garbage
> That
On Thu, Jan 5, 2012 at 17:13, Tom Lane wrote:
> Heikki Linnakangas writes:
>> My laptop ran out of battery and turned itself off while I was just
>> starting up postmaster. After plugging in the charger and rebooting, I
>> got the following error when I tried to restart PostgreSQL:
>
>> FATAL: b
Heikki Linnakangas writes:
> My laptop ran out of battery and turned itself off while I was just
> starting up postmaster. After plugging in the charger and rebooting, I
> got the following error when I tried to restart PostgreSQL:
> FATAL: bogus data in lock file "postmaster.pid": ""
> postm
On Thu, Jan 5, 2012 at 8:23 AM, Magnus Hagander wrote:
> On Thu, Jan 5, 2012 at 14:18, Heikki Linnakangas
> wrote:
>> My laptop ran out of battery and turned itself off while I was just starting
>> up postmaster. After plugging in the charger and rebooting, I got the
>> following error when I tri
On Thu, Jan 5, 2012 at 14:18, Heikki Linnakangas
wrote:
> My laptop ran out of battery and turned itself off while I was just starting
> up postmaster. After plugging in the charger and rebooting, I got the
> following error when I tried to restart PostgreSQL:
>
> FATAL: bogus data in lock file "
My laptop ran out of battery and turned itself off while I was just
starting up postmaster. After plugging in the charger and rebooting, I
got the following error when I tried to restart PostgreSQL:
FATAL: bogus data in lock file "postmaster.pid": ""
postmaster.pid file was present in the dat
26 matches
Mail list logo
