Re: [GENERAL] Broken primary key after backup restore.

On 9/18/15 3:44 PM, Michael Chau wrote: Hi Jeff, Only if you are very lucky. If your tar command tars up the pg_xlog directory as the last thing it does, then you are probably going to be OK. Otherwise, it is a crap shoot. May be that's it. I have another similar set up, but the pg_xlog i

Re: [GENERAL] Broken primary key after backup restore.

Hi Jeff, >Only if you are very lucky. If your tar command tars up the pg_xlog directory as the last thing it does, then you are probably going to be OK. Otherwise, it is a crap shoot. May be that's it. I have another similar set up, but the pg_xlog is a soft link to another directory, and I use

Re: [GENERAL] clone_schema function

Revised to add rules after all tables are create to avoid error where table referenced in rule was not created yet. Added copying of column statistics with thanks to Marc Mamin for pointing that out. On Thu, Sep 17, 2015 at 12:06 PM, Marc Mamin wrote: > > -- > *Von

Re: [GENERAL] Broken primary key after backup restore.

On Fri, Sep 18, 2015 at 6:16 AM, Adrian Klaver wrote: > On 09/17/2015 11:15 PM, Guillaume Lelarge wrote: > >> Le 18 sept. 2015 5:23 AM, "Adrian Klaver" > > a écrit : >> > >> > On 09/17/2015 05:37 PM, Michael Chau wrote: >> >> >> >> To restore on test server:

Re: [GENERAL] search_path not reloaded via unix socket connections

We just found out that the problem was that our own ~/.psqlrc contained the SET statement, overriding the global setting. From: kong_mansatian...@hotmail.com To: t...@sss.pgh.pa.us CC: pgsql-general@postgresql.org Subject: RE: [GENERAL] search_path not reloaded via unix socket connections Date:

Re: [GENERAL] search_path not reloaded via unix socket connections

On 09/18/2015 08:19 AM, Kong Man wrote: Tom, I have made sure that the per-user and per-database settings are reset. The old search_path setting still persists whenever I reconnect via local connections no matter what user I log in as. So exactly how are you connecting and from what? In othe

Re: [GENERAL] search_path not reloaded via unix socket connections

Tom,I have made sure that the per-user and per-database settings are reset. The old search_path setting still persists whenever I reconnect via local connections no matter what user I log in as. > From: t...@sss.pgh.pa.us > To: kong_mansatian...@hotmail.com > CC: pgsql-general@postgresql.org >

Re: [GENERAL] Broken primary key after backup restore.

On 09/17/2015 11:15 PM, Guillaume Lelarge wrote: Le 18 sept. 2015 5:23 AM, "Adrian Klaver" mailto:adrian.kla...@aklaver.com>> a écrit : > > On 09/17/2015 05:37 PM, Michael Chau wrote: >> >> 1) >> >> In Production, I have a DB2 which is replicated partially using Londiste >> from DB

Re: [GENERAL] Delete trigger

Hi Ioana and David. Thank you. Yes, I can see the problem. I will look into your suggestions. Leif - Original Message - > On Friday, September 18, 2015, Leif Jensen wrote: > > >Hello Laurenz, > > > >Thank you for you suggestion. I really want to aviod that someone > > '

Re: [GENERAL] Delete trigger

On Friday, September 18, 2015, Leif Jensen wrote: >Hello Laurenz, > >Thank you for you suggestion. I really want to aviod that someone > 'accidentally' deletes too much by typing (programming) a not full > qualified DELETE ... statement. In your case one would have to always use > the del

Re: [GENERAL] Delete trigger

It depends on the size of the table and the frequency of updates, deletes but cold consider an audit table with triggers for update, delete and truncate. At least you have a way to recover deleted records. Ioana On Fri, Sep 18, 2015 at 5:52 AM, Leif Jensen wrote: >Hello Laurenz, > >Tha

Re: [GENERAL] Online backup of PostgreSQL data.

You can use pg_dump to creating a backup. pg_dump -U db_username db_name -f file_name.dump On Thu, Sep 17, 2015 at 1:45 PM, Albe Laurenz wrote: > John R Pierce wrote: > > to copy the data directory and have it be useful you need to bracket the > copy with calls to > > pg_start_backup() and pg_s

Re: [GENERAL] Delete trigger

Hello Laurenz, Thank you for you suggestion. I really want to aviod that someone 'accidentally' deletes too much by typing (programming) a not full qualified DELETE ... statement. In your case one would have to always use the delete function, but no restrictions on using the DELETE statem

Re: [GENERAL] Delete trigger

Leif Jensen wrote: >If I do "DELETE FROM devicegroup WHERE group=1" I do not want to delete > anything. I only want to > delete if I do "DELETE FROM devicegroup WHERE groupid=x AND ctrlid=y AND > userid=z". I don't wanna let > anyone delete more than 1 row at a time. I can't think of a way t

Re: [GENERAL] Delete trigger

Hi Charles, If I do "DELETE FROM devicegroup WHERE group=1" I do not want to delete anything. I only want to delete if I do "DELETE FROM devicegroup WHERE groupid=x AND ctrlid=y AND userid=z". I don't wanna let anyone delete more than 1 row at a time. Leif - Original Message -

Re: [GENERAL] Delete trigger

Hello Not sure I get it right, but all three fields are not nullable. So they will always have a value, which is what I understand of "are specified". What do you need the trigger for in that case? Bye Charles > -Original Message- > From: pgsql-general-ow...@postgresql.org > [mailto:pg

[GENERAL] Delete trigger

Hi, I am running PostgreSQL 9.3.4. I have a simple table with 3 fields: CREATE TABLE devicegroup ( groupid integer NOT NULL, ctrlid integer NOT NULL, userid integer NOT NULL ); ALTER TABLE ONLY devicegroup ADD CONSTRAINT pk_devicegroup PRIMARY KEY (groupid, ctrlid, userid);