[GENERAL] WAL log level compatibility

Hi everyone, Are 'wal_level = archive' vs 'wal_level = hot_standby' ok to mix? For example, let's say I had a PostgreSQL database running and creating WAL logs in the archive level. Then we switch to the hot standby level to support a hot standby, then go back to the archive level, all while

Re: [GENERAL] Best practices for cloning DB servers

set in QA I would have thought that shipping WAL file into S3 would have been problematic - I'd be interested in the size of the data set and the experiences you've had with that Regards Bill Sent from my iPhone On Aug 14, 2014, at 12:17, Andy Lau a...@infer.com wrote: Hi everyone

[GENERAL] Best practices for cloning DB servers

Hi everyone, I had a question about some best practices. Our situation is that we want to be able to clone a database server. Our single database server is hosted in AWS, we take EBS snapshots every so often, and upload our WAL logs to S3. We want to be able to start a new server from a snapshot,

Re: [GENERAL] Missing uuid_generate_v1()

Does anyone know where I can see what's already fixed at 9.0.2? Thanks, Alexia On 2010-10-07 09:54, Dave Page wrote: On Thu, Oct 7, 2010 at 3:56 AM, Tom Lane t...@??? wrote: Mike Christensen m...@??? writes: On Wed, Oct 6, 2010 at 7:38 PM, Tom Lane t...@??? wrote: If you have a

[GENERAL] GRANT ALL ON recursive for all tables in my scheme?

I recently searched for a way to grant permissions to a new created user for all tables in a scheme or database. I just found ways who uses psql and scripts. But I'm astonished that there is no way to do it with the grant all on database [schema]...-option. Actually i thought that a grant on a

[GENERAL] syntax error at or near PROCEDURAL

Hello, I try to restore a dump file on a new Database. But unfortunatly i get this error: pg_restore: [archiver (db)] Error while PROCESSING TOC: pg_restore: [archiver (db)] Error from TOC entry 532; 2612 16386 PROCEDURAL LANGUAGE plpgsql postgres pg_restore: [archiver (db)] could not

Re: [GENERAL] syntax error at or near PROCEDURAL

[mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 26. Februar 2008 10:30 An: Andreas Lau; pgsql-general@postgresql.org Betreff: Re: [GENERAL] syntax error at or near PROCEDURAL On Tue, Feb 26, 2008 at 10:26:25AM +0100, Martijn van Oosterhout wrote: On Tue, Feb 26, 2008 at 10:23:05AM +0100, Magnus

Re: [GENERAL] syntax error at or near PROCEDURAL

i used version 8.2.6 both for pg_restore and pg_dump. On Tue, Feb 26, 2008 at 10:48:06AM +0100, Andreas Lau wrote: Thanks for your hinds. It's true i used pg_dump and pg_restore version 8.3 to dump and restore 8.2 databases. I wouldn't have thought that there could be problems. But it seems

Re: [GENERAL] SELECT DISTINCT performance issue

At 13:06 05/06/05, Tom Lane wrote: K C Lau [EMAIL PROTECTED] writes: esdt= explain analyze select DISTINCT ON (PlayerID) PlayerID,AtDate from Player where PlayerID='0' order by PlayerID desc, AtDate desc; Unique (cost=0.00..2507.66 rows=1 width=23) (actual time=0.000..187.000 rows

[GENERAL] SELECT DISTINCT performance issue

desc, AtDate desc LIMIT 1 Any clue or suggestions would be most appreciated. If you need further info or the full explain logs, please let me know. Regards, KC Lau. ps. This problem probably should go to pgsql-performance mailing list, but I have sent this email to pgsql-performance