Dear Adrian,
We are using binary replication and par day pg_log_archive total size is
increase after upgrade for PG11 to PG13.
Regards,
Ram Pratap.
-Original Message-
From: Adrian Klaver [mailto:adrian.kla...@aklaver.com]
Sent: 19 April 2022 22:51
To: Ram Pratap Maurya ;
pg
"David G. Johnston" writes:
> Might I suggest the following:
> + /*
> + * For each action, modify procForm to type-safely set the new value.
> + * However, because the SET clause is repeatable we handle it
> + * a bit differently, modifying the underlying tuple directly. So
> + * make sure to lea
On Tue, Apr 19, 2022 at 7:47 PM Julien Rouhaud wrote:
>
> On Tue, Apr 19, 2022 at 07:21:19PM -0700, David G. Johnston wrote:
> > On Tue, Apr 19, 2022 at 7:07 PM Bryn Llewellyn
> wrote:
> >
>
> > > *alter function s1.f()security invokerset timezone = 'UTC'stable*
> > > *parallel safe*
> > > *;*
>
On Tue, Apr 19, 2022 at 11:06:30PM -0400, Tom Lane wrote:
> Julien Rouhaud writes:
> > On Wed, Apr 20, 2022 at 10:47:07AM +0800, Julien Rouhaud wrote:
> >>
> >> AFAICT the problem is that SET / RESET part is messing with the
> >> HeapTuple, so you can't use the procForm reference afterwards. Sim
Julien Rouhaud writes:
> On Wed, Apr 20, 2022 at 10:47:07AM +0800, Julien Rouhaud wrote:
>>
>> AFAICT the problem is that SET / RESET part is messing with the
>> HeapTuple, so you can't use the procForm reference afterwards. Simply
>> processing parallel_item before set_items fixes the problem,
On Wed, Apr 20, 2022 at 10:47:07AM +0800, Julien Rouhaud wrote:
>
> AFAICT the problem is that SET / RESET part is messing with the HeapTuple, so
> you can't use the procForm reference afterwards. Simply processing
> parallel_item before set_items fixes the problem, as in the attached.
This time
Hi,
On Tue, Apr 19, 2022 at 07:21:19PM -0700, David G. Johnston wrote:
> On Tue, Apr 19, 2022 at 7:07 PM Bryn Llewellyn wrote:
>
> > *SUMMARY*
> >
> > This part of the syntax diagram for "alter function":
> >
> > *ALTER FUNCTION name [ ( [ [ argmode ] [ argname ] argtype [, ...] ] ) ]
> > action
"David G. Johnston" writes:
> On Tue, Apr 19, 2022 at 7:07 PM Bryn Llewellyn
> wrote:
>> This is the bug.
> While I haven't experimented with this for confirmation, what you are
> proposing here (set + parallel safe) is an impossible runtime
> combination (semantic rule) but perfectly valid to w
On Tue, Apr 19, 2022 at 7:07 PM Bryn Llewellyn wrote:
> *SUMMARY*
>
> This part of the syntax diagram for "alter function":
>
> *ALTER FUNCTION name [ ( [ [ argmode ] [ argname ] argtype [, ...] ] ) ]
> action [ … ]*
>
> says that the first "action" can be followed (without punctuation) by
> zero
SUMMARY
This part of the syntax diagram for "alter function":
ALTER FUNCTION name [ ( [ [ argmode ] [ argname ] argtype [, ...] ] ) ] action
[ … ]
says that the first "action" can be followed (without punctuation) by zero,
one, or many other actions. A semantic rule says that no particular act
Hi All,
OK, apologies in advance, I feel like this is a rather unintelligent
question that I probably know the answer to, but I am banging my head
against a wall trying to understand what is happening.
I have an ETL program, written in Python, that uses mutiple processes
to read and load a bunc
I'll be asking 'those in charge' to reset some timeout/keep-alive
setting /somewhere/. I need help in hopefully naming the correct
setting. The server is running version 14
Am I dealing with a client issue, a server issue or a mis-match in
host/postgres configuration values? If I cannot hav
On 4/19/22 00:34, Pól Ua L. wrote:
Bonjour a tous/Hello all,
Small problem - I hope it not to trivial for here.
We created a table, then someone deleted some records and we want to put
them back, but we not sure how.
CREATE TABLE dat AS
SELECT
GENERATE_SERIES
(
'2022-0
Bonjour a tous/Hello all,
Small problem - I hope it not to trivial for here.
We created a table, then someone deleted some records and we want to put them
back, but we not sure how.
CREATE TABLE dat AS
SELECT
GENERATE_SERIES
(
'2022-03-01'::DATE,
'2022-04-18'::DATE,
'1 DAY' ) AS jour;
So, all
On 4/18/22 21:41, Ram Pratap Maurya wrote:
Dear Adrian,
If we set parameter *"PG-WAL = replica"* in PG13 conf file , there is
any issue in replication through PG_WAL and pg_log_archive log.
In versions of Postgres from 9.6+ your setting of hot_standby is mapped
to the replica setting
On 4/19/22 04:59, Thomas, Richard wrote:
A request for further suggestions for how to fix/diagnose this PG crash (having
just got back from holiday I discover that PG is still crashing even though I
have changed the pgdump target output location to a folder excluded from the
McAfee Antivirus s
On Mon, Apr 18, 2022 at 11:37 PM bhargav kamineni wrote:
> executing the vacuum on the entire cluster is also giving the same HINTS and
> WARNING's
You're using Aurora, not PostgreSQL. Perhaps this is actually a bug,
but there is no way for anybody here to know.
--
Peter Geoghegan
Rob Sargent writes:
> On 4/19/22 00:06, David G. Johnston wrote:
>> On Monday, April 18, 2022, bhargav kamineni wrote:
>> It seems vacuum is behaving somewhat weird on postgres database ,
>> observing below HINTS on the vacuum logs
>> WARNING: oldest xmin is far in the past
> This site has lots
A request for further suggestions for how to fix/diagnose this PG crash (having
just got back from holiday I discover that PG is still crashing even though I
have changed the pgdump target output location to a folder excluded from the
McAfee Antivirus scanning - but thanks for the suggestion Adr
19 matches
Mail list logo
