On Thu, Jan 21, 2021 at 10:25:39AM +0900, Ian Lawrence Barwick wrote:
> 2021年1月21日(木) 9:19 Mohamed Wael Khobalatte :
>
>
>
> On Wed, Jan 20, 2021 at 2:37 PM Michael Lewis wrote:
>
> Using pg_upgrade takes minutes for an in place upgrade. If you can
> allow 1+ hour of downti
2021年1月21日(木) 9:19 Mohamed Wael Khobalatte :
>
>
> On Wed, Jan 20, 2021 at 2:37 PM Michael Lewis wrote:
>
>> Using pg_upgrade takes minutes for an in place upgrade. If you can allow
>> 1+ hour of downtime, it seems overly complicated to use logical replication.
>>
>
> I suppose the Atul's issue i
Keith Christian writes:
> Planning to convert a Postgres 10 instance to systemd init. I understand it
> had to be compiled with systemd support to work that way.
Try "pg_config --configure" and see if --with-systemd is mentioned.
regards, tom lane
Planning to convert a Postgres 10 instance to systemd init. I understand it
had to be compiled with systemd support to work that way.
Thanks!
On Wed, Jan 20, 2021 at 2:37 PM Michael Lewis wrote:
> Using pg_upgrade takes minutes for an in place upgrade. If you can allow
> 1+ hour of downtime, it seems overly complicated to use logical replication.
>
I suppose the Atul's issue is what to do with the replicas. Once he does
pg_upgrade, th
Michael Lewis writes:
> I've read the documentation but am unclear on what memory is used when
> temp_buffers are exceeded by temp tables that are created.
The data gets flushed out to disk storage, or at least kernel disk buffers
(I don't think we'll try to fsync it).
> Does that also go toward
I've read the documentation but am unclear on what memory is used when
temp_buffers are exceeded by temp tables that are created. Does that also
go towards temp_file_limit?
When are temp files (temp_file_limit) cleared out? If there is a big ugly
query that uses 8GB of a 10GB limit, and then anoth
Hi Michael,
> On 20. Jan, 2021, at 20:37, Michael Lewis wrote:
>
> Using pg_upgrade takes minutes for an in place upgrade. If you can allow 1+
> hour of downtime, it seems overly complicated to use logical replication.
my all time best score was 18 seconds for migrating from 11 to 12. :-)
Che
Using pg_upgrade takes minutes for an in place upgrade. If you can allow 1+
hour of downtime, it seems overly complicated to use logical replication.
"David G. Johnston" writes:
> On Wed, Jan 20, 2021 at 5:00 AM Avery Fischer wrote:
>> ERROR: PL/pgSQL functions cannot return type myrange
>> Am I misunderstanding the docs, or are they out-of-date, or is something
>> else going on? How can I create a canonicalization function for my range
>> ty
On Wed, Jan 20, 2021 at 5:00 AM Avery Fischer wrote:
> ERROR: PL/pgSQL functions cannot return type myrange
>
> Am I misunderstanding the docs, or are they out-of-date, or is something
> else going on? How can I create a canonicalization function for my range
> type?
>
In short, I'm pretty sur
Hi, I'm trying to create a canonicalization function for a user-defined
range type and running into some issues. I've filled out the template
below, and I'm super grateful for your help!
A description of what you are trying to achieve and what results you
expect.:
I'm trying to create a user-defi
Hi,
We are planning to upgrade from postgres 9.5 to postgres 10, on
centos version 6.8, We have a database of around 400GBs.
We need to perform the upgrade activity with minimum downtime (around
1-2 hours). We are thinking of logical replication for the same.
but The issue is we already have co
13 matches
Mail list logo