On 10/08/2013 03:55 AM, shailesh singh wrote:
I had got this message while running vacuum full from backend . Now My
database is not starting , Help pls.
backend> vacuum full debug;
WARNING: database "debug" must be vacuumed within 99 transactions
HINT: To avoid a database shutdown, execut
Adrian Klaver-3 wrote
> On 10/08/2013 03:55 AM, shailesh singh wrote:
>> I had got this message while running vacuum full from backend . Now My
>> database is not starting , Help pls.
>>
>> backend> vacuum full debug;
>> WARNING: database "debug" must be vacuumed within 99 transactions
>> HINT
Dear all,
First of all i wish to share actual error meassge,
Below are the queries i had executed on the terminal on my server
-bash-3.2$ touch fix.sql
-bash-3.2$ echo "VACUUM FULL;" > fix.sql
-bash-3.2$ postgres -D /var/lib/pgsql/data patnadbold < fix.sql
WARNING: database "patnadbold" must be
On 10/08/2013 08:03 AM, shailesh singh wrote:
Dear all,
First of all i wish to share actual error meassge,
Below are the queries i had executed on the terminal on my server
-bash-3.2$ touch fix.sql
-bash-3.2$ echo "VACUUM FULL;" > fix.sql
-bash-3.2$ postgres -D /var/lib/pgsql/data patnadbold
> postgres -D /var/lib/pgsql/data patnadbold < fix.sql
What the heck is the point of feeding "VACUUM FULL;" into the standard input
of the postgres command? "postgres" simply starts the server, it does not
execute arbitrary SQL. Once the database is started you want to use "psql"
- either inter
On 10/08/2013 09:03 AM, David Johnston wrote:
postgres -D /var/lib/pgsql/data patnadbold < fix.sql
What the heck is the point of feeding "VACUUM FULL;" into the standard input
of the postgres command? "postgres" simply starts the server, it does not
execute arbitrary SQL. Once the database
On Fri, Oct 16, 2009 at 11:26 AM, Neha Patel wrote:
> Hi,
>
>
>
> We are running with postgres sql 7.3.2. We were trying to create an index
> on a big table. The create index command ran for nearly 5 hours at which
> point we decided to interrupt it. Since this was interrupted, any
> operations
On Fri, Oct 16, 2009 at 11:26:40AM +0100, Neha Patel wrote:
> Hi,
>
> We are running with postgres sql 7.3.2.
Whatever you thought your most urgent priority was, it's actually
getting your database off of a major version of PostgreSQL, 7.3, whose
end-of-life was well over a year ago.
Your secon
RAL] Urgent Help required
On Fri, Oct 16, 2009 at 11:26:40AM +0100, Neha Patel wrote:
> Hi,
>
> We are running with postgres sql 7.3.2.
Whatever you thought your most urgent priority was, it's actually
getting your database off of a major version of PostgreSQL, 7.3, whose
end-of-life was
Neha Patel wrote:
Hi,
We are running with postgres sql 7.3.2. We were trying to...
well, right off the bat, thats a -really- old version. Release notes
say February 2003. 7.3 was updated to 7.3.21, and we're currently on
8.4 (while still supporting 8.3, 8.2, 8.1, and 7.4).There
On Fri, 2009-10-16 at 11:26 +0100, Neha Patel wrote:
> We are running with postgres sql 7.3.2. We were trying to create an
> index on a big table. The create index command ran for nearly 5 hours
> at which point we decided to interrupt it. Since this was interrupted,
> any operations attempted on t
Hmm would this be a bad time to ask for PostGres 1.0 support?
On Fri, Oct 16, 2009 at 1:55 PM, Jeff Davis wrote:
> On Fri, 2009-10-16 at 11:26 +0100, Neha Patel wrote:
>> We are running with postgres sql 7.3.2. We were trying to create an
>> index on a big table. The create index command ran for
12 matches
Mail list logo
