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
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 process.
The database cluster will be initialized with locale en_GB.UTF-
38 matches
Mail list logo
