Tom Lane wrote:
>
> Fascinating. So maybe there is something to Bosco's theory of something
> holding open the old pidfile.
There could also have been a corrupt in-memory/cached descriptor in the
filesystem code that never needed flushing to disk? That would help
explain why it fully went away
On 6 March 2012 19:28, Tom Lane wrote:
> Thom Brown writes:
>> On 6 March 2012 18:20, Tom Lane wrote:
>>> Still, I agree with your point: Thom should reboot and see if the
>>> misbehavior is still there, because that would be useful info for his
>>> bug report.
>
>> After a reboot, initdb comple
Thom Brown writes:
> On 6 March 2012 18:20, Tom Lane wrote:
>> Still, I agree with your point: Thom should reboot and see if the
>> misbehavior is still there, because that would be useful info for his
>> bug report.
> After a reboot, initdb completes successfully. I don't think it
> performed
On 6 March 2012 18:51, dennis jenkins wrote:
> On Tue, Mar 6, 2012 at 10:11 AM, Thom Brown wrote:
>> On 6 March 2012 16:04, Adrian Klaver wrote:
>>> The postmaster.pid is located outside the data directory, but points back
>>> to the
>>> data directory. Not sure where Debian, though at a gues
On 6 March 2012 18:20, Tom Lane wrote:
> Bosco Rama writes:
>> Thom Brown wrote:
>>> I've done that a couple times, but no effect. I think Tom's point
>>> about a filesystem bug is probably right.
>
>> Have you rebooted since this started? There may be a process that is
>> holding the pid file
On Tue, Mar 6, 2012 at 10:11 AM, Thom Brown wrote:
> On 6 March 2012 16:04, Adrian Klaver wrote:
>> The postmaster.pid is located outside the data directory, but points back to
>> the
>> data directory. Not sure where Debian, though at a guess somewhere in /var.
>> Any way search for postmaste
Bosco Rama writes:
> Thom Brown wrote:
>> I've done that a couple times, but no effect. I think Tom's point
>> about a filesystem bug is probably right.
> Have you rebooted since this started? There may be a process that is
> holding the pid file 'deleted but present' until the process terminat
Sry, forgot to add list.
Thom Brown wrote:
>
> I've done that a couple times, but no effect. I think Tom's point
> about a filesystem bug is probably right.
Have you rebooted since this started? There may be a process that is
holding the pid file 'deleted but present' until the process termina
Thom Brown writes:
> On 6 March 2012 18:01, Adrian Klaver wrote:
>> A thought, what if you do rm -rf * in the data directory?
> I've done that a couple times, but no effect. I think Tom's point
> about a filesystem bug is probably right.
Yeah, given your "touch" experiment I think that you hav
On Tue, Mar 6, 2012 at 19:03, Thom Brown wrote:
> On 6 March 2012 18:01, Adrian Klaver wrote:
>> On Tuesday, March 06, 2012 9:53:52 am Tom Lane wrote:
>>> Thom Brown writes:
>>> > /home/thom/Development/data was causing problems so:
>>> >
>>> > mv data databroken
>>> > mkdir data
>>> > initdb
>>
On 6 March 2012 18:01, Adrian Klaver wrote:
> On Tuesday, March 06, 2012 9:53:52 am Tom Lane wrote:
>> Thom Brown writes:
>> > /home/thom/Development/data was causing problems so:
>> >
>> > mv data databroken
>> > mkdir data
>> > initdb
>> >
>> > ... working fine again. I then used the postmaste
On Tuesday, March 06, 2012 9:53:52 am Tom Lane wrote:
> Thom Brown writes:
> > /home/thom/Development/data was causing problems so:
> >
> > mv data databroken
> > mkdir data
> > initdb
> >
> > ... working fine again. I then used the postmaster.pid from this when
> > started up. But if I do:
>
On 6 March 2012 17:53, Tom Lane wrote:
> Thom Brown writes:
>> /home/thom/Development/data was causing problems so:
>
>> mv data databroken
>> mkdir data
>> initdb
>
>> ... working fine again. I then used the postmaster.pid from this when
>> started up. But if I do:
>
>> pg_ctl stop
>> rm -rf d
On Tuesday, March 06, 2012 9:48:51 am Thom Brown wrote:
> On 6 March 2012 17:45, Adrian Klaver wrote:
> > On Tuesday, March 06, 2012 9:25:17 am Thom Brown wrote:
> >> These are in my env output:
> >>
> >> PATH=/home/thom/Development/psql/bin/:/usr/lib/lightdm/lightdm:/usr/loca
> >> l/s bin:/usr/l
Thom Brown writes:
> /home/thom/Development/data was causing problems so:
> mv data databroken
> mkdir data
> initdb
> ... working fine again. I then used the postmaster.pid from this when
> started up. But if I do:
> pg_ctl stop
> rm -rf data
> mv databroken data
> initdb
> ... error messag
On 6 March 2012 17:46, Tom Lane wrote:
> Thom Brown writes:
>> On 6 March 2012 16:31, Tom Lane wrote:
>>> [ scratches head... ] I can't reproduce it with current git tip.
>
>> And I don't think I can reproduce this if I remove that directory.
>> I've seen this issue about 3 or 4 times in the pa
On 6 March 2012 17:45, Adrian Klaver wrote:
> On Tuesday, March 06, 2012 9:25:17 am Thom Brown wrote:
>
>>
>> These are in my env output:
>>
>> PATH=/home/thom/Development/psql/bin/:/usr/lib/lightdm/lightdm:/usr/local/s
>> bin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
>> PGDATA=/home
On Tuesday, March 06, 2012 9:43:00 am Tom Lane wrote:
> Adrian Klaver writes:
> > The postmaster.pid is located outside the data directory, but points back
> > to the data directory. Not sure where Debian, though at a guess
> > somewhere in /var. Any way search for postmaster.pid.
>
> Really?
Thom Brown writes:
> On 6 March 2012 16:31, Tom Lane wrote:
>> [ scratches head... ] I can't reproduce it with current git tip.
> And I don't think I can reproduce this if I remove that directory.
> I've seen this issue about 3 or 4 times in the past, and fixed it by
> ditching the old data dir
On Tuesday, March 06, 2012 9:25:17 am Thom Brown wrote:
>
> These are in my env output:
>
> PATH=/home/thom/Development/psql/bin/:/usr/lib/lightdm/lightdm:/usr/local/s
> bin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
> PGDATA=/home/thom/Development/data/
> PGPORT=5488
>
> This appe
Adrian Klaver writes:
> The postmaster.pid is located outside the data directory, but points back to
> the
> data directory. Not sure where Debian, though at a guess somewhere in /var.
> Any way search for postmaster.pid.
Really? That seems like an extremely dangerous/stupid/unnecessary hac
On 6 March 2012 17:16, Tom Lane wrote:
> Thom Brown writes:
>> Looking back through my terminal log, one thing might lend a clue from
>> before I tried rebuliding it:
>
>> thom@swift:~/Development$ pg_ctl stop
>> waiting for server to shut downcd .postgre.s
>> .
>>
>
>
>
>> .
On Tuesday, March 06, 2012 9:09:41 am Thom Brown wrote:
> On 6 March 2012 17:00, Adrian Klaver wrote:
> > On Tuesday, March 06, 2012 8:44:10 am Thom Brown wrote:
> >> >> And if I start my development copy, this is the content of its
> >> >> postmaster.pid:
> >> >>
> >> >> 27061
> >> >> /home/thom
Thom Brown writes:
> Looking back through my terminal log, one thing might lend a clue from
> before I tried rebuliding it:
> thom@swift:~/Development$ pg_ctl stop
> waiting for server to shut downcd .postgre.s
> .
>
> ^C
> thom@swift:~/Development$ pg_ctl stop
> pg_ct
On 6 March 2012 17:00, Adrian Klaver wrote:
> On Tuesday, March 06, 2012 8:44:10 am Thom Brown wrote:
>
>> >> And if I start my development copy, this is the content of its
>> >> postmaster.pid:
>> >>
>> >> 27061
>> >> /home/thom/Development/data
>> >> 1331050950
>> >> 5488
>> >> /tmp
>> >> localh
On Tuesday, March 06, 2012 8:44:10 am Thom Brown wrote:
> >> And if I start my development copy, this is the content of its
> >> postmaster.pid:
> >>
> >> 27061
> >> /home/thom/Development/data
> >> 1331050950
> >> 5488
> >> /tmp
> >> localhost
> >> 5488001 191365126
> >
> > So how are getting
On 6 March 2012 16:40, Adrian Klaver wrote:
> On Tuesday, March 06, 2012 8:24:20 am Thom Brown wrote:
>>
>>
>> No, only the ones running as the postgres user.
>
> In my original read, I missed the part you had the Ubuntu/Debian packaged
> version running.
>
>>
>> Here's the contents of the pid fil
On Tuesday, March 06, 2012 8:24:20 am Thom Brown wrote:
>
>
> No, only the ones running as the postgres user.
In my original read, I missed the part you had the Ubuntu/Debian packaged
version running.
>
> Here's the contents of the pid file in /var/lib/postgresql/9.1/main/
>
> 1199
> /var/lib
On 6 March 2012 16:31, Tom Lane wrote:
> Thom Brown writes:
>> On 6 March 2012 16:02, Tom Lane wrote:
>>> Um ... I assume this is some patched version rather than pristine
>>> sources? It's pretty hard to explain why it's falling over like that.
>
>> No, I did a "git stash", "git clean -f" and
Thom Brown writes:
> On 6 March 2012 16:02, Tom Lane wrote:
>> Um ... I assume this is some patched version rather than pristine
>> sources? It's pretty hard to explain why it's falling over like that.
> No, I did a "git stash", "git clean -f" and "git pull" before trying to build.
[ scratches
On 6 March 2012 16:18, Adrian Klaver wrote:
> On Tuesday, March 06, 2012 8:11:20 am Thom Brown wrote:
>> On 6 March 2012 16:04, Adrian Klaver wrote:
>> > The postmaster.pid is located outside the data directory, but points back
>> > to the data directory. Not sure where Debian, though at a gues
On 6 March 2012 16:11, Thom Brown wrote:
> On 6 March 2012 16:04, Adrian Klaver wrote:
>> The postmaster.pid is located outside the data directory, but points back to
>> the
>> data directory. Not sure where Debian, though at a guess somewhere in /var.
>> Any way search for postmaster.pid.
>
>
On Tuesday, March 06, 2012 8:11:20 am Thom Brown wrote:
> On 6 March 2012 16:04, Adrian Klaver wrote:
> > The postmaster.pid is located outside the data directory, but points back
> > to the data directory. Not sure where Debian, though at a guess
> > somewhere in /var. Any way search for postma
On 6 March 2012 16:04, Adrian Klaver wrote:
> The postmaster.pid is located outside the data directory, but points back to
> the
> data directory. Not sure where Debian, though at a guess somewhere in /var.
> Any way search for postmaster.pid.
I'm not sure, because if I use a new data director
On 6 March 2012 16:02, Tom Lane wrote:
> Thom Brown writes:
>> thom@swift:~/Development$ initdb
>> The files belonging to this database system will be owned by user "thom".
>> This user must also own the server process.
>
>> The database cluster will be initialized with locale en_GB.UTF-8.
>> The
On Tuesday, March 06, 2012 7:46:37 am Thom Brown wrote:
> Hi all,
>
> After building Postgres and trying an initdb, I'm getting the following:
>
>
> thom@swift:~/Development$ initdb
> The files belonging to this database system will be owned by user "thom".
> This user must also own the server p
Thom Brown writes:
> thom@swift:~/Development$ initdb
> The files belonging to this database system will be owned by user "thom".
> This user must also own the server process.
> The database cluster will be initialized with locale en_GB.UTF-8.
> The default database encoding has accordingly been
37 matches
Mail list logo
