On Sun, Oct 4, 2015 at 6:38 AM, Madovsky wrote: > On 10/3/2015 6:55 AM, Michael Paquier wrote: >> On Sat, Oct 3, 2015 at 10:20 PM, Madovsky wrote: >> Requesting the master would be necessary, still I don't really get why >> you don't want to query the master for read queries... You could for >> example plug on top of the master pgbouncer if you have many >> connections, but well at this stage I have no idea of what is your use >> case. > > > Your idea is interesting, but unfortunately not dynamic and not for a per > user basis. > like we can change synchronous_commit on the fly and per block transactions > so > why not the same for standby priority? > I'm trying to use the master for write only. There can be only one sync standby at a time, and please note again the difference between WAL flush and WAL replay. Synchonous replication ensures that the former has been done, not the latter. As far as this thread goes, it seems to me that you are taking a more bug-prone approach on your application-side which could be solved by just querying the master... Another idea would be to add some meta-data in the schema to check the validity of the things replayed, like a state-of-data-per-user or a data-version-number-per-user in a dedicated table, this would avoid having to make the application WAL-aware, still you would need to make the application aware of this meta-data in some way, which would surely require to query the master or update some cache or a file on client side. Still I don't see why you would need to use this approach, and no reason is given to justify *why* this would be needed in your case. But well I guess I cannot stop you to do so if you wish to do it :) -- Michael -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
