Hi Dave,
As far as I understood the logical Replication thing, you can control when you like to receive changed data since your last consumption – so you
have to pull actively the changesets out the replication slot. PostgreSQL keeps track of which commits you have already consumed and which not. So perhaps you’ll loose one or to commits that are some milliseconds old, but you’ll get them the next time. I think
this behavior would be feasible and would occur on secondary PostgreSQL nodes as well.
This pull mechanism to fetch all changes since your last pull could be done by hand manually from the geogig cli in order to incorporate all changes
in a PostGIS DB into a specific geogig branch. As long as no one else writes into that PostGIS “integration branch”, all would be fine.
If that is working well, the step of setting up a batch job which does this “delta import step” every hour or as a nightly “snapshot” of the PostGIS
data is not so far anymore.
Kind regards,
Von: geogig-dev-bounces@xxxxxxxxxxxxxxxx [mailto:geogig-dev-bounces@xxxxxxxxxxxxxxxx]
Im Auftrag von Dave Blasby
Gesendet: Mittwoch, 18. Oktober 2017 18:49
An: GeoGig project
Betreff: Re: [geogig-dev] Antwort: Re: Sync changes from GeoGig repository back to Postgis
Hi, Sebastian,
Thats a good point (replication). However, I'd expect that it would be more difficult than one might expect - there's always a delay between transaction end and when the actual physical
log replication occurs (although pg10 might be better at that). However, is definitely an interesting idea - I've only thought about replication for scaling the postgresql database.
I will think about it a bit more...
On Wed, Oct 18, 2017 at 4:28 AM, <Markus.Hesse@xxxxxxxxxxxxxx> wrote:
Sounds very interesting. But one draw back is, that logical replication is only available with progres version 10. I assume most progress installation are on postgres 9 and
below.
Von: <Schmidt.Sebastian2@xxxxxx>
An: <geogig-dev@xxxxxxxxxxxxxxxx>,
Datum: 18.10.2017 10:37
Betreff: Re: [geogig-dev] Sync changes from GeoGig repository
back to Postgis
Gesendet von: geogig-dev-bounces@xxxxxxxxxxxxxxxx
Hi everyone,
"The main issue with allowing people to update the PostGIS table is that you need to be able to track what change's they've made. You can do this with audit triggers on the database, or you can can do a brute-force diff using GeoGig to do a feature-by-feature
compare to see what's changed. "
What about using Logical Decoding or logical Replication on PostGIS-Databases in order to mitigate the "brute-force approach" looking through all features?
Using logical decoding/replication you're able to track change sets inside the PostGIS DB without the need to create triggers.
You can configure and accesss these change sets with pure (postgresql-specific) SQL code. So what about writing a geogig import step that
a) Initially sets up such replication slots and
b) consumes the changes when triggered?
This would make integration of larger databases faster in order of magnitudes as only the inserted/updated/deleted rows are processed.
https://www.postgresql.org/docs/10/static/logical-replication.html
Kind regards,
Sebastian
_______________________________________________
geogig-dev mailing list
geogig-dev@xxxxxxxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.locationtech.org/mailman/listinfo/geogig-dev
_______________________________________________________
Mettenmeier GmbH
Sitz der Gesellschaft: 33100 Paderborn
Geschaeftsfuehrung: Ulrich Mettenmeier
Handelsregister: Amtsgericht Paderborn B 1114
USt.-ID: DE 811 324 124
Steuer-Nr.: 339/5873/3133
_______________________________________________________
_______________________________________________
geogig-dev mailing list
geogig-dev@xxxxxxxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.locationtech.org/mailman/listinfo/geogig-dev
|
