stellar / go

Stellar's public monorepo of go code
https://stellar.org/developers
Apache License 2.0
1.3k stars 502 forks source link

Switch back to postgres 9.4 (?) in Travis #823

Closed bartekn closed 1 year ago

bartekn commented 5 years ago
howardtw commented 5 years ago

Do you plan on modifying both https://github.com/stellar/go/blob/master/services/horizon/internal/scripts/rebuild_schema.bash and /scripts/build_test_scenarios.bash to have them run with docker container of Postgres 9.6? I think we should at least bump the Travis Postgres to 9.6 as suggested here https://github.com/stellar/docker-stellar-core-horizon#stellar-quickstart-docker-image

tomerweller commented 5 years ago

We should probably not go above 9.5 because that's as far as the official ubuntu packages for 16.04LTS go.

tomerweller commented 5 years ago

we should use Docker to prevent unnecessary DB dumps diffs.

@bartekn we can probably achieve a stable dump for the empty db but not for the populated ones, as the dumps contain timestamps (in their current form).

howardtw commented 5 years ago

We should probably not go above 9.5 because that's as far as the official ubuntu packages for 16.04LTS go.

You're right. 9.5 it is. UPSERT is very useful feature for optimization though I haven't come across the places where we can adapt it.

@bartekn we can probably achieve a stable dump for the empty db but not for the populated ones, as the dumps contain timestamps (in their current form).

On that note, we probably don't have to maintain the latest.sql as we can just run the migrations as part of horizon db init. What do you think? @tomerweller @bartekn https://github.com/stellar/go/issues/827

bartekn commented 5 years ago

@bartekn we can probably achieve a stable dump for the empty db but not for the populated ones, as the dumps contain timestamps (in their current form).

Good point.

You're right. 9.5 it is. UPSERT is very useful feature for optimization though I haven't come across the places where we can adapt it.

UPSERT can be useful in asset stats.

On that note, we probably don't have to maintain the latest.sql as we can just run the migrations as part of horizon db init. What do you think?

I once proposed that and we probably shouldn't do it.

@brahman81 you should join this discussion.

brahman81 commented 5 years ago

@bartekn I think that from the packages perspective it would be better to stick to stock 16.04 (postgresql 9.5) at the minimum.