On 2021/09/13 11:00, Kyotaro Horiguchi wrote:
The point here is "retry this page, not this record", so "we don't need
to retry immediately" looks a bit ambiguous. So how about something
like this?
Note that we don't do this while not in standby mode because we don't
need to avoid retrying
On Thu, Sep 9, 2021 at 9:50 AM Amit Kapila wrote:
>
> On Wed, Sep 8, 2021 at 12:24 PM Peter Smith wrote:
> >
> > v2 --> v3
> >
> > The subscription_parameter names are now split into 2 groups using
> > Amit's suggestion [1] on how to categorise them.
> >
> > I also made some grammar improvements
On Sun, Sep 12, 2021 at 8:54 PM Justin Pryzby wrote:
> Adding -hackers, sorry for the duplicate.
>
> This seems to be deficient, citing
>
> https://www.postgresql.org/message-id/flat/0d1b394b-bec9-8a71-a336-44df7078b295%40gmail.com
>
> I'm proposing something like the attached. Ideally, there
On Mon, Sep 13, 2021 at 8:44 AM Michael Paquier wrote:
>
> On Sun, Sep 12, 2021 at 09:25:32PM -0300, Euler Taveira wrote:
> > On Thu, Sep 9, 2021, at 8:18 AM, Amul Sul wrote:
> >> Also, we don't have a good test for archive_cleanup_command as well, I
> >> am not sure how we could test that which
Adding -hackers, sorry for the duplicate.
This seems to be deficient, citing
https://www.postgresql.org/message-id/flat/0d1b394b-bec9-8a71-a336-44df7078b295%40gmail.com
I'm proposing something like the attached. Ideally, there would be a central
place to put details, and the other places could
On Mon, Sep 13, 2021 at 8:07 AM Michael Paquier wrote:
>
> On Sun, Sep 12, 2021 at 10:14:36PM -0300, Euler Taveira wrote:
> > On Sun, Sep 12, 2021, at 8:02 PM, Bossart, Nathan wrote:
> >> nitpick: It looks like there's an extra set of parentheses around
> >> errmsg().
> >
> > Indeed. Even the
On Mon, Sep 13, 2021 at 6:45 AM Euler Taveira wrote:
>
> On Sun, Sep 12, 2021, at 8:02 PM, Bossart, Nathan wrote:
>
> nitpick: It looks like there's an extra set of parentheses around
> errmsg().
>
> Indeed. Even the requirement for extra parenthesis around auxiliary function
> calls was removed
On Sun, Sep 12, 2021 at 09:25:32PM -0300, Euler Taveira wrote:
> On Thu, Sep 9, 2021, at 8:18 AM, Amul Sul wrote:
>> Also, we don't have a good test for archive_cleanup_command as well, I
>> am not sure how we could test that which executes with every
>> restart-point.
>
> Setup a replica and stop
On Sun, Sep 12, 2021 at 08:23:44PM -0500, Justin Pryzby wrote:
> Could you check what HEAD your server is compiled from ?
That works on HEAD for me.
--
Michael
signature.asc
Description: PGP signature
On Sun, Sep 12, 2021 at 10:14:36PM -0300, Euler Taveira wrote:
> On Sun, Sep 12, 2021, at 8:02 PM, Bossart, Nathan wrote:
>> nitpick: It looks like there's an extra set of parentheses around
>> errmsg().
>
> Indeed. Even the requirement for extra parenthesis around auxiliary function
> calls was
On Fri, Sep 10, 2021 at 03:56:18PM +0900, Michael Paquier wrote:
> And this part leads me to the attached, where the addition of the JSON
> format would result in the addition of a couple of lines.
Okay, I have worked through the first half of the patch set, and
applied the improved versions of
On Sat, Sep 11, 2021 at 11:58 PM Tom Lane wrote:
>
> Amit Kapila writes:
> > On Wed, Sep 8, 2021 at 7:57 AM houzj.f...@fujitsu.com
> > wrote:
> >> I found that the patch cannot be applied to back-branches(v10-v14) cleanly,
> >> so, I generate the patches for back-branches. Attached, all the
At Fri, 10 Sep 2021 10:38:39 +0900, Fujii Masao
wrote in
>
>
> On 2021/09/07 2:02, Fujii Masao wrote:
> > Even if we do this while NOT in standby mode, ISTM that this function
> > doesn't
> > return with a valid errmsg_buf because it's reset. So probably the
> > comment
> > should be updated
Hello.
As reported in [1] it seems that walsender can suffer timeout in
certain cases. It is not clearly confirmed, but I suspect that
there's the case where LogicalRepApplyLoop keeps running the innermost
loop without receiving keepalive packet for longer than
wal_sender_timeout (not
I'm +1 for the $SUBJECT concept, mostly because I take longer to read code
where immaterial zero-initialization lines are diluting the code. A quick
scan of the patch content is promising. If there's a decision to move
forward, I'm happy to review it more closely.
On Wed, Jun 30, 2021 at
On Sun, Sep 12, 2021 at 07:44:47PM -0500, Jaime Casanova wrote:
> Hi Tomas,
>
> Just noted that this query crash the server. Execute it in the
> regression database:
If I'm not wrong, this is the crash fixed by e1fbe1181 in April.
Could you check what HEAD your server is compiled from ?
--
On Sun, Sep 12, 2021, at 8:02 PM, Bossart, Nathan wrote:
> nitpick: It looks like there's an extra set of parentheses around
> errmsg().
Indeed. Even the requirement for extra parenthesis around auxiliary function
calls was removed in v12 (e3a87b4991cc2d00b7a3082abb54c5f12baedfd1).
--
Euler
Hi Tomas,
Just noted that this query crash the server. Execute it in the
regression database:
"""
update brintest_multi set inetcol = '192.168.204.50/0'::inet;
"""
Attached is the backtrace. Let me know if you need something else to
track it.
--
Jaime Casanova
Director de Servicios
On Thu, Sep 9, 2021, at 8:18 AM, Amul Sul wrote:
> The attached patch adds a small test for recovery_end_command execution.
Additional coverage is always a good thing.
> Currently, patch tests execution of recovery_end_command by creating
> dummy file, I am not wedded only to this approach, other
On 9/11/21, 1:31 AM, "Bharath Rupireddy"
wrote:
> We have two static check_permissions functions (one in slotfuncs.c
> another in logicalfuncs.c) with the same name and same code for
> checking the privileges for using replication slots. Why can't we have
> a single function
On Tue, Jul 20, 2021 at 08:27:02PM -0400, Alvaro Herrera wrote:
> I have to wonder if there really *is* a use case for CLUSTER in the
> first place on regular tables, let alone on partitioned tables, which
> are likely to be large and thus take a lot of time.
The cluster now is done one partition
On Thu, Sep 02, 2021 at 07:27:09AM +0100, Dean Rasheed wrote:
>
> It's mostly done, but there is one more corner case where it loses
> precision. I'll post an update shortly.
>
I spent some more time looking at this, testing a variety of edge
cases, and the only case I could find that produces
On 9/11/21 8:51 PM, Justin Pryzby wrote:
>
> @Andrew: did you have any comment on this part ?
>
> |Subject: buildfarm xversion diff
> |Forking
> https://www.postgresql.org/message-id/20210328231433.gi15...@telsasoft.com
> |
> |I gave suggestion how to reduce the "lines of diff" metric almost to
Artur Zakirov writes:
> [ v2-0001-signal-backends-on-commit.patch ]
I had an epiphany while looking at this. Now that PostgresMain
calls ProcessNotifyInterrupt at the same place it calls
ProcessCompletedNotifies (which it does since 790026972), we don't
actually need ProcessCompletedNotifies to
Hi,
>
> Thanks, will test rebased version.
> BTW, that is not the temp variable. You can note it because of the
> schema or the lack of a "Transaction end action". That is a normal
> non-temp variable that has been created before. A TEMP variable with an
> ON COMMIT DROP created outside an
Hi!
> 12 сент. 2021 г., в 18:02, Private Information Retrieval(PIR)
> написал(а):
>
> I've created a Postgresql C/C++ Aggregate Extension implementing Private
> Information Retrieval (PIR) using Homomorphic Encryption. The open sourced
> version can be found here:
On Sat, Sep 11, 2021, at 5:28 AM, Bharath Rupireddy wrote:
> We have two static check_permissions functions (one in slotfuncs.c
> another in logicalfuncs.c) with the same name and same code for
> checking the privileges for using replication slots. Why can't we have
> a single function
On Sun, Sep 12, 2021 at 05:38:42PM +0200, Pavel Stehule wrote:
> Hi
>
> > """
> > regression=# create temp variable random_number numeric on commit drop;
> > CREATE VARIABLE
> > regression=# \dV
> > Did not find any schema variables.
> > regression=# declare q cursor for select 1;
> > ERROR:
On Fri, 10 Sept 2021 at 19:30, Jaime Casanova
wrote:
>
> On Tue, Aug 10, 2021 at 01:20:14PM +0100, Simon Riggs wrote:
> > On Wed, 14 Jul 2021 at 12:48, vignesh C wrote:
> >
> > > The patch does not apply on Head anymore, could you rebase and post a
> > > patch. I'm changing the status to
ne 12. 9. 2021 v 17:38 odesílatel Pavel Stehule
napsal:
> Hi
>
>
>
>> Just noted that there is no support for REASSIGN OWNED BY:
>>
>> """
>> regression=# create variable random_number numeric;
>> CREATE VARIABLE
>> regression=# alter variable random_number owner to jcm;
>> ALTER VARIABLE
>>
sure so "ON COMMIT RESET" is not correct in
implemented case. And from the perspective of a PLpgSQL developer, I would
have initialized the variable on any transaction start, so I need to reset
it on any end.
Regards
Pavel
> I will test more this patch tomorrow. Great work, very complete.
>
> --
> Jaime Casanova
> Director de Servicios Profesionales
> SystemGuards - Consultores de PostgreSQL
>
schema-variables-20210912.patch.gz
Description: application/gzip
On Thu, Sep 2, 2021, at 00:03, Daniel Gustafsson wrote:
> I can see value in a function like this one, and the API is AFAICT fairly
> aligned with what I as a user would expect it to be given what we already
> have.
Good to hear and thanks for looking at this patch.
I've fixed the problem due
Hello,
I've created a Postgresql C/C++ Aggregate Extension implementing Private
Information Retrieval (PIR) using Homomorphic Encryption. The open sourced
version can be found here: https://github.com/ReverseControl/MuchPIR .
In essence, with PIR we can retrieve data from any row in a table
In commit aa769f80e, I back-patched the same postgres-fdw.sgml change,
including $SUBJECT, to v12, but I noticed the type info on each FDW
option is present in HEAD only. :-( Here is a patch to remove
$SUBJECT from the back branches for consistency.
Best regards,Etsuro Fujita
Hi,
> -Original Message-
> From: Andrew Dunstan
> Sent: Thursday, September 9, 2021 8:30 PM
> I think I would say that we should remove any "." or ".." element in the
> path except at the beginning, and in the case of ".." also remove the
> preceding element, unless someone can convince
On Sunday, September 12, 2021, Jaime Casanova
wrote:
>
>
> So, what is it? the index row size could be upto 8191 or cannot be
> greater than 2704?
>
The wording doesn’t change between the two: The size cannot be greater the
8191 regardless of the index type being used. This check is first,
36 matches
Mail list logo
