On Thu, Feb 11, 2021 at 5:33 PM Greg Nancarrow wrote:
>
> On Tue, Feb 9, 2021 at 1:04 AM Amit Langote wrote:
> >
> > * I think that the concerns raised by Tsunakawa-san in:
> >
> >
On Tue, Feb 9, 2021 at 1:04 AM Amit Langote wrote:
>
> * I think that the concerns raised by Tsunakawa-san in:
>
> https://www.postgresql.org/message-id/TYAPR01MB2990CCB6E24B10D35D28B949FEA30%40TYAPR01MB2990.jpnprd01.prod.outlook.com
>
> regarding how this interacts with plancache.c deserve a
Ranier Vilela writes:
> *long* 4 *long int*, *signed long int* -2.147.483.648 a 2.147.483.647
> Therefore long never be > INT_MAX at Windows 64 bits.
> Thus lindex is always false in this expression:
> if (errno != 0 || badp == c || *badp != '\0' || lindex > INT_MAX || lindex
> < INT_MIN)
As I mentioned in connection with adding the src/test/modules/test_regex
test code, I've been fooling with some performance improvements to our
regular expression engine. Here's the first fruits of that labor.
This is mostly concerned with cutting the overhead for handling trivial
unconstrained
On Wed, Feb 10, 2021 at 7:10 PM Peter Geoghegan wrote:
> Attached is v3 of the index. I'll describe the changes I made in more
> detail in my response to your points below.
I forget to mention that v3 adds several assertions like this one:
Assert(!_bt_page_recyclable(BufferGetPage(buf)));
On Wed, Feb 10, 2021 at 2:20 AM Masahiko Sawada wrote:
> Thank you for working on this!
I'm glad that I finally found time for it! It seems like it'll make
things easier elsewhere.
Attached is v3 of the index. I'll describe the changes I made in more
detail in my response to your points below.
On Sun, Jan 24, 2021 at 6:26 PM Andy Fan wrote:
> Hi Masahiko:
>
> On Fri, Jan 22, 2021 at 9:15 PM Masahiko Sawada
> wrote:
>
>> Hi Andy,
>>
>> On Mon, Dec 7, 2020 at 9:15 PM Andy Fan wrote:
>> >
>> >
>> >
>> > On Mon, Dec 7, 2020 at 4:16 PM Jesper Pedersen <
>> jesper.peder...@redhat.com>
On Tue, Feb 9, 2021 at 11:58 PM Heikki Linnakangas wrote:
> Thanks for picking this up!
I actually had a patch for this in 2019, albeit one that remained in
rough shape until recently. Must have forgotten about it.
> Is it really worth the trouble to maintain 'level' on deleted pages? All
> you
On 2/10/21, 2:43 PM, "Bruce Momjian" wrote:
> On Tue, Feb 9, 2021 at 06:48:21PM +, Bossart, Nathan wrote:
>> HOT works wonders when no indexed columns are updated. However, as
>> soon as you touch one indexed column, you lose that optimization
>> entirely, as you must update every index on
2021年2月10日(水) 13:55 Ashutosh Bapat :
>
> On Tue, Feb 9, 2021 at 7:45 PM Kazutaka Onishi wrote:
> >
> > > IIUC, "truncatable" would be set to "false" for relations which do not
> > > have physical storage e.g. views but will be true for regular tables.
> >
> > "truncatable" option is just for the
Another round of doc fixen.
wdiff to follow
commit 389c4ac2febe21fd48480a86819d94fd2eb9c1cc
Author: Justin Pryzby
Date: Wed Feb 10 17:19:51 2021 -0600
doc review for pg_stat_progress_create_index
ab0dfc961b6a821f23d9c40c723d11380ce195a6
should backpatch to v13
diff
On 2021-Jan-21, Alvaro Herrera wrote:
> As you can see in an XXX comment in the libpq test program, the current
> implementation has the behavior that PQgetResult() returns NULL after a
> batch is finished and has reported PGRES_BATCH_END. I don't know if
> there's a hard reason to do that, but
Hi,
Per Coverity.
The use of type "long" is problematic with Windows 64bits.
Long type on Windows 64bits is 32 bits.
See at:
https://docs.microsoft.com/pt-br/cpp/cpp/data-type-ranges?view=msvc-160
*long* 4 *long int*, *signed long int* -2.147.483.648 a 2.147.483.647
Therefore long never be >
Hello, Peter.
If you are interested, the possible patch (based on FPI mask during
replay) was sent with some additional explanation and graphics to (1).
At the moment I unable to find any "incorrectness" in it.
Thanks again for your comments.
Michail.
[1]
On Wed, Feb 10, 2021 at 8:59 PM Hou, Zhijie wrote:
>
> > > >
> > > > else if (IsA(node, Query))
> > > > {
> > > > Query *query = (Query *) node;
> > > >
> > > > /* SELECT FOR UPDATE/SHARE must be treated as unsafe */
> > > > if (query->rowMarks != NULL)
> > >
Hi,
Per Coverity.
If xid is a subtransaction, the setup of base snapshot on the top-level
transaction,
can be not optional, otherwise a Dereference null return value
(NULL_RETURNS) can be raised.
Patch suggestion to fix this.
diff --git a/src/backend/replication/logical/reorderbuffer.c
Hi,
Per Coverity.
The functions ExecGetInsertedCols and ExecGetUpdatedCols at ExecUtils.c
only are safe to call if the variable "ri_RangeTableIndex" is != 0.
Otherwise a possible Dereference after null check (FORWARD_NULL) can be
raised.
Exemple:
void
On Tue, Feb 9, 2021 at 06:48:21PM +, Bossart, Nathan wrote:
> Hello,
>
> I'm hoping to gather some early feedback on a heap optimization I've
> been working on. In short, I'm hoping to add "partial heap only
> tuple" (PHOT) support, which would allow you to skip updating indexes
> for
Greetings,
* Heikki Linnakangas (hlinn...@iki.fi) wrote:
> On 05/02/2021 23:22, Stephen Frost wrote:
> >Unless there's anything else on this, I'll commit these sometime next
> >week.
>
> One more thing: Instead of using 'effective_io_concurrency' GUC directly,
> should call
On Wed, Feb 10, 2021 at 3:06 PM Robert Haas wrote:
> I think you have a fairly big problem with row types. Consider this example:
>
> create table t1 (a int, b text compression pglz);
> create table t2 (a int, b text compression lz4);
> create table t3 (x t1);
> insert into t1 values (1,
Greetings,
* Thomas Munro (thomas.mu...@gmail.com) wrote:
> Rebase attached.
> Subject: [PATCH v15 4/6] Prefetch referenced blocks during recovery.
> diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
> index 4b60382778..ac27392053 100644
> --- a/doc/src/sgml/config.sgml
> +++
On Wed, Feb 10, 2021 at 11:43 AM Robert Haas wrote:
> On Mon, Jan 25, 2021 at 10:07 AM Jan Wieck wrote:
> > Our current plan is to create a new set of API calls and hooks that
> allow to register additional wire protocols. The existing backend libpq
> implementation will be modified to register
On Wed, Feb 10, 2021 at 9:52 AM Dilip Kumar wrote:
> [ new patches ]
I think that in both varattrib_4b and toast_internals.h it would be
better to pick a less generic field name. In toast_internals.h it's
just info; in postgres.h it's va_info. But:
[rhaas pgsql]$ git grep info | wc -l
24552
On Sat, Feb 06, 2021 at 08:45:49AM -0600, Justin Pryzby wrote:
> On Mon, Jan 18, 2021 at 12:34:59PM -0600, Justin Pryzby wrote:
> > On Sat, Nov 28, 2020 at 08:03:02PM -0600, Justin Pryzby wrote:
> > > On Sun, Nov 15, 2020 at 07:53:35PM -0600, Justin Pryzby wrote:
> > > > On Wed, Nov 04, 2020 at
On Wed, Feb 10, 2021 at 2:04 PM Tom Lane wrote:
> That is a spot-on definition of where I do NOT want to end up. Hooks
> everywhere and enormous extensions that break anytime we change anything
> in the core. It's not really clear that anybody is going to find that
> more maintainable than a
"Jonah H. Harris" writes:
> On Wed, Feb 10, 2021 at 1:10 PM Tom Lane wrote:
>> ... If we start having
>> modes for MySQL identifier quoting, Oracle outer join syntax, yadda
>> yadda, it's going to be way more of a maintenance nightmare than some
>> hook functions. So if we accept any patch
On Wed, Feb 10, 2021 at 1:10 PM Tom Lane wrote:
> What I'm actually more concerned about, in this whole line of development,
> is the follow-on requests that will surely occur to kluge up Postgres
> to make its behavior more like $whatever. As in "well, now that we
> can serve MySQL clients
Hi Mark,
On Mon, Feb 8, 2021, at 09:40, Mark Rofail wrote:
>Attachments:
>fk_arrays_elem_v1.patch
>anyarray_anyelement_operators-v1.patch
Nice work!
I have successfully tested both patches against
e7f42914854926c2afbb89b9cd0e381fd90766be
by cloning all pg_catalog tables, and adding foreign
On 10/02/2021 16:25, Magnus Hagander wrote:
On Tue, Feb 9, 2021 at 9:54 AM Heikki Linnakangas wrote:
(I may have said this before, but) My overall high-level impression of
this patch is that it's really cmmplex for a feature that you use maybe
once in the lifetime of a cluster. I'm happy to
On Wed, Feb 10, 2021 at 03:25:58PM +0100, Magnus Hagander wrote:
> On Tue, Feb 9, 2021 at 9:54 AM Heikki Linnakangas wrote:
> >
> > (I may have said this before, but) My overall high-level impression of
> > this patch is that it's really cmmplex for a feature that you use maybe
> > once in the
Robert Haas writes:
> If we're going to end up with an open source implementation of
> something useful in contrib or whatever, then I think this is fine.
> But, if not, then we're just making it easier for Amazon to do
> proprietary stuff without getting any benefit for the open-source
>
On Wed, Feb 10, 2021 at 11:43 AM Robert Haas wrote:
> On Mon, Jan 25, 2021 at 10:07 AM Jan Wieck wrote:
> > Our current plan is to create a new set of API calls and hooks that
> allow to register additional wire protocols. The existing backend libpq
> implementation will be modified to register
That's because using the foreign server is difficult for the user.
For example, the user doesn't always have the permission to login to
the forein server.
In some cases, the foreign table has been created by the administrator that
has permission to access the two servers and the user only uses
On Wed, Feb 10, 2021 at 1:43 PM Robert Haas wrote:
>
> On Mon, Jan 25, 2021 at 10:07 AM Jan Wieck wrote:
> > Our current plan is to create a new set of API calls and hooks that
allow to register additional wire protocols. The existing backend libpq
implementation will be modified to register
On Mon, Jan 25, 2021 at 10:07 AM Jan Wieck wrote:
> Our current plan is to create a new set of API calls and hooks that allow to
> register additional wire protocols. The existing backend libpq implementation
> will be modified to register itself using the new API. This will serve as a
> proof
On Wed, Feb 10, 2021 at 4:36 PM Michael Banck wrote:
>
> Hi,
>
> On Wed, Feb 10, 2021 at 10:15:12AM -0500, Jonathan S. Katz wrote:
> > Please see updated draft.
>
> What about the CVEs, it's my understanding that two security issues have
> been fixed; shouldn't they be mentioned as well? Or are
On 2/10/21 10:19 AM, Chapman Flack wrote:
> On 02/10/21 10:15, Jonathan S. Katz wrote:
>> On 2/8/21 6:11 PM, Noah Misch wrote:
>>> On Mon, Feb 08, 2021 at 05:40:41PM -0500, Jonathan S. Katz wrote:
Some of these issues only affect version 13, but may also apply to other
supported
Hi,
On Wed, Feb 10, 2021 at 10:15:12AM -0500, Jonathan S. Katz wrote:
> Please see updated draft.
What about the CVEs, it's my understanding that two security issues have
been fixed; shouldn't they be mentioned as well? Or are those scheduled
to be merged into the announcement at the last
On 02/10/21 10:15, Jonathan S. Katz wrote:
> On 2/8/21 6:11 PM, Noah Misch wrote:
>> On Mon, Feb 08, 2021 at 05:40:41PM -0500, Jonathan S. Katz wrote:
>>> Some of these issues only affect version 13, but may also apply to other
>>> supported versions.
>>
>> Did you want s/may/many/?
>
> Nope. The
On 2/8/21 6:11 PM, Noah Misch wrote:
> On Mon, Feb 08, 2021 at 05:40:41PM -0500, Jonathan S. Katz wrote:
>> This update also fixes over 80 bugs that were reported in the last several
>> months. Some of these issues only affect version 13, but may also apply to
>> other
>> supported versions.
>
>
On 2/8/21 11:30 PM, e...@xs4all.nl wrote:
>> On 02/08/2021 11:40 PM Jonathan S. Katz wrote:
>>
>>
>> Hi,
>>
>> Attached is a draft of the release announcement for the upcoming
>> 2021-02-11 cumulative update release. Please review for technical
>
> 'closes fixes' maybe better is:
> 'includes
On Wed, Feb 10, 2021 at 10:02 AM Dilip Kumar wrote:
>
> I don't find any problem with this approach as well, but I personally
> feel that the other approach where we don't wait in any API and just
> return the recovery pause state is much simpler and more flexible. So
> I will make the pending
On Tue, Feb 9, 2021 at 9:32 PM Amit Kapila wrote:
> If by successfully confirmed, you mean that once the subscriber node
> has received, it won't be sent again then as far as I know that is not
> true. We rely on the flush location sent by the subscriber to advance
> the decoding locations. We
On Tue, Feb 9, 2021 at 9:54 AM Heikki Linnakangas wrote:
>
> (I may have said this before, but) My overall high-level impression of
> this patch is that it's really cmmplex for a feature that you use maybe
> once in the lifetime of a cluster. I'm happy to review but I'm not
> planning to commit
On Fri, Feb 5, 2021 at 6:51 PM japin wrote:
> On Fri, 05 Feb 2021 at 17:50, Bharath Rupireddy
> wrote:
> We will get cell == NULL when we iterate all items in publist. I use it
> to check whether the dropped publication is in publist or not.
>
> > If you
> > have a strong reasong retain this
On Wed, Feb 10, 2021 at 3:59 PM Peter Smith wrote:
>
> PSA the new patch set v38*.
>
> This patch set has been rebased to use the most recent tablesync patch
> from other thread [1]
> (i.e. notice that v38-0001 is an exact copy of that thread's tablesync
> patch v31)
>
I see one problem which
Hi
Is there some reason why \copy statement (parse_slash_copy parser) doesn't
support psql variables?
Regards
Pavel
On Wed, Feb 10, 2021 at 7:31 PM Etsuro Fujita wrote:
> Attached is an updated version of the patch. Sorry for the delay.
I noticed that I forgot to add new files. :-(. Please find attached
an updated patch.
Best regards,
Etsuro Fujita
async-wip-2021-02-10-v2.patch
Description: Binary data
> On 10 Feb 2021, at 08:23, Michael Paquier wrote:
>
> On Tue, Feb 09, 2021 at 10:30:52AM +0100, Daniel Gustafsson wrote:
>> It can be, it's not the most pressing patch scope reduction but everything
>> helps of course.
>
> Okay. I have spent some time on this one and finished it.
Thanks,
Em qua., 10 de fev. de 2021 às 01:44, Kyotaro Horiguchi <
horikyota@gmail.com> escreveu:
> At Tue, 9 Feb 2021 22:01:45 -0300, Ranier Vilela
> wrote in
> > Hi Hackers,
> >
> > Per Coverity.
> >
> > Coverity complaints about pg_cryptohash_final function.
> > And I agree with Coverity, it's a
On Wed, Feb 10, 2021 at 4:43 PM Joel Jacobson wrote:
>
> Hi,
>
> I need to filter out any system catalog objects from SQL,
> and I've learned it's not possible to simply filter based on namespace name,
> since there are objects such as pg_am that don't have any namespace belonging,
> except
> > > It did have performance gain, but I think it's not huge enough to
> > > ignore the extra's index cost.
> > > What do you think ?
> >
> > Yes... as you suspect, I'm afraid the benefit from parallel bitmap
> > scan may not compensate for the loss of the parallel insert operation.
> >
> > The
On Thu, Feb 4, 2021 at 7:21 PM Etsuro Fujita wrote:
> On Mon, Feb 1, 2021 at 12:06 PM Etsuro Fujita wrote:
> > Rather than doing so, I'd like to propose to allow
> > FDWs to disable async execution of them in problematic cases by
> > themselves during executor startup in the first cut. What I
> What are the results if disable the bitmap heap scan(Set enable_bitmapscan
> = off)? If that happens to be true, then we might also want to consider
> if in some way we can teach parallel insert to cost more in such cases.
> Another thing we can try is to integrate a parallel-insert patch with
On Wed, Feb 10, 2021 at 10:53 AM Peter Geoghegan wrote:
>
> On Tue, Feb 9, 2021 at 2:14 PM Peter Geoghegan wrote:
> > The first patch teaches nbtree to use 64-bit transaction IDs here, and
> > so makes it impossible to leak deleted nbtree pages. This patch is the
> > nbtree equivalent of commit
On Wed, Feb 10, 2021 at 5:50 PM Amit Langote wrote:
> On Wed, Feb 10, 2021 at 5:24 PM Amit Kapila wrote:
> > On Wed, Feb 10, 2021 at 1:00 PM Amit Langote
> > wrote:
> > > On Wed, Feb 10, 2021 at 1:35 PM Greg Nancarrow
> > > wrote:
> > > > It's parallel UNSAFE because it's not safe or even
On Wed, Feb 10, 2021 at 1:40 PM Markus Wanner
wrote:
>
> On 10.02.21 07:32, Amit Kapila wrote:
> > On Wed, Feb 10, 2021 at 11:45 AM Ajin Cherian wrote:
> >> But the other side of the problem is that ,without this, if the
> >> prepared transaction is prior to a consistent snapshot when decoding
>
On Wed, Feb 10, 2021 at 5:52 PM tsunakawa.ta...@fujitsu.com
wrote:
> From: Amit Langote
> > Just to be clear, I'm not suggesting that we should put effort into
> > making INSERT ... VALUES run in parallel. I'm just raising my concern
> > about embedding the assumption in max_parallel_hazard()
> > >
> > > else if (IsA(node, Query))
> > > {
> > > Query *query = (Query *) node;
> > >
> > > /* SELECT FOR UPDATE/SHARE must be treated as unsafe */
> > > if (query->rowMarks != NULL)
> > > {
> > > context->max_hazard =
Hi John,
I never build postgresql from source, so I must get some information on how
to apply your patch and do some test. I can't review your code because I
know nothing about Postgresql internals and just basic C. I am mainly a
PL/SQL programmer, with experience with PHP, Python and Javascript.
Hi
My company is looking for a team of developers to implement the
"flashback database" functionality in PostgreSQL.
Do you think it's feasible to implement? how many days of
development?
Thanks in advance
Best Regards
Didier ROS
E.D.F
Ce message
From: Amit Langote
> Just to be clear, I'm not suggesting that we should put effort into
> making INSERT ... VALUES run in parallel. I'm just raising my concern
> about embedding the assumption in max_parallel_hazard() that it will
> never make sense to do so.
I'm sorry I misunderstood your
On Wed, Feb 10, 2021 at 5:24 PM Amit Kapila wrote:
> On Wed, Feb 10, 2021 at 1:00 PM Amit Langote wrote:
> > On Wed, Feb 10, 2021 at 1:35 PM Greg Nancarrow wrote:
> > > It's parallel UNSAFE because it's not safe or even possible to have a
> > > parallel plan for this.
> > > (as UNSAFE is the
On Wed, Feb 10, 2021 at 11:13 AM tsunakawa.ta...@fujitsu.com
wrote:
>
>
> The loss is probably due to 1) more index page splits, 2) more buffer writes
> (table and index), and 3) internal locks for things such as relation
> extension and page content protection. To investigate 3), we should
On Thu, Feb 4, 2021 at 1:40 PM Tomas Vondra
wrote:
> With master, it'd take ~16000 seconds to catch up. I don't have the
> exact number, because I got tired of waiting, but the estimate is likely
> accurate (judging by other tests and how regular the progress is).
>
> With WAL prefetching enabled
On Wed, Feb 10, 2021 at 1:00 PM Amit Langote wrote:
>
> On Wed, Feb 10, 2021 at 1:35 PM Greg Nancarrow wrote:
> > On Wed, Feb 10, 2021 at 2:39 PM Amit Langote
> > wrote:
> > >
> > > > The code check that you have identified above ensures that the INSERT
> > > > has an underlying SELECT,
On Wed, Feb 10, 2021 at 5:03 PM tsunakawa.ta...@fujitsu.com
wrote:
> From: Amit Langote
> > On Wed, Feb 10, 2021 at 1:35 PM Greg Nancarrow
> > wrote:
> > > There's no "second-guessing" involved here.
> > > There is no underlying way of dividing up the VALUES data of
> > > "INSERT...VALUES"
On 10.02.21 07:32, Amit Kapila wrote:
On Wed, Feb 10, 2021 at 11:45 AM Ajin Cherian wrote:
But the other side of the problem is that ,without this, if the
prepared transaction is prior to a consistent snapshot when decoding
starts/restarts, then only the "commit prepared" is sent to downstream
Hi,
Am Mittwoch, den 10.02.2021, 15:06 +0900 schrieb Michael Paquier:
> On Tue, Feb 09, 2021 at 10:54:50AM +0200, Heikki Linnakangas wrote:
> > (I may have said this before, but) My overall high-level impression of this
> > patch is that it's really cmmplex for a feature that you use maybe once
On Wed, Feb 10, 2021 at 12:58:05AM -0600, Justin Pryzby wrote:
> If I'm not wrong, you meant to ORDER BY attrelid::regclass::text, attnum;
Indeed, I meant that. Thanks, Justin!
--
Michael
signature.asc
Description: PGP signature
From: Amit Langote
> On Wed, Feb 10, 2021 at 1:35 PM Greg Nancarrow
> wrote:
> > There's no "second-guessing" involved here.
> > There is no underlying way of dividing up the VALUES data of
> > "INSERT...VALUES" amongst the parallel workers, even if the planner
> > was updated to produce a
71 matches
Mail list logo
