On 10/22/21 19:58, Дмитрий Иванов wrote:
Good afternoon. Tell me what version of Python3 PostgreSQL 14 is
targeting. I had problems with pairing version 12, working on 3.7.4
1) Where did you install Postgres from?
2) Define problems.
3) To be clear you are trying to use plpython3u, correct?
Hey Tom,
Thank you for your response. Actually, when we copy data using scp/rsync,
it works without any issue. But, it fails while attempting to transfer
using pg_basebackup.
Would keepalive setting address and mitigate the issue?
Regards,
Ninad Shah
On Fri, 22 Oct 2021 at 21:39, Tom Lane wro
Good afternoon. Tell me what version of Python3 PostgreSQL 14 is targeting.
I had problems with pairing version 12, working on 3.7.4
On 2021-10-22 10:26:38 -0700, Bryn Llewellyn wrote:
> There could, so easily, have been three “to_char()” overloads for these three
> data types that honored the spirit of the “::text” typecast by rendering only
> what’s meaningful, despite what the template asks for.
I think to_date() is very muc
> t...@sss.pgh.pa.us wrote:
>
> Bryn Llewellyn writes:
>> There could, so easily, have been three “to_char()” overloads for these
>> three data types that honored the spirit of the “::text” typecast by
>> rendering only what’s meaningful, despite what the template asks for.
>
> You can, of cours
> david.g.johns...@gmail.com wrote:
>
>> Bryn wrote:
>>
>> There could, so easily, have been three “to_char()” overloads for these
>> three data types…
>
> The argument about avoiding the implicit cast, and thus being easier for
> newcomers to figure out, is the compelling one for me. But, fra
On Friday, October 22, 2021, Bryn Llewellyn wrote:
>
> There could, so easily, have been three “to_char()” overloads for these
> three data types that honored the spirit of the “::text” typecast by
> rendering only what’s meaningful, despite what the template asks for.
>
Even if we added to_char(
You can, of course, trivially make that so in your own database.
=# create function to_char(date, text) returns text
language sql stable strict parallel safe
as 'select pg_catalog.to_char($1::timestamp without time zone, $2)';
=# select to_char(current_date, 'dd-Mon- TZH:TZM');
to_c
On 10/22/21 10:26 AM, Bryn Llewellyn wrote:
//
I’ll make this my final turn on this thread. Yes, I accept that
everything to do with the date-time story is tough stuff. And I do
understand that this is, to a large extent, just a reflection of the
fact that the terrain is inevitably affected
Bryn Llewellyn writes:
> There could, so easily, have been three “to_char()” overloads for these
> three data types that honored the spirit of the “::text” typecast by
> rendering only what’s meaningful, despite what the template asks for.
You can, of course, trivially make that so in your own da
> adrian.kla...@aklaver.com wrote:
>
> Bryn wrote:
>
>>> adrian.kla...@aklaver.com wrote:
>>>
>>> Bryn wrote:
> Adrian Klaver wrote:
> ...
>> You've lost me entirely here, I'm afraid.
>> My question was simple: why is there no "to_char ( date, text ) → text"
>> overload?
>
> Because th
Ninad Shah writes:
> What I observed is that it takes a couple of hours between below 2 lines.
> 115454656/1304172127 kB (8%), 0/1 tablespace
> (...atastaging/base/115868/154220.2)
> pgbasebackup: could not read COPY data: could not receive data from server:
> Connection timed out
We have heard
On 10/21/21 17:42, Bryn Llewellyn wrote:
On 21-Oct-2021, at 17:15, Adrian Klaver wrote:
On 10/21/21 15:45, Bryn Llewellyn wrote:
/Adrian Klaver wrote:/
*Why is there no "date" overload of "to_char()"?*
You've lost me entirely here, I'm afraid.
My question was simple: why is there no "to
Hello experts,
I am facing an issue with a customer's production server while trying to
take backup using pg_basebackup.
Below is the log from pg_basebackup execution.
* 115338208/1304172127 kB (8%), 0/1 tablespace
(...atastaging/base/115868/154220.1)
115355616/1304172127 kB (8%), 0/1 tablespac
On Fri, 2021-10-22 at 17:11 +0900, Abhishek Bhola wrote:
> postgres@dxxxpgs03:/D1/datadg/data13$ /usr/pgsql-13/bin/pg_upgrade -k
> --check
> --new-datadir='/D1/datadg/data13' --old-datadir='/D1/datadg/data'
> --new-bindir='/usr/pgsql-13/bin' --old-bindir='/usr/pgsql-11/bin'
>
> *C
Frankly speaking, nothing is impossible. But, I don't see any tools
available for the same.
I found the below link, which has migrated using code only.
https://niravshah2705.medium.com/spanner-database-to-postgres-90740424f744
Regards,
Ninad Shah
On Tue, 19 Oct 2021 at 14:58, Pawan Sharma wro
Hi All,
I am also facing a similar issue. In my case I am connecting to AWS Aurora
PostgreSQL.
When my psql session is idle for a while ( for 5 - 10 minutes ) , It gets
terminated and reconnect but query/transaction started by earlier session
remain in `idle in transaction` state and the only opt
While upgrading from Postgres 11 to 13, the pg_upgrade passed the check mode
postgres@dxxxpgs03:/D1/datadg/data13$ /usr/pgsql-13/bin/pg_upgrade -k
--check --new-datadir='/D1/datadg/data13'
--old-datadir='/D1/datadg/data' --new-bind$
r='/usr/pgsql-13/bin' --old-bindir='/usr/pgsql-11/bin
18 matches
Mail list logo
