On Mittwoch, 1. Dezember 2010, Greg Swisher wrote:
> FATAL: the database system is starting up
This is what you get on 8.4, when you try to connect to a standby.
Rgds, Jens
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.p
Am Montag 13 Dezember 2010, um 14:47:03 schrieb Adarsh Sharma:
> > mv pg_xlog pg_xlog_old
> But me server fail to start and there is empty log in startup.log. I also
Hi,,
you have to move the contents from the old to the new pg_xlog directory as
well.
HTH, Jens
--
Sent via pgsql-general mail
On Dienstag, 8. Februar 2011, Carlos Mennens wrote:
> Why am I not prompted for a password when I connect from my laptop
> to the server?
check your pg_hba.conf
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/m
On Tuesday 22 February 2011 10:21:01 Adarsh Sharma wrote:
Hi,
> Today I need to back up a mysql database and restore in Postgresql
> database but I don't know how to achieve this accurately.
>
> Can anyone kindly describe me the way to do this.
Have a look here:
http://wiki.postgresql.org/wik
On Sonntag, 27. Februar 2011, Sean Laurent wrote:
> Unfortunately, most queries against the hot standby fail. Worse
> yet, pg_dump fails:
...
> I'm not entirely certain I understand why I'm seeing this. Nor do
> I understand how to fix or work around this. Any advice or
> suggestions would be grea
On Sonntag, 27. Februar 2011, Sean Laurent wrote:
> In particular, I was really hoping to
> run database dumps against the standby, not the master.
One solution is to begin idle transactions on the master by using
e.g. dblink from the standby to the master before you start pg_dump
on the standb
On Samstag, 2. April 2011, Henry C. wrote:
> I just noticed something odd: I'm busy with a manual vacuum on a
> table and an autovacuum keeps firing up as well.
Usually a manual vacuum cancels a running autovacuum task.
You should find a notice about the cancelation in th logfile.
> current_qu
On Samstag, 2. April 2011, Henry C. wrote:
> Sadly, in my case, the db is so busy that autovac processes run
> for weeks and never catch up
Increase the cost_limit and the HW and/or check your application, if
it's possible to reduce the amount of deletes and/or updates.
Regards, Jens
--
Sent
On 3. April 2011, Joshua D. Drake wrote:
> On Sat, 2 Apr 2011 19:26:56 +0200, "Henry C."
wrote:
> > On Sat, April 2, 2011 14:17, Jens Wilke wrote:
> >> Nevertheless since at least 8.4 IMO there's no need to bother
> >> with manual vacuum any more.
&
ted new timeline ID: 2
2008-05-13 15:59:22 CEST LOG: archive recovery complete
2008-05-13 15:59:22 CEST LOG: database system is ready
--snipp--
As we can see logfile ..48 is requested again.
So the question is: Which log files can I safely delete from my archive?
OTOH, is this a bug? I think
On Montag, 18. April 2011, Scott Mead wrote:
> I've seen it, but catalog hacks always make me nervous. Anybody
> else have good / bad experience to share?
Hi,
yes, we used it to reduce massive bloat after a database split and
were very satisfied.
IIRC "vacuum full" mode rewrites the indexes as
On Tue, Apr 19, 2011 at 04:02:01AM +0530, Vibhor Kumar wrote:
> > IIRC "vacuum full" mode rewrites the indexes as well.
>
> Till 8.4 no. From 9.0 onwards yes. However VACUUM FULL still locks the table.
Don't be confused with the "vacuum full" term.
This has nothing to do with the postgresql "vac
Hi,
pg_upgrade brakes with the following error:
pg_upgrade 8.4.5 to 9.0.4:
Restoring user relation files
/data1/postgres/pgsql/foo/data_8.4/base/11564/2613 ^M
/data1/postgres/pgsql/foo/data_8.4/base/11564/2683
Could not find foo.bar_idx in old cluster
This index was dele
On Thursday 05 May 2011 16:46:05 Cédric Villemain wrote:
> I understood that you droped an index and when you dump/restore you
> get your index again.
Yes, that's it, after the pg_upgrade error, i removed the target data
directory, and initialzed a new target DB.
After pg_dumpall|pg_dump i got a
On Wednesday 04 May 2011 17:32:50 Tom Lane wrote:
> Hmm, is this an autogenerated index?
I don't think so.
And to confirm, that i really deleted the new cluster between the pg_upgrade
run and the dump|restore i did it again and was able to revive this index
again:
foo=# \d+ foo.bar_idx
On Friday 06 May 2011 17:18:29 Tom Lane wrote:
Hi Tom,
> Possibly if
> you showed us the actual (not obfuscated) table declaration, associated
> constraint declarations, and resulting index definition, things would be
> clearer.
Thanks Tom, yes, the index is named
Indexes:
"concurrently" btr
On Friday 06 May 2011 18:08:58 Tom Lane wrote:
> There doesn't appear to be any fix for this that doesn't require a time
> machine and/or a lot more effort than it's worth.
Isn't it possible to backport the fix for pg_get_indexdef() to 8.* ?
> Suggest you rename
> the index in the 8.4 database
On Freitag, 29. Juli 2011, woow wrote:
> I have following function expectation is I want to return the
> items in array
> SELECT INTO rolelist role_id FROM roles WHERE role_type =
> $1; RETURN rolelist;
Hi,
you've to use array_agg:
SELECT INTO rolelist array_agg(role_id) FROM roles
On Samstag, 8. Oktober 2011, Raymond O'Donnell wrote:
Hi,
> rod@simecom:~$ psql -U postgres -h localhost
> Can't exec "dpkg-architecture": No such file or directory at
dpkg-architecture is missing.
This file is provided by the package dpkg-dev.
Regards, Jens
--
Sent via pgsql-general mailing
On Montag, 28. Mai 2012, Anthony Bull wrote:
Hi,
>This did not
> work either - postgres still reports 25GB being used by the
> database.
Did you run analyze?
Did the disk usage reported by the OS shrink?
Regards, Jens
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To
Am Mittwoch 11 August 2010 16:20:27 schrieb Bill Christensen:
Hi,
> Export error: Failed to execute pg_dump (given path in your
> conf/config.inc.php :
Is pg_dump executable?
Did you try to do a manual dump w/o phpadmin?
Regards, Jens
--
Sent via pgsql-general mailing list (pgsql-genera
On Dienstag, 21. September 2010, Aleksey Tsalolikhin wrote:
> Yesterday, I had twelve thousand "cache lookup failed for type N"
> messages, like this:
> What does "type 14237017" mean?
pg_type oid
> What cache are we talking about?
Did you alter a type before?
There's a bug in postgres, tha
On Dienstag, 21. September 2010, Aleksey Tsalolikhin wrote:
Hi Aleksey,
> So PostgreSQL was trying to lookup a row in a system table and
> did not find it in a cache.
yes,
select * from pg_type where oid =14237017
>> Did you alter a type before?
> No. I don't even know how to alter a type.
On Thursday 10 November 2011 05:58:01 Dennis Ryan wrote:
> Is there a way to list the installed pl languages for a database and/or
> server cluster?
they are registered in the pg_language system catalog.
Rgds, Jens
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make ch
On Dienstag, 21. Februar 2012, sunpeng wrote:
> 00010009
> obviously there is no 00020007.
The standby is on timeline 2, but the WAL Files are on timeline 1.
I guess, you should make a new base backup.
Regards, Jens
--
Sent via pgsql-general mailing list (pgsql
On Wednesday 07 March 2012 21:13:26 pawel_kukawski wrote:
Hi,
> Do you know any real reason why the autovacuum may fail to clear old XIDs?
If it's unable to keep up.
Or may be, if there're very long running idle in transactions.
> Is this highly probable ?
postmaster will shutdown to prevent w
26 matches
Mail list logo
