Major Problem, need help! Can't run our website!

Started by ITS ONT Alcazar, Jose Aguedo Cabout 20 years ago10 messages
#1ITS ONT Alcazar, Jose Aguedo C
jacalcazar@exportbank.com.ph

Anyone!

Before anything else, I have no background in PostgreSQL. But I have a
little knowledge in Linux. We used postgreSQL to run one of our website. It
runs in Redhat Linux 7.3. Our System Administrator, who used to maintain
this server, had resigned and didn't have a proper documentation on how to
maintain this server. Right now, our NEW System Administrator is clearing
some logs in /var/lib/pgsql/data/pg_xlog in able to free some space in the
/var file system. It used to work before, but now, its not working anymore.
Information below is the message we are encountering when we are trying to
connect to the website. Please, ANYONE, help us!

Warning: Unable to connect to PostgreSQL server: could not connect to
server: Connection refused Is the server running on host localhost and
accepting TCP/IP connections on port 5432? in
/var/lib/phplib-7.2d/php/db_pgsql.inc on line 48
Database error: Link-ID == false, pconnect failed
ODBC Error: 0 ()
Session halted.

Thanks! --AGUEDO

#2Tim Allen
tim@proximity.com.au
In reply to: ITS ONT Alcazar, Jose Aguedo C (#1)
Re: Major Problem, need help! Can't run our website!

ITS ONT Alcazar, Jose Aguedo C wrote:

Anyone!

Before anything else, I have no background in PostgreSQL. But I have a
little knowledge in Linux. We used postgreSQL to run one of our website. It
runs in Redhat Linux 7.3. Our System Administrator, who used to maintain
this server, had resigned and didn't have a proper documentation on how to
maintain this server. Right now, our NEW System Administrator is clearing
some logs in /var/lib/pgsql/data/pg_xlog in able to free some space in the
/var file system. It used to work before, but now, its not working anymore.
Information below is the message we are encountering when we are trying to
connect to the website. Please, ANYONE, help us!

We've seen reports of people firing this particular foot-gun before,
haven't we? Would it make sense to rename pg_xlog to something that
doesn't sound like it's "just" full of log files? Eg pg_wal - something
where the half-educated will have no idea what it is, and therefore not
think they know what they can do with it.

Tim

--
-----------------------------------------------
Tim Allen tim@proximity.com.au
Proximity Pty Ltd http://www.proximity.com.au/

#3Tom Lane
tgl@sss.pgh.pa.us
In reply to: Tim Allen (#2)
Re: [HACKERS] Major Problem, need help! Can't run our website!

Tim Allen <tim@proximity.com.au> writes:

We've seen reports of people firing this particular foot-gun before,
haven't we? Would it make sense to rename pg_xlog to something that
doesn't sound like it's "just" full of log files? Eg pg_wal - something
where the half-educated will have no idea what it is, and therefore not
think they know what they can do with it.

There's something in what you say. We'd have to rename pg_clog as well,
since that's even more critical than pg_xlog ...

regards, tom lane

#4Christopher Kings-Lynne
chriskl@familyhealth.com.au
In reply to: Tim Allen (#2)
Re: [HACKERS] Major Problem, need help! Can't run our website!

We've seen reports of people firing this particular foot-gun before,
haven't we? Would it make sense to rename pg_xlog to something that
doesn't sound like it's "just" full of log files? Eg pg_wal - something
where the half-educated will have no idea what it is, and therefore not
think they know what they can do with it.

Would it be wise or insane for us to to mention in the startup error a
HINT that if you've removed such files, only hope is full restore from
backup or pg_resetxlog with data loss?

Chris

#5Tom Lane
tgl@sss.pgh.pa.us
In reply to: Christopher Kings-Lynne (#4)
Re: [HACKERS] Major Problem, need help! Can't run our website!

Christopher Kings-Lynne <chriskl@familyhealth.com.au> writes:

Would it be wise or insane for us to to mention in the startup error a
HINT that if you've removed such files, only hope is full restore from
backup or pg_resetxlog with data loss?

Not sure that we should have a HINT recommending a worst-case-scenario
course of action as the first resort. We'll have people blowing away
their data for what might be relatively fixable problems (eg, bogus
permissions on the pg_xlog directory, which I think was an issue that
just came up a day or two ago ...)

(We're all really jumping to conclusions here anyway. The guy may have
been foolish to remove xlog files, but that doesn't explain why his
postmaster isn't running. There's some facts missing in that report.)

regards, tom lane

#6Rod Taylor
pg@rbt.ca
In reply to: Tom Lane (#3)
Re: [HACKERS] Major Problem, need help! Can't run our

On Mon, 2005-11-14 at 23:02 -0500, Tom Lane wrote:

Tim Allen <tim@proximity.com.au> writes:

We've seen reports of people firing this particular foot-gun before,
haven't we? Would it make sense to rename pg_xlog to something that
doesn't sound like it's "just" full of log files? Eg pg_wal - something
where the half-educated will have no idea what it is, and therefore not
think they know what they can do with it.

There's something in what you say. We'd have to rename pg_clog as well,
since that's even more critical than pg_xlog ...

Rename them to pg_donttouchthis and pg_youneedthis.
--

#7Tom Lane
tgl@sss.pgh.pa.us
In reply to: Rod Taylor (#6)
Re: [HACKERS] Major Problem, need help! Can't run our

Rod Taylor <pg@rbt.ca> writes:

On Mon, 2005-11-14 at 23:02 -0500, Tom Lane wrote:

There's something in what you say. We'd have to rename pg_clog as well,
since that's even more critical than pg_xlog ...

Rename them to pg_donttouchthis and pg_youneedthis.

:-)

On a more serious level: Tim's suggestion of "pg_wal" for pg_xlog sounds
fine to me. How about "pg_trans" for pg_clog, by analogy to the
existing pg_subtrans? Nothing else in the standard layout looks like
it's got a name that a newbie would think means discardable data.

regards, tom lane

#8Jonah H. Harris
jonah.harris@gmail.com
In reply to: Tom Lane (#7)
Re: [HACKERS] Major Problem, need help! Can't run our

I agree.
(sorry again Tom... dang GMAIL should default reply to all.... grrrr!)

Show quoted text

On 11/14/05, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Rod Taylor <pg@rbt.ca> writes:

On Mon, 2005-11-14 at 23:02 -0500, Tom Lane wrote:

There's something in what you say. We'd have to rename pg_clog as well,
since that's even more critical than pg_xlog ...

Rename them to pg_donttouchthis and pg_youneedthis.

:-)

On a more serious level: Tim's suggestion of "pg_wal" for pg_xlog sounds
fine to me. How about "pg_trans" for pg_clog, by analogy to the
existing pg_subtrans? Nothing else in the standard layout looks like
it's got a name that a newbie would think means discardable data.

regards, tom lane

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

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

#9Trent Shipley
tshipley@deru.com
In reply to: Tim Allen (#2)
Re: [ADMIN] Major Problem, need help! Can't run our website!

On Monday 2005-11-14 20:48, Tim Allen wrote:

<snip>
OOPS deleted pg_xlog because surely it was only a log file.
</snip>

We've seen reports of people firing this particular foot-gun before,
haven't we? Would it make sense to rename pg_xlog to something that
doesn't sound like it's "just" full of log files? Eg pg_wal - something
where the half-educated will have no idea what it is, and therefore not
think they know what they can do with it.

Tim

Renaming the file sounds like an excellent design decision since the current
name is a proven "human factor" bug.

#10Joshua D. Drake
jd@commandprompt.com
In reply to: Trent Shipley (#9)
Re: [ADMIN] Major Problem, need help! Can't run our website!

Renaming the file sounds like an excellent design decision since the current
name is a proven "human factor" bug.

I am sorry, but as soon as you look at the files it is obvious that they
are not "just" log files. If someone
is going to delete the xlog they are going to do it no matter what we
call it. Unless of course we change
the directory to pg_xlogs_do_not_ever_delete, but I doubt that would
help either.

Sincerely,
Joshua D. Drake

Show quoted text

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match