We have a cluster with four nodes, each running a postgres 7.4.8
database. Due to a large amount of pilot error and possibly hardware
problems (still trying to get to the bottom of it all), two of the
databases won't start, and I can't login to two others, with any
registered user.
Two of the node
On 9/22/07, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Morris Goldstein" <[EMAIL PROTECTED]> writes:
> > Two of the nodes have logs that look like this:
>
> > 2007-09-22 07:06:05 [3060] LOG: could not open file
> > "/var/lib/pgsql/data/pg_xlog/000
Sorry to reply to myself but here's a bit more info. That strace shows
a crash. The node that was denying logins is now complaining about
checkpoint file 000...000. It appears to be the case that a few
attempts to start converts a db that rejects logins to one that
crashes on startup. (When I first
On 9/22/07, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Morris Goldstein" <[EMAIL PROTECTED]> writes:
> > ...
> > 2007-09-22 07:06:05 [3060] LOG: could not open file
> > "/var/lib/pgsql/data/pg_xlog/" (log file 0, segment 0): No
>
pg_dump --help says:
-b, --blobs include large objects in dump
What is the definition of "large object"? Is it a certain set of types
(e.g. text)? Long values stored in these types? What qualifies as
long? In general, how can I tell if I need the -b flag (postgres 7.4).
Morris Goldstein
Thanks for your help with pg_resetxlog. It recovered all of our databases,
and it looks like we got lucky in that no updates were lost.
We are deciding on the goals for our next release, and one of the issues on
the table is an upgrade to postgres 8. Can you comment on the improvements
in performa
On 9/25/07, Scott Marlowe <[EMAIL PROTECTED]> wrote:
>
> But since it hit all of your machines, and at about the same time, I
> tend to think that someone did something to these machines that caused
> this issue, and it's not a 7.4.x problem.
I'm sure it is pilot error, and we're still trying to
Suppose I have a large table with no indexes, and I scan the entire
thing. What is the impact on the shared buffers? I'm interested in
three scenarios:
- Scan done in SQL using SELECT, (via JDBC if it matters).
- Scan done using SQL COPY.
- Scan done using psql COPY.
I suspect that the SELECT sca
Suppose I have a database with $PGDATA on /dev/sda, and a tablespace
directory on /dev/sdb. Will Postgres start successfully if /dev/sda is
mounted and /dev/sdb is not? If not, why not?
Morris
On Mon, Mar 31, 2008 at 2:10 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Morris Goldstein" <[EMAIL PROTECTED]> writes:
> > Suppose I have a database with $PGDATA on /dev/sda, and a tablespace
> > directory on /dev/sdb. Will Postgres start successfully if /dev/s
On Wed, Apr 2, 2008 at 8:44 AM, Zdenek Kotala <[EMAIL PROTECTED]> wrote:
> Morris Goldstein napsal(a):
> > - Postgres running normally on /dev/sda and /dev/sdb.
> > - Update to table in /dev/sdb tablespace is committed but still exists in
> WAL.
> > - Postgr
On Wed, Apr 2, 2008 at 10:55 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Morris Goldstein" <[EMAIL PROTECTED]> writes:
>
> > Without going into a lot of details about our application, I'll just
> > say that the ability to start Postgres with just th
aining that template0 and template1 haven't been
vacuumed in the over 2 billion transactions encountered by testdb? (I
never touch template0 and template1.) If that's what's going on, I
take it that I have no risk of data loss? And is there some reason to
vacuum these databases, (other tha
13 matches
Mail list logo
