Hello,
Last month, I brought up the following issue to the general mailing list about
how running streaming replication between machines running different versions
of glibc can cause corrupt indexes.
http://www.postgresql.org/message-id/ba6132ed-1f6b-4a0b-ac22-81278f5ab...@tripadvisor.com
In th
Here is where I think the timezone and PostGIS cases are fundamentally
different:
I can pretty easily make sure that all my servers run in the same timezone.
That's just good practice. I'm also going to install the same version of
PostGIS everywhere in a cluster. I'll build PostGIS and its de
witched to 'don't trust any change until shown otherwise', so
that may have bled into my last email.
- Matt K.
On Sep 17, 2014, at 8:17 AM, Robert Haas
wrote:
> On Wed, Sep 17, 2014 at 9:07 AM, Matthew Kelly wrote:
>> Here is where I think the timezone and PostGIS cases
> Hmm 2^32 times aprox. 2kB (as per usual heuristics, ~4 rows per heap
> page) is 8796093022208 (~9e13) bytes
> ... which results in 8192 1GB segments :O
8192 1GB segments is just 8TB, its not _that_ large. At TripAdvisor we’ve been
using a NoSQL solution to do session storage. We are look
> That's assuming that toasting is evenly spread between tables. In my
> experience, that's not a great bet...
Time to create a test:
SELECT chunk_id::bigint/10 as id_range, count(*), count(*)/(10::float)
density FROM (SELECT chunk_id FROM pg_toast.pg_toast_39000165 WHERE chunk_id <
100
If you do the following sequence, the server gives the least helpful error
message:
initdb data
pg_ctl -D data -l logfile start
# The following reconfigs are obvious based on error message if you try to take
a base backup
echo 'local replication all trust’ >> data/pg_hba.conf
sed -i 's/
