On 2019-06-02 09:10:25 +1000, Morris de Oryx wrote:
> Peter, thanks a lot for picking up on what I started, improving it, and
> reporting back. I thought I was providing timing estimates from the EXPLAIN
> cost dumps. Seems not. Well, there's another thing that I've learned.
The cost is how long t
Peter,
Thanks a lot for the remedial help on EXPLAIN and timing results.
On 6/1/19 8:07 PM, Tom K wrote:
https://www.postgresql.org/docs/10/app-postgres.html
Single-User Mode
...
and see if that at least gets the server started. This is a highly
restricted so do not expect much usability.
These servers did crash before however didn't' notice a
On Fri, May 24, 2019 at 11:26 AM Jeremy Finzel wrote:
> I have been hoping for clearer direction from the community about
> specifically btree_gin indexes for low cardinality columns (as well as low
> cardinality multi-column indexes). In general there is very little
> discussion about this both
On Sun, Jun 2, 2019 at 11:47 AM Adrian Klaver
wrote:
> On 6/1/19 8:07 PM, Tom K wrote:
>
> >
> > https://www.postgresql.org/docs/10/app-postgres.html
> > Single-User Mode
> > ...
> >
> > and see if that at least gets the server started. This is a highly
> > restricted so do no
On 6/2/19 11:14 AM, Tom K wrote:
Nope. wal_level was set to replica, not logical. Unless you mean
What was the role of this cluster in the original setup?
The cluster was the backend database for a number of applications. The
aim was to point applications to a single large cluster in
Jeff Janes writes:
> On Fri, May 24, 2019 at 11:26 AM Jeremy Finzel wrote:
>> I have been hoping for clearer direction from the community about
>> specifically btree_gin indexes for low cardinality columns (as well as low
>> cardinality multi-column indexes). In general there is very little
>> d
Hello
We have done pg10 upgrades from 9.6 on all our environments successfully. We
have an automation script that does this for us. One environment is a near
replica of our production setup and all works fine.
We have now made 2 attempts at doing this on production - both ending up with
rollba
Zahir Lalani writes:
> We have done pg10 upgrades from 9.6 on all our environments successfully. We
> have an automation script that does this for us. One environment is a near
> replica of our production setup and all works fine.
> We have now made 2 attempts at doing this on production - both
Ah no we did not!
Will give that a go next tim Tom
Thank you
Z
On 3 Jun 2019 00:18, Tom Lane wrote:
Zahir Lalani writes:
> We have done pg10 upgrades from 9.6 on all our environments successfully. We
> have an automation script that does this for us. One environment is a near
> replica of o
Thanks to Tom Lane and Jeff Janes for chiming in with the level of detail
they're able to provide.
As an outsider-who-now-loves-Postgres, I don't know the history or deep
details of all of the various index types. (Obviously.) As a long-time
database programmer, I can say that low-cardinality fiel
Hey Adrian,
Fixed it.
I saw the post from jebriggs but that didn't work for me so posted here.
Anyway, here's how I resolved it:
When I ran an strace on the postgres startup line, I got this:
open("pg_logical/replorigin_checkpoint", O_RDONLY) = 6
write(2, "2019-06-02 14:50:34.777 EDT [283"...,
12 matches
Mail list logo
