Re: approach to logging complete statements - Mailing list pgsql-novice

From Sergey Konoplev
Subject Re: approach to logging complete statements
Date
Msg-id CAL_0b1tGgK1WTUmMnzEBgQ0QKfVq59PxZcX8Th_wQUEWbr8iNA@mail.gmail.com
Whole thread Raw
In response to approach to logging complete statements  (Michael Swierczek <mike.swierczek@gmail.com>)
Responses Re: approach to logging complete statements  (Michael Swierczek <mike.swierczek@gmail.com>)
List pgsql-novice
Hi,

On Mon, May 20, 2013 at 11:18 AM, Michael Swierczek
<mike.swierczek@gmail.com> wrote:
> Hello.  I have a web surveying system backed by PostgreSQL.  A common
> use case is for internal staff to make a series of changes to some
> survey templates (questions, question order, calculations based on
> answers, translations, etc...)  through the web interface.  Then those
> changes are tested, and then manually reproduced through the web
> interface on production servers.  The manual reproduction wastes time
> and causes errors, so instead I would like to capture all of the SQL
> that affects the modified tables on development machines so we can run
> it on the production servers.

You can use a replication tool, eg. londiste, to replicate changes of
particular tables to the production database. Keep the replication
service stopped all the time when you do not need to mirror your
changes, it will still collect the changes in the internal tables on
the testing server side. When you are ready to apply the changes to
the production start the replication, wait until all the data is
replicated and stop it again.

Note, that this approach requires you to have separate tables for
metadata (ones that only internal stuff will change) and user tables,
so you are assumed to replicate metadata tables from testing to
production.

--
Kind regards,
Sergey Konoplev
PostgreSQL Consultant and DBA

Profile: http://www.linkedin.com/in/grayhemp
Phone: USA +1 (415) 867-9984, Russia +7 (901) 903-0499, +7 (988) 888-1979
Skype: gray-hemp
Jabber: gray.ru@gmail.com


pgsql-novice by date:

Previous
From: Michael Swierczek
Date:
Subject: approach to logging complete statements
Next
From: Michael Swierczek
Date:
Subject: Re: approach to logging complete statements