Hi
I have some questions with your patch. Here are two cases I used to check the
bug.
Case1(PK toasted_key is short), data could be synchronized on HEAD.
---
INSERT INTO toasted_key(toasted_key, toasted_col1) VALUES('111',
repeat('9876543210', 200));
UPDATE toasted_key SET toasted_c
On Tue, Jun 1, 2021 at 11:44 AM Dilip Kumar wrote:
>
> On Tue, Jun 1, 2021 at 11:00 AM Dilip Kumar wrote:
> >
> > On Tue, Jun 1, 2021 at 10:21 AM Amit Kapila wrote:
> > >
> > >
> > > Right, I think you can remove the change related to stream xact and
> > > probably write some comments on why we
On Tue, Jun 1, 2021 at 11:00 AM Dilip Kumar wrote:
>
> On Tue, Jun 1, 2021 at 10:21 AM Amit Kapila wrote:
> >
> > On Tue, Jun 1, 2021 at 9:59 AM Dilip Kumar wrote:
> > >
> > > On Tue, Jun 1, 2021 at 9:53 AM Amit Kapila
> > > wrote:
> > > >
> > > > On Mon, May 31, 2021 at 8:12 PM Dilip Kumar
Hi,
Andres Freund wrote 2021-05-31 00:07:
Hi,
On 2021-05-30 03:10:26 +0300, Yura Sokolov wrote:
While this result is not directly applied to stock PostgreSQL, I
believe
page compression is important for full_page_writes with
wal_compression
enabled. And probably when PostgreSQL is used on fi
On Tue, Jun 1, 2021 at 10:21 AM Amit Kapila wrote:
>
> On Tue, Jun 1, 2021 at 9:59 AM Dilip Kumar wrote:
> >
> > On Tue, Jun 1, 2021 at 9:53 AM Amit Kapila wrote:
> > >
> > > On Mon, May 31, 2021 at 8:12 PM Dilip Kumar wrote:
> > > >
> > > > On Mon, May 31, 2021 at 6:32 PM Dilip Kumar
> > > >
On Tue, Jun 1, 2021 at 10:07 AM Masahiko Sawada wrote:
>
> On Tue, Jun 1, 2021 at 1:01 PM Amit Kapila wrote:
> >
> > On Tue, Jun 1, 2021 at 12:55 AM Peter Eisentraut
> > wrote:
> > >
> > > On 27.05.21 12:04, Amit Kapila wrote:
> > > >>> Also, I am thinking that instead of a stat view, do we need
On Tue, Jun 1, 2021 at 9:59 AM Dilip Kumar wrote:
>
> On Tue, Jun 1, 2021 at 9:53 AM Amit Kapila wrote:
> >
> > On Mon, May 31, 2021 at 8:12 PM Dilip Kumar wrote:
> > >
> > > On Mon, May 31, 2021 at 6:32 PM Dilip Kumar wrote:
> > > >
> > > > I missed to do the test for streaming. I will to tha
On Tue, Jun 1, 2021 at 1:01 PM Amit Kapila wrote:
>
> On Tue, Jun 1, 2021 at 12:55 AM Peter Eisentraut
> wrote:
> >
> > On 27.05.21 12:04, Amit Kapila wrote:
> > >>> Also, I am thinking that instead of a stat view, do we need
> > >>> to consider having a system table (pg_replication_conflicts or
On Tue, Jun 1, 2021 at 9:53 AM Amit Kapila wrote:
>
> On Mon, May 31, 2021 at 8:12 PM Dilip Kumar wrote:
> >
> > On Mon, May 31, 2021 at 6:32 PM Dilip Kumar wrote:
> > >
> > > I missed to do the test for streaming. I will to that tomorrow and reply
> > > back.
> >
> > For streaming transaction
On Mon, May 31, 2021 at 8:12 PM Dilip Kumar wrote:
>
> On Mon, May 31, 2021 at 6:32 PM Dilip Kumar wrote:
> >
> > I missed to do the test for streaming. I will to that tomorrow and reply
> > back.
>
> For streaming transactions this issue is not there. Because this
> problem will only occur if
Hi Horiguchi-san,
On 2021/05/31 16:58, Kyotaro Horiguchi wrote:
So, I started a thread for this topic diverged from the following
thread.
https://www.postgresql.org/message-id/4698027d-5c0d-098f-9a8e-8cf09e36a...@nttcom.co.jp_1
So, what should we do for the user? I think we should put some no
On Tue, Jun 1, 2021 at 12:55 AM Peter Eisentraut
wrote:
>
> On 27.05.21 12:04, Amit Kapila wrote:
> >>> Also, I am thinking that instead of a stat view, do we need
> >>> to consider having a system table (pg_replication_conflicts or
> >>> something like that) for this because what if stats informa
On Thu, Apr 08, 2021 at 11:41:17AM +0200, Magnus Hagander wrote:
> I've applied this patch with some minor changes.
I wondered if the new pg_wait_for_backend_termination() could replace
regress.c:wait_pid(). I think it can't, because the new function requires the
backend to still be present in th
On Tue, May 25, 2021 at 12:51 PM Michael Paquier wrote:
>
> On Tue, May 25, 2021 at 12:06:38PM +0530, Pavan Deolasee wrote:
> > While working on an output plugin that uses streaming protocol, I hit an
> > assertion failure. Further investigations revealed a possible bug in core
> > Postgres. This
On Mon, May 31, 2021 at 12:33:44PM +0500, Andrey Borodin wrote:
> Would it make sense to run our own benchmarks?
Yes, I think that it could be a good idea to run some custom-made
benchmarks as that could mean different bottlenecks found when it
comes to PG.
There are a couple of factors that matt
On Monday, May 31, 2021, Laurenz Albe wrote:
> On Mon, 2021-05-31 at 15:55 -0400, Tom Lane wrote:
> > > If I have two procedures
> > > p1(IN int, IN int, OUT int, OUT int)
> > > p1(OUT int, OUT int)
> > > then a DROP, or ALTER, or GRANT, etc. on p1(int, int) should operate
> on
> > > the second o
On Fri, May 21, 2021 at 03:56:31PM +0530, Bharath Rupireddy wrote:
> On Fri, May 21, 2021 at 6:08 AM Michael Paquier wrote:
>> I am not sure that I see the point of using a random() number here
>> while the backend ID, or just the PID, would easily provide enough
>> entropy for this internal alias
On Mon, 2021-05-31 at 15:55 -0400, Tom Lane wrote:
> > If I have two procedures
> > p1(IN int, IN int, OUT int, OUT int)
> > p1(OUT int, OUT int)
> > then a DROP, or ALTER, or GRANT, etc. on p1(int, int) should operate on
> > the second one in a spec-compliant implementation, but you propose to
>
On Mon, May 31, 2021 at 09:14:36AM +0900, Michael Paquier wrote:
> I have been finally able to poke at that, resulting in the attached.
> You are right that adding only the fallback implementation for
> setenv() seems to be enough. I cannot get my environment to complain,
> and the code compiles.
Michael Paquier writes:
>>> Another thing that strikes me as incorrect is that we don't unset
>>> PGGSSENCMODE or PGGSSLIB in TestLib.pm. Just noting it on the way..
>> Agreed, that seems bogus.
> There may be others, and I have not checked yet. I'd rather do a
> backpatch for this part, would
On Mon, May 31, 2021 at 09:36:20AM -0400, Tom Lane wrote:
> Interesting --- I was considering running such a test locally, but
> didn't get round to it yet.
Just to be clear, that's my Windows dev box.
> It seems like the ideal solution would be to make pg_GSS_have_cred_cache
> smarter, so that w
On 2021-May-31, Andrew Dunstan wrote:
> However, not all buildfarm animals are set up to build the docs, and not
> all owners necessarily want to. Moreover, we have provision for testing
> various docs formats (PDF, epub etc). So I'd like to be able to build
> and install all the world EXCEPT the
On Sun, Apr 25, 2021 at 02:40:54PM -0400, Stephen Frost wrote:
> * Noah Misch (n...@leadboat.com) wrote:
> > On Mon, Apr 19, 2021 at 05:38:43PM -0400, Stephen Frost wrote:
> > > > > > On Fri, Apr 16, 2021 at 3:57 AM Noah Misch
> > > > > > wrote:
> > > > > >> Hence, I do find it reasonable to let
I wrote:
> Peter Eisentraut writes:
>> I don't see that.
> It's under CREATE PROCEDURE. 11.60 SR 20 says
Oh... just noticed something else relevant to this discussion: SR 13
in the same section saith
13) If R is an SQL-invoked function, then no
in NPL shall contain a .
In other words, t
Greetings,
* Andres Freund (and...@anarazel.de) wrote:
> On 2021-05-27 17:00:23 -0400, Bruce Momjian wrote:
> > If you go in that direction, you should make sure pg_upgrade preserves
> > what you use (it does not preserve relfilenode, just pg_class.oid)
>
> Is there a reason for pg_upgrade not to
"Joel Jacobson" writes:
> On Mon, May 31, 2021, at 16:16, Andrew Dunstan wrote:
>> However, not all buildfarm animals are set up to build the docs, and not
>> all owners necessarily want to. Moreover, we have provision for testing
>> various docs formats (PDF, epub etc). So I'd like to be able to
Peter Eisentraut writes:
> On 26.05.21 19:28, Tom Lane wrote:
>> Why? If it actually works that way right now, I'd maintain
>> strenously that it's broken. The latter should be referring
>> to a procedure with two IN arguments. Even if the SQL spec
>> allows fuzziness about that, we cannot affo
On Mon, May 31, 2021, at 16:16, Andrew Dunstan wrote:
> However, not all buildfarm animals are set up to build the docs, and not
> all owners necessarily want to. Moreover, we have provision for testing
> various docs formats (PDF, epub etc). So I'd like to be able to build
> and install all the wo
On 27.05.21 12:04, Amit Kapila wrote:
Also, I am thinking that instead of a stat view, do we need
to consider having a system table (pg_replication_conflicts or
something like that) for this because what if stats information is
lost (say either due to crash or due to udp packet loss), can we rely
On 26.05.21 19:28, Tom Lane wrote:
Peter Eisentraut writes:
AFAICT, your patch does not main the property that
CREATE PROCEDURE p1(OUT int, OUT int)
corresponds to
DROP PROCEDURE p1(int, int)
which would be bad.
Why? If it actually works that way right now, I'd maintain
strenousl
ne 7. 2. 2021 v 19:09 odesílatel Pavel Stehule
napsal:
> Hi
>
> fresh rebase
>
only rebase
Regards
Pavel
> Regards
>
> Pavel
>
diff --git a/src/pl/plpgsql/src/pl_exec.c b/src/pl/plpgsql/src/pl_exec.c
index 78b593d12c..1048343c21 100644
--- a/src/pl/plpgsql/src/pl_exec.c
+++ b/src/pl/plpgsql/
> Please add this patch to the commitfest so that it's not forgotten. It
> will be considered as a new feature so will be considered for commit
> after the next commitfest.
I did [1]. You can add yourself as a reviewer.
> I don't understand why we need to complicate the expressions when
> sendin
Alexander Pyhalov писал 2021-05-31 15:39:
Hi.
There's issue with join pushdown after
commit 86dc90056dfdbd9d1b891718d2e5614e3e432f35
Author: Tom Lane
Date: Wed Mar 31 11:52:34 2021 -0400
...
You'll get
ERROR: input of anonymous composite types is not implemented
CONTEXT: whole-row refer
On Mon, May 31, 2021 at 6:32 PM Dilip Kumar wrote:
>
> On Mon, 31 May 2021 at 4:29 PM, Dilip Kumar wrote:
>>
>> On Mon, May 31, 2021 at 8:50 AM Dilip Kumar wrote:
>> >
>> > On Mon, 31 May 2021 at 8:21 AM, Amit Kapila
>> > wrote:
>> >>
>> >> Okay, I think it would be better if we can test this
## Esteban Zimanyi (ezima...@ulb.ac.be):
> Is there a step-by-step procedure specified somewhere?
The first step is not to disable autovacuum... (why would you want to
do that?).
> For example, before launching the tests there is a load.sql file that loads
> all the test tables. The file starts
I've been thinking about rationalizing some of the buildfarm code, which
has grown somewhat like Topsy over the years. One useful thing would be
to run all the "make" and "install" pieces together. When the buildfarm
started we didn't have world targets, but they are now almost ancient
history the
On Sat, May 29, 2021 at 9:20 PM Bharath Rupireddy
wrote:
>
> On Sat, May 29, 2021 at 9:08 PM vignesh C wrote:
> > One minor comment:
> > You can remove the brackets around errcode, You could change:
> > + if (localeEl)
> > + ereport(ERROR,
> > + (errcode(ERRCODE_SYNTAX_ERROR),
> > + errmsg("optio
Many thanks Tom for your feedback. I appreciate it.
Actually the tests work in parallel with autovacuum, I just wanted to
minimize the test time since the autovacuum launches in the middle of the
many regression and robustness tests. But then I follow your advice.
Regards
Esteban
On Mon, May 3
Esteban Zimanyi writes:
> Any idea how to disable the autovacuum during the regression and coverage
> tests for the MobilityDB extension ?
TBH, this seems like a pretty bad idea. If your extension doesn't
behave stably with autovacuum it's not going to be much use in the
real world.
In the core
mzj1...@mail.ustc.edu.cn writes:
> In most scenarios, we want to assign permissions to a table and partition
> table to a user, but in postgresql, permissions are not recursive, so we need
> to spend extra energy to do this. So let's ask the postgresql team, why is
> the permission granted in a
On Sat, May 29, 2021 at 9:10 PM Tom Lane wrote:
>
> vignesh C writes:
> > I felt inclusion of alias types regpublication and regsubscription will
> > help the logical replication users.
>
> This doesn't really seem worth the trouble --- how often would you
> use these?
>
> If we had a policy of i
Michael Paquier writes:
> On Mon, May 31, 2021 at 12:05:12AM -0400, Tom Lane wrote:
>> What is not clear is why GSS is acting that way. We wouldn't
>> have tried a GSS connection unless pg_GSS_have_cred_cache
>> succeeded ... so how come that worked but then gss_init_sec_context
>> complained "Cr
On Mon, 31 May 2021 at 4:29 PM, Dilip Kumar wrote:
> On Mon, May 31, 2021 at 8:50 AM Dilip Kumar wrote:
> >
> > On Mon, 31 May 2021 at 8:21 AM, Amit Kapila
> wrote:
> >>
> >> Okay, I think it would be better if we can test this once for the
> >> streaming case as well. Dilip, would you like to
Hi.
There's issue with join pushdown after
commit 86dc90056dfdbd9d1b891718d2e5614e3e432f35
Author: Tom Lane
Date: Wed Mar 31 11:52:34 2021 -0400
Rework planning and execution of UPDATE and DELETE
To make sure that join pushdown path selected, one can patch
contrib/postgres_fdw/postgres_
On Thu, May 27, 2021 at 10:01:49AM -0700, Andres Freund wrote:
> Why would it be intrusive? We're talking a split second here, no? More
> importantly, I don't think it's correct to release the locks at that
> point.
I have been looking at all that for the last couple of days, and
checked the code
Hi Emre,
This looks like a good improvement.
Please add this patch to the commitfest so that it's not forgotten. It
will be considered as a new feature so will be considered for commit
after the next commitfest.
Mean time here are some comments.
+/*
+ * Deparse IS [NOT] TRUE/FALSE/UNKNOWN express
On Mon, May 31, 2021 at 12:39 PM Masahiko Sawada wrote:
>
> On Sat, May 29, 2021 at 3:54 PM Amit Kapila wrote:
> >
> > > > > 1. the worker records the XID and commit LSN of the failed transaction
> > > > > to a catalog.
> > > > >
> > > >
> > > > When will you record this info? I am not sure if we
On Fri, May 28, 2021 at 11:55 AM Amit Kapila wrote:
>
> One minor comment for 0001.
> * Special case: if when tables were specified but copy_data is
> + * false then it is safe to enable two_phase up-front because
> + * those tables are already initially READY state. Note, if
> + * the subscriptio
On Mon, May 31, 2021 at 8:50 AM Dilip Kumar wrote:
>
> On Mon, 31 May 2021 at 8:21 AM, Amit Kapila wrote:
>>
>> Okay, I think it would be better if we can test this once for the
>> streaming case as well. Dilip, would you like to do that and send the
>> updated patch as per one of the comments by
On Mon, 31 May 2021 at 3:33 PM, tanghy.f...@fujitsu.com <
tanghy.f...@fujitsu.com> wrote:
> On Mon, May 31, 2021 5:12 PM Dilip Kumar wrote:
> >
> > The problem is if the key attribute is not changed we don't log it as
> > it should get logged along with the updated tuple, but if it is
> > externa
On Mon, May 31, 2021 5:12 PM Dilip Kumar wrote:
>
> The problem is if the key attribute is not changed we don't log it as
> it should get logged along with the updated tuple, but if it is
> externally stored then the complete key will never be logged because
> there is no log from the toast table
On Thu, May 27, 2021 at 10:36 AM Peter Eisentraut
wrote:
>
>
> The RADIUS-related checks in parse_hba_line() did not respect elevel
> and did not fill in *err_msg. Also, verify_option_list_length()
> pasted together error messages in an untranslatable way. To fix the
> latter, remove the functio
Dear Christoph
Many thanks for your prompt reply !
Is there a step-by-step procedure specified somewhere?
For example, before launching the tests there is a load.sql file that loads
all the test tables. The file starts as follows
SET statement_timeout = 0;
SET lock_timeout = 0;
SET idle_in_tran
On Mon, May 31, 2021 at 12:20 PM Dilip Kumar wrote:
>
> On Mon, May 31, 2021 at 8:04 AM tanghy.f...@fujitsu.com
> wrote:
> >
> > On Friday, May 28, 2021 6:51 PM, Dilip Kumar wrote:
> > > Seems you did not set the replica identity for updating the tuple.
> > > Try this before updating, and it sho
## Esteban Zimanyi (ezima...@ulb.ac.be):
> I have tried
> alter system set autovacuum = off;
> but it does not seem to work.
Did you reload the configuration ("SELECT pg_reload_conf()" etc) after
that? If not, that's your problem right there.
Regards,
Christoph
--
Spare Space
On Mon, May 31, 2021 at 12:19 AM wrote:
> Our team uses postgresql as the database, but we have some problem on
> grant and revoke.
>
> imagine the following sequence of operations:
>
> create user test;
> CREATE TABLE sales (trans_id int, date date, amount int)
> PARTITION BY RANGE (date);
> CRE
Sorry for missing this.
At Mon, 31 May 2021 12:52:54 +0900, Fujii Masao
wrote in
>
> On 2021/05/19 19:24, Fujii Masao wrote:
> > On 2021/05/19 16:43, Kyotaro Horiguchi wrote:
> >> +1 for adding some tests for pg_wal_replay_pause() but the test seems
> >> like checking only that pg_get_wal_repl
The comparison predicates IS [NOT] TRUE/FALSE/UNKNOWN were not
recognised by postgres_fdw, so they were not pushed down to the remote
server. The attached patch adds support for them.
I am adding this to the commitfest 2021-07.
0001-postgres_fdw-Handle-boolean-comparison-predicates.patch
Descri
Moved to another thread.
https://www.postgresql.org/message-id/20210531.165825.921389284096975508.horikyota@gmail.com
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
So, I started a thread for this topic diverged from the following
thread.
https://www.postgresql.org/message-id/4698027d-5c0d-098f-9a8e-8cf09e36a...@nttcom.co.jp_1
At Mon, 31 May 2021 11:52:05 +0900, Tatsuro Yamada
wrote in
> Since the above behavior is different from the behavior of the
> tes
> 25 мая 2021 г., в 12:26, Michael Paquier написал(а):
>
> On Mon, May 24, 2021 at 11:44:45PM -0500, Justin Pryzby wrote:
>> The goal is to support 2+ "methods" (including "none"), which takes 4 bits,
>> so
>> may as well support 3 methods.
>>
>> - uncompressed
>> - pglz
>> - lz4
>> - zlib o
Dear all
Any idea how to disable the autovacuum during the regression and coverage
tests for the MobilityDB extension ?
I have tried
alter system set autovacuum = off;
but it does not seem to work.
Any suggestions are much appreciated.
Esteban
Our team uses postgresql as the database, but we have some problem on grant and
revoke.
imagine the following sequence of operations:
createuser test;
CREATETABLE sales (trans_id int,datedate, amount int)
PARTITIONBYRANGE(date);
CREATETABLE sales_1 PARTITION OF sales
FORVALUESFROM('2001-01-0
On Sat, May 29, 2021 at 3:54 PM Amit Kapila wrote:
>
> On Sat, May 29, 2021 at 8:27 AM Masahiko Sawada wrote:
> >
> > On Thu, May 27, 2021 at 7:04 PM Amit Kapila wrote:
> > >
> > > On Thu, May 27, 2021 at 1:46 PM Masahiko Sawada
> > > wrote:
> > > >
> > > > 1. the worker records the XID and co
64 matches
Mail list logo
