On Wed, Dec 30, 2020 at 04:28:44PM -0500, Andrew Dunstan wrote:
> On 12/30/20 3:42 PM, Tom Lane wrote:
> > Since I'd just seen Noah's commit 52202bb39 go by, I tried
> > modifying src/bin/pg_upgrade/test.sh to do the drop, but that
> > isn't helping. I recall now from prior discussions that we
>
On Thu, Dec 31, 2020 at 4:16 PM Amit Kapila wrote:
> 3. Merged the doc changes patch after some changes mostly cosmetic.
Some minor comments here:
v35-0001 - logicaldecoding.sgml
In the example section:
Change "The following example shows SQL interface can be used to
decode prepared
On Wed, Dec 30, 2020 at 08:22:07PM -0500, Bruce Momjian wrote:
> So, I am learning this cfbot thing. Seems I need -M100% to disable
> rename detection for diffs to work with cfbot --- makes sense.
A good way to make sure that a patch format is correct for the CF bot
would be to use "git
On Thu, Dec 31, 2020 at 10:48 AM Amit Kapila wrote:
>
> On Wed, Dec 30, 2020 at 6:49 PM Amit Kapila wrote:
> >
> > On Tue, Dec 29, 2020 at 3:15 PM Ajin Cherian wrote:
> > >
> > > Hi Sawada-san,
> > >
> > > I think Amit has a plan to commit this patch-set in phases.
> > >
> >
> > I have pushed
On Wed, Dec 30, 2020 at 7:47 PM Bharath Rupireddy
wrote:
>
> Thanks for the comments.
>
> How about naming like below more generically and placing them in
> parallel.h so that it will also be used for refresh materialized view?
>
> +typedef enum ParallelInsertTupleCostOpt
> +{
> +
Please find attached :)
This could probably use a lot of filling in, but having it in the
actual documentation beats needing to know folklore even to know
that the capability is there.
Best,
David.
--
David Fetter http://fetter.org/
Phone: +1 415 235 3778
Remember to vote!
Consider donating
On Wed, Dec 30, 2020 at 11:11 PM Alexey Kondratov
wrote:
> On 2020-12-30 17:59, Bharath Rupireddy wrote:
> > On Wed, Dec 30, 2020 at 5:20 PM Alexey Kondratov
> > wrote:
> >>
> >> On 2020-12-30 09:10, Bharath Rupireddy wrote:
> >> I still have some doubts that it is worth of allowing to call
> >>
On Wed, Dec 30, 2020 at 06:49:34PM -0500, Stephen Frost wrote:
> The API to fetch the KEK doesn't care at all about where it's stored or
> how it's derived or anything like that. There's a relatively small
> change which could be made to have PG request all of the keys that it'll
> need on
On Wed, Dec 30, 2020 at 07:35:57PM -0500, Bruce Momjian wrote:
> I now understand the wisdom of moving the remaining hex functions to
> /common. I know someone already suggested that, and the attached patch
> does this.
>
> I will add the attached patch to the commitfest so I can get cfbot
>
I now understand the wisdom of moving the remaining hex functions to
/common. I know someone already suggested that, and the attached patch
does this.
I will add the attached patch to the commitfest so I can get cfbot
testing.
--
Bruce Momjian https://momjian.us
EnterpriseDB
On Mon, Dec 28, 2020 at 9:49 PM Peter Geoghegan wrote:
> I would like to commit this patch to v12, the first version that did
> this process during original execution rather than in REDO routines.
> It seems worth keeping the back branches in sync here. I suspect that
> the old approach used
Greetings,
* Fabien COELHO (coe...@cri.ensmp.fr) wrote:
> I think that an API should be carefully thought about, without assumption
> about the underlying cryptography (algorithm, key lengths, modes, how keys
> are derived and stored, and so on), and its usefulness be demonstrated by
> actually
On Mon, Dec 28, 2020 at 06:15:44PM -0400, Fabien COELHO wrote:
> The API should NOT make assumptions about the cryptographic design, what
> depends about what, where things are stored… ISTM that Pg should only care
> about naming keys, holding them when created/retrieved (but not create
> them),
Greetings,
* Paul Martinez (paul...@google.com) wrote:
> You've identified exactly the problem we're running into -- we want to
> allow customers, who aren't superusers, to create replication roles.
This is also where it's probably useful to think about what the impact
of that is- after all,
On 12/30/20 3:42 PM, Tom Lane wrote:
> I broke $SUBJECT again today by removing regress_putenv from
> regress.so. I don't really want to put it back, but that means
> we need a way to drop the corresponding SQL function from the
> old version's regression database before attempting an upgrade.
On Tue, 15 Dec 2020 at 23:59, Jeff Davis wrote:
>
> On Tue, 2020-12-15 at 17:37 +, Simon Riggs wrote:
> >
> > I definitely don't agree with the premise that all existing heap
> > options should be common across all new or extension tableAMs. There
> > are dozens of such options and I don't
On Wed, Dec 30, 2020 at 03:00:17PM -0500, Tom Lane wrote:
> David Fetter writes:
> > On Wed, Dec 30, 2020 at 08:24:06PM +0100, David Fetter wrote:
> >> On Mon, Sep 07, 2020 at 11:57:58AM +0900, Michael Paquier wrote:
> >>> I have looked at the patch of this thread, and I doubt that it is a
> >>>
Hi Surafel,
On 3 Sep 2020, at 19:22, Surafel Temesgen wrote:
This is my review of your patch
Thanks for the review.
subqueries in row trigger's is not supported in your patch so the the
documentation have to reflect it
It is still the case that the documentation says this. But, that may
On Wed, Dec 30, 2020 at 12:28 PM Andrey Borodin wrote:
> I think that sharing "various small changes to permission checks" is a really
> good idea.
>
> > 30 дек. 2020 г., в 20:39, Stephen Frost написал(а):
> > In other words, I suspect people would be happier if we
> > provided a way for
Hi,
A question from a colleague made me wonder if there are scenarios where
two subsequent crashes could lead to wrong WAL to be applied.
Imagine the following scenario
[ xlog page 1 ][ xlog page 2 ][ xlog page 3 ][ xlog page 4 ]
^flush^write ^insert
I broke $SUBJECT again today by removing regress_putenv from
regress.so. I don't really want to put it back, but that means
we need a way to drop the corresponding SQL function from the
old version's regression database before attempting an upgrade.
Since I'd just seen Noah's commit 52202bb39 go
On Wed, 30 Dec 2020 at 15:00, Tom Lane wrote:
> In the third place,
> I believe the vast majority of users don't invoke initdb "by hand"
> anymore. The typical scenario is to go through a packager-provided
> script, which almost certainly won't offer access to these additional
> options.
I
It works - now it compiles clean and all checks are passed, thank you. I
will continue with more complex tests.
На ср, 30.12.2020 г. в 21:50 ч. David Fetter написа:
> On Wed, Dec 30, 2020 at 09:32:26PM +0200, Krasiyan Andreev wrote:
> > Hi, after latest committed patches about multirange
> On Wed, Dec 30, 2020 at 07:48:57PM +0100, Pavel Stehule wrote:
> st 30. 12. 2020 v 14:46 odesílatel Dmitry Dolgov <9erthali...@gmail.com>
> napsal:
>
> > > On Wed, Dec 30, 2020 at 02:45:12PM +0100, Dmitry Dolgov wrote:
> > > > On Sat, Dec 26, 2020 at 01:24:04PM -0500, Tom Lane wrote:
> > > >
> >
David Fetter writes:
> On Wed, Dec 30, 2020 at 08:24:06PM +0100, David Fetter wrote:
>> On Mon, Sep 07, 2020 at 11:57:58AM +0900, Michael Paquier wrote:
>>> I have looked at the patch of this thread, and I doubt that it is a
>>> good idea to put more burden into initdb for that. I agree that
>>>
On Wed, Dec 30, 2020 at 09:32:26PM +0200, Krasiyan Andreev wrote:
> Hi, after latest committed patches about multirange datatypes, I get a
> compilation error,
Oh, right. I'd been meaning to send a patch to fix that. Here it is.
Best,
David.
--
David Fetter http://fetter.org/
Phone: +1 415 235
Hi, after latest committed patches about multirange datatypes, I get a
compilation error,
when I try to apply a patch about respect/ignore null for window functions.
Without it applied, it complies clean and all checks are passed.
[krasiyan@localhost build]$
On Wed, Dec 30, 2020 at 08:24:06PM +0100, David Fetter wrote:
> On Mon, Sep 07, 2020 at 11:57:58AM +0900, Michael Paquier wrote:
> > On Thu, Jul 02, 2020 at 04:02:21PM +0200, Daniel Gustafsson wrote:
> > > The CF Patch Tester consider this patch to be malformed and is unable to
> > > apply
> > >
On Mon, Sep 07, 2020 at 11:57:58AM +0900, Michael Paquier wrote:
> On Thu, Jul 02, 2020 at 04:02:21PM +0200, Daniel Gustafsson wrote:
> > The CF Patch Tester consider this patch to be malformed and is unable to
> > apply
> > and test it. Can you please submit a rebased version?
>
> I have
st 30. 12. 2020 v 14:46 odesílatel Dmitry Dolgov <9erthali...@gmail.com>
napsal:
> > On Wed, Dec 30, 2020 at 02:45:12PM +0100, Dmitry Dolgov wrote:
> > > On Sat, Dec 26, 2020 at 01:24:04PM -0500, Tom Lane wrote:
> > >
> > > In a case like jsonpath['...'], the initially UNKNOWN-type literal
>
> 30 дек. 2020 г., в 20:26, Stephen Frost написал(а):
>
> I'd strongly suggest that, instead, you consider proposing changes which
> would address the actual use cases you have and work with the community
> to have those included in core, which would further have the added
> property that
Attached is the latest patch against HEAD - basically fixes a few typos.
Cheers,
Greg
v3-psql-df-pick-function-by-type.patch
Description: Binary data
On 2020-12-30 17:59, Bharath Rupireddy wrote:
On Wed, Dec 30, 2020 at 5:20 PM Alexey Kondratov
wrote:
On 2020-12-30 09:10, Bharath Rupireddy wrote:
I still have some doubts that it is worth of allowing to call
postgres_fdw_disconnect() in the explicit transaction block, since it
adds a lot of
On Wed, Dec 30, 2020 at 05:27:04PM +0100, Daniel Verite wrote:
> David Fetter wrote:
>
> +Datum
> +byteapopcount(PG_FUNCTION_ARGS)
> +{
> + bytea *t1 = PG_GETARG_BYTEA_PP(0);
> + int len, result;
> +
> + len = VARSIZE_ANY_EXHDR(t1);
> + result =
David Fetter wrote:
+Datum
+byteapopcount(PG_FUNCTION_ARGS)
+{
+ bytea *t1 = PG_GETARG_BYTEA_PP(0);
+ int len, result;
+
+ len = VARSIZE_ANY_EXHDR(t1);
+ result = pg_popcount(VARDATA_ANY(t1), len);
+
+ PG_RETURN_INT32(result);
+}
The input may
Greetings,
* Michael Paquier (mich...@paquier.xyz) wrote:
> On Tue, Dec 29, 2020 at 02:26:19PM -0600, Paul Martinez wrote:
> > The checks for whether the current user can create a user with the
> > SUPERUSER,
> > REPLICATION, or BYPASSRLS attributes are chained together using if/else-if,
> >
Greetings,
* Paul Martinez (paul...@google.com) wrote:
> This small patch simply modifies the code to replace the if/else-if chain with
> separate if statements, and always checks whether the user has the CREATEROLE
> privilege. (The have_createrole_privilege function includes another superuser
>
On Mon, 16 Nov 2020 at 15:32, Bharath Rupireddy
wrote:
>
> On Mon, Nov 16, 2020 at 8:02 PM Paul Guo wrote:
> >
> > > On Nov 13, 2020, at 7:21 PM, Bharath Rupireddy
> > > wrote:
> > >
> > > On Tue, Nov 10, 2020 at 3:47 PM Paul Guo wrote:
> > >>
> > >> Thanks for doing this. There might be
On Wed, Dec 30, 2020 at 5:20 PM Alexey Kondratov
wrote:
>
> On 2020-12-30 09:10, Bharath Rupireddy wrote:
> > Hi,
> >
> > I'm posting a v4-0001 patch for the new functions
> > postgres_fdw_get_connections() and postgres_fdw_disconnect(). In this
> > patch, I tried to address the review comments
On 2020-10-09 20:46, Andres Freund wrote:
Is there really a good reason for forcing the client to issue
NextResult, Describe, Execute for each of the dynamic result sets? It's
not like there's really a case for allowing the clients to skip them,
right? Why aren't we sending something more like
The first file of Amit's patch can not only re-range the code, but also fix a
hidden bug.
To make it easy to see, I attach another patch.
"RelationIdGetRelation" will increase ref on owner-relrefarr, without
"RelationClose", the owner-relrefarr will enlarge and re-hash.
When the capacity of
Thanks for the comments.
How about naming like below more generically and placing them in
parallel.h so that it will also be used for refresh materialized view?
+typedef enum ParallelInsertTupleCostOpt
+{
+ PINS_SELECT_QUERY = 1 << 0, /* turn on this before planning */
+ /*
+ * Turn on this
On 23-10-2020 07:51, Luc Vlaming wrote:
On 14.10.20 09:38, Luc Vlaming wrote:
Hi,
It seems I ran the wrong make checks to verify everything is correct
(make check instead
of make installcheck-world) and this uncovered another regress test
change. I also noticed
the statistics are sometimes
On Wed, 30 Dec 2020 at 13:04, Michael Paquier wrote:
> > Yes, we did think of this feature already and rejected it.
>
> I don't recall seeing such a discussion. Do you have some references?
> Just a matter of curiosity :)
Off-list discussions.
--
Simon Riggs
> On Wed, Dec 30, 2020 at 02:45:12PM +0100, Dmitry Dolgov wrote:
> > On Sat, Dec 26, 2020 at 01:24:04PM -0500, Tom Lane wrote:
> >
> > In a case like jsonpath['...'], the initially UNKNOWN-type literal could
> > in theory be coerced to any of these types, so you'd have to resolve that
> > case
> On Sat, Dec 26, 2020 at 01:24:04PM -0500, Tom Lane wrote:
>
> In a case like jsonpath['...'], the initially UNKNOWN-type literal could
> in theory be coerced to any of these types, so you'd have to resolve that
> case manually. The overloaded-function code has an internal preference
> that
On Sat, Dec 26, 2020 at 9:16 PM vignesh C wrote:
>
> On Thu, Dec 17, 2020 at 4:28 AM Bruce Momjian wrote:
> >
> > On Mon, Dec 7, 2020 at 01:56:50PM +0530, vignesh C wrote:
> > > Hi,
> > >
> > > Added missing copy related data structures to typedefs.list, these
> > > data structures were added
On 30-12-2020 02:57, Andres Freund wrote:
Hi,
Great to see work in this area!
On 2020-12-28 09:44:26 +0100, Luc Vlaming wrote:
I would like to propose a small patch to the JIT machinery which makes the
IR code generation lazy. The reason for postponing the generation of the IR
code is that
On Tue, Dec 29, 2020 at 3:15 PM Ajin Cherian wrote:
>
> Hi Sawada-san,
>
> I think Amit has a plan to commit this patch-set in phases.
>
I have pushed the first patch and I would like to make a few changes
in the second patch after which I will post the new version. I'll try
to do that tomorrow
On Mon, Dec 28, 2020 at 11:06:30AM +, Simon Riggs wrote:
> Agreed, it is a footgun. -1 to commit the patch as-is.
>
> The patch to avoid WAL is simple but it is dangerous for both the user
> and the PostgreSQL project.
Something that has not been mentioned on this thread is that if you
could
On Thu, Dec 24, 2020 at 01:23:40PM +0900, Michael Paquier wrote:
> Please note that I have added an entry in the CF app for the moment so
> as we don't lose track of it:
> https://commitfest.postgresql.org/31/2892/
I have been able to look at that again today, and applied it. I have
tweaked a
On Thu, 10 Dec 2020 at 18:40, Peter Eisentraut
wrote:
>
> On 2020-06-24 20:21, Peter Eisentraut wrote:
> > On 2020-06-24 10:12, Vik Fearing wrote:
> >> On 6/24/20 8:35 AM, Peter Eisentraut wrote:
> >>> I was checking some loose ends in SQL conformance, when I noticed: We
> >>> support GRANT role
On Tue, 29 Dec 2020 at 23:08, Justin Pryzby wrote:
>
> On Fri, Dec 25, 2020 at 03:41:46PM +0900, Michael Paquier wrote:
> > On Wed, Dec 09, 2020 at 02:13:29PM -0600, Justin Pryzby wrote:
> > > I thought this was a good idea, but didn't hear back when I raised it
> > > before.
> > >
> > > Failing
Thanks for looking into this, Justin!
> 30 дек. 2020 г., в 09:39, Justin Pryzby написал(а):
>
> There's some typos in the current patch;
>
> farer (further: but it's not your typo)
> positiion
> reduce a => reduce the
> monotonicity what => monotonicity, which
> lesser good => less good
>
Hi all,
On Fri, Dec 25, 2020 at 4:32 PM Masahiko Sawada wrote:
>
> Hello, hackers!
>
> 2021-01 commitfest will start from the new year, in a week. I'm happy
> to volunteer to be the CFM for this one.
>
> It's time to register your patch in the commitfest, if not yet.
>
> If you already have a
On Tue, Dec 29, 2020 at 05:49:24AM -0800, Noah Misch wrote:
> https://postgr.es/m/20201031163518.gb4039...@rfd.leadboat.com gave $SUBJECT as
> one of the constituent projects for changing the public schema default ACL.
> This ended up being simple. Attached.
This is defective; it fails to
On Wed, Dec 30, 2020 at 9:25 AM Bharath Rupireddy
wrote:
>
> On Wed, Dec 30, 2020 at 5:22 AM Zhihong Yu wrote:
> > w.r.t. v17-0004-Enable-CTAS-Parallel-Inserts-For-Append.patch
> >
> > + * Push the dest receiver to Gather node when it is either at the top of
> > the
> > + * plan or under top
On Wed, Dec 30, 2020 at 11:28 AM Tang, Haiying
wrote:
>
> Hi Amit,
>
> In last
> mail(https://www.postgresql.org/message-id/66851e198f6b41eda59e6257182564b6%40G08CNEXMBPEKD05.g08.fujitsu.local),
> I've sent you the performance test results(run only 1 time) on single table.
> Here is my the
On Wed, Dec 30, 2020 at 10:47 AM Bharath Rupireddy
wrote:
>
> On Wed, Dec 30, 2020 at 10:32 AM Dilip Kumar wrote:
> > I have completed reviewing 0001, I don't have more comments, just one
> > question. Soon I will review the remaining patches.
>
> Thanks.
>
> > +/* If parallel inserts are
On 2020-12-30 09:10, Bharath Rupireddy wrote:
Hi,
I'm posting a v4-0001 patch for the new functions
postgres_fdw_get_connections() and postgres_fdw_disconnect(). In this
patch, I tried to address the review comments provided upthread.
Thoughts?
I still have some doubts that it is worth of
Hi,
Per request, I'd like to see about surfacing $Subject to SQL.
Best,
David.
--
David Fetter http://fetter.org/
Phone: +1 415 235 3778
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
>From 28c9b7acad605197a8a242ff929bcce6f3100c91 Mon Sep 17 00:00:00
On Wed, Dec 30, 2020 at 10:49 AM Dilip Kumar wrote:
>
> On Wed, 30 Dec 2020 at 10:47 AM, Bharath Rupireddy
> wrote:
>>
>> On Wed, Dec 30, 2020 at 10:32 AM Dilip Kumar wrote:
>> > I have completed reviewing 0001, I don't have more comments, just one
>> > question. Soon I will review the
> But why do you pass int natts and VacAttrStats **stats to
> acquire_sample_rows()? Is it of any use? It seems to break abstraction too.
Yes, it is really a kluge that should be discussed. The main problem is that we
don’t pass projection information to analyze scan (analyze begin scan
63 matches
Mail list logo
