On Sat, Apr 3, 2021 at 1:29 AM Peter Eisentraut
wrote:
> The code you have in merge_publications() to report all existing
> publications is pretty messy and is not properly internationalized. I
> think what you are trying to do there is excessive. Compare this
> similar case:
>
> create table
On Fri, Apr 2, 2021, at 22:59, Chapman Flack wrote:
> Slonik's backslashes are falling off. Eww.
>
> Regards,
> -Chap
Thanks for the bug report.
Fixed by properly escaping backslackes:
ALTER SYSTEM SET motd TO E'\u001B[94m'
'\n __ ___ '
'\n /)/ \\/ \\ '
'\n ( / __
On Sat, Apr 3, 2021, at 04:47, Michael Paquier wrote:
> On Fri, Apr 02, 2021 at 10:46:16PM +0200, Joel Jacobson wrote:
> > Ascii elephant in example by Michael Paquier [1], with ANSI colors added by
> > me.
> >
> > [1]
> >
On Fri, Apr 2, 2021, at 22:51, Bruce Momjian wrote:
> On Fri, Apr 2, 2021 at 10:46:16PM +0200, Joel Jacobson wrote:
> > Dear fellow hackers,
> >
> > This patch is one day late, my apologies for missing the deadline this year.
>
> Uh, the deadline for the last commitfest was March 1, 2021, not
Hi,
On 2021-03-16 12:54:40 -0700, Andres Freund wrote:
> I did consider command_progress.c too - but that seems confusing because
> there's src/include/commands/progress.h, which is imo a different layer
> than what pgstat/backend_progress provide. So I thought splitting things
> up so that
On Fri, Apr 02, 2021 at 02:25:15PM +0200, Peter Eisentraut wrote:
>
> New patch attached.
Thanks, it all looks good to me. I just spot a few minor formatting issues:
@@ -2968,6 +2973,13 @@ pg_get_functiondef(PG_FUNCTION_ARGS)
}
/* And finally the function definition ... */
+ tmp =
On Fri, Apr 2, 2021 at 07:53:35PM -0700, Zhihong Yu wrote:
> Bruce:
> In src/interfaces/ecpg/pgtypeslib/interval.c, how about the following places ?
>
> Around line 158:
> case 'Y':
> tm->tm_year += val;
> tm->tm_mon += (fval *
Hi,
On 2021-04-02 12:44:58 -0700, Andres Freund wrote:
> If we went for the my_wait_event_info approach there is one further
> advantage, after my change to move the wait event code into a separate
> file: wait_event.h does not need to include proc.h anymore, which seems
> architecturally nice
Bruce:
In src/interfaces/ecpg/pgtypeslib/interval.c, how about the following
places ?
Around line 158:
case 'Y':
tm->tm_year += val;
tm->tm_mon += (fval * MONTHS_PER_YEAR);
Around line 194:
tm->tm_year += val;
On Fri, Apr 02, 2021 at 10:46:16PM +0200, Joel Jacobson wrote:
> Ascii elephant in example by Michael Paquier [1], with ANSI colors added by
> me.
>
> [1]
> https://www.postgresql.org/message-id/CAB7nPqRaacwcaANOYY3Hxd3T0No5RdZXyqM5HB6fta%2BCoDLOEg%40mail.gmail.com
The credit here goes to
On Fri, Apr 2, 2021 at 07:06:08PM -0700, Zhihong Yu wrote:
> Hi,
> The mix of interval and comparison with float is not easy to interpret. See
> the
> following (I got 0.0833 since the result for interval '0.3 years' + interval
> '0.4 years' - ... query was 1 month and 1/12 ~= 0.0833).
>
>
On Fri, Apr 2, 2021 at 06:11:08PM -0700, Zhihong Yu wrote:
> Hi,
> I got a local build with second patch where:
>
> yugabyte=# SELECT interval '0.3 years' + interval '0.4 years' -
> interval '0.7 years';
> ?column?
> --
> 1 mon
>
> I think the outcome is a bit
I wrote:
> Also, both the code and docs thought that the "reconstructedValue"
> datums that are passed down the tree during a search should be of
> the leaf data type. This seems to me to be arrant nonsense.
> As an example, if you made an opclass that indexes 1-D arrays
> by labeling each inner
Hi,
The mix of interval and comparison with float is not easy to interpret. See
the following (I got 0.0833 since the result for interval '0.3 years' +
interval '0.4 years' - ... query was 1 month and 1/12 ~= 0.0833).
yugabyte=# select 0.3 * '1 year'::interval + 0.4 * '1 year'::interval - 0.7
*
On Fri, Apr 2, 2021 at 1:59 PM Fujii Masao wrote:
>
>
>
> On 2021/04/02 11:20, vignesh C wrote:
> > On Thu, Apr 1, 2021 at 11:18 PM Fujii Masao
> > wrote:
> >>
> >>
> >>
> >> On 2021/04/02 2:18, Jeevan Ladhe wrote:
> >>>
> >>>
> >>> On Thu, Apr 1, 2021 at 10:20 PM vignesh C >>>
> I was unclear. What I meant was that your patch isn't just useful
> because it speeds up "pgbench -i" for everybody. It's also useful
> because having all of the tuples already frozen after bulk loading
> seems like a good benchmarking practice, at least most of the time.
>
> The patch changes
On Fri, 2 Apr 2021 at 21:08, Zhihong Yu wrote:
> Hi,
> I got a local build with second patch where:
>
> yugabyte=# SELECT interval '0.3 years' + interval '0.4 years' -
> interval '0.7 years';
> ?column?
> --
> 1 mon
>
> I think the outcome is a bit unintuitive (I would
Hi,
I got a local build with second patch where:
yugabyte=# SELECT interval '0.3 years' + interval '0.4 years' -
interval '0.7 years';
?column?
--
1 mon
I think the outcome is a bit unintuitive (I would expect result close to 0).
Cheers
On Fri, Apr 2, 2021 at 5:07 PM
On Fri, Apr 2, 2021 at 4:58 PM Tatsuo Ishii wrote:
> I am not sure how many people use this kind of options while running
> pgbench -i but we could add yet another switch to fall back to none
> FREEZE COPY if you want.
I was unclear. What I meant was that your patch isn't just useful
because it
On Fri, Apr 2, 2021 at 05:50:59PM -0700, Bryn Llewellyn wrote:
> are the user’s parameterization. All are real numbers. Because non-integral
> values for years, months, days, hours, and minutes are allowed when you
> specify
> a value using the ::interval typecast, my reference doc must state
All,
Thank you for discussion.
I've updated the patch (v6->v7) according to the conclusion.
I'll show the modified points:
1. Comments for ExecuteTuncate()
2. Replacing extra value in frels_extra with integer to label.
3. Skipping XLOG_HEAP_TRUNCATE on foreign table
Regards,
2021年4月2日(金) 11:44
br...@momjian.us wrote:
> I have just posted a new version of the patch which I think covers all the
> right areas.
I found the relevant email from you to pgsql-hackers here:
https://www.postgresql.org/message-id/20210402234732.GA29125%40momjian.us
You said:
> I have modified the patch to
On Fri, Apr 2, 2021 at 07:47:32PM -0400, Bruce Momjian wrote:
> I have modified the patch to prevent partial months from creating
> partial hours/minutes/seconds, so the output is now at least consistent
> based on the three units:
>
> SELECT ('6.54321 years'::interval)::text as i;
>
Hi,
bq. My new code returns 0.2 months for this, not zero
Can you clarify (the output below that was 2 mons, not 0.2) ?
Thanks
On Fri, Apr 2, 2021 at 4:58 PM Bruce Momjian wrote:
> On Fri, Apr 2, 2021 at 02:00:03PM -0700, John W Higgins wrote:
> > On Fri, Apr 2, 2021 at 11:05 AM Bruce
> Most of the time when I run pgbench I use my own shell script, which does
> this:
>
> PGOPTIONS='-c vacuum_freeze_min_age=0 -c wal_compression=off' pgbench
> -i -s $SCALE
>
> Have you considered this case? In other words, have you considered the
> benefits of this patch for users that
On Fri, Apr 2, 2021 at 02:00:03PM -0700, John W Higgins wrote:
> On Fri, Apr 2, 2021 at 11:05 AM Bruce Momjian wrote:
> While maybe there is an argument to fixing the negative/positive rounding
> issue
> - there is no way this gets solved without breaking the current implementation
>
> select
On Thu, Apr 1, 2021, at 7:19 AM, Amit Kapila wrote:
> Your ideas/suggestions look good to me. Don't we need to provide a
> read function corresponding to logicalrep_write_message? We have it
> for other write functions. Can you please combine all of your changes
> into one patch?
Thanks for taking
On Fri, Apr 2, 2021 at 01:27:33PM -0700, Zhihong Yu wrote:
> Bruce:
> Thanks for tackling this issue.
>
> The patch looks good to me.
> When you have time, can you include the places which were not covered by the
> current diff ?
I have just posted a new version of the patch which I think
On Fri, Apr 2, 2021 at 01:05:42PM -0700, Bryn Llewellyn wrote:
> I should come clean about the larger context. I work for Yugabyte, Inc. We
> have
> a distributed SQL database that uses the Version 11.2 PostgreSQL C code for
> SQL
> processing “as is”.
>
> https://blog.yugabyte.com/
>
Peter Geoghegan writes:
> On Fri, Apr 2, 2021 at 9:37 AM Tom Lane wrote:
>> I propose changing things so that
>> (A) attType really is the input (heap) data type.
>> (B) We enforce that leafType agrees with the opclass opckeytype,
>> ensuring the index tupdesc can be used for leaf tuples.
>> (C)
Alvaro Herrera writes:
> On 2021-Apr-02, Tom Lane wrote:
>> +1, but the comment could be more specific. Maybe like "In regress mode,
>> suppress the length of ErrorResponse and NoticeResponse messages --- the F
>> (file name) field, in particular, can vary in length depending on compiler
>>
On 2021-Apr-02, Tom Lane wrote:
> Alvaro Herrera writes:
> > As in the attached patch.
>
> +1, but the comment could be more specific. Maybe like "In regress mode,
> suppress the length of ErrorResponse and NoticeResponse messages --- the F
> (file name) field, in particular, can vary in
On Sun, Mar 21, 2021 at 5:23 PM Tatsuo Ishii wrote:
> Anyway, this time total pgbench time is reduced by 14% over all
> here. I hope people agree that the patch is worth the gain.
Most of the time when I run pgbench I use my own shell script, which does this:
PGOPTIONS='-c
On Fri, Apr 2, 2021 at 10:46:16PM +0200, Joel Jacobson wrote:
> Dear fellow hackers,
>
> This patch is one day late, my apologies for missing the deadline this year.
Uh, the deadline for the last commitfest was March 1, 2021, not April
1.
--
Bruce Momjian https://momjian.us
EDB
My goal is to use RLS for everything, including SELECTs, so it's super
important to consider every performance tweak possible. Appreciate any
insights or comments. I'm also hoping to document this better for
application developers who want to use postgres and RLS.
Does anyone know details of, or
Hi Joel
On Fri, Apr 2, 2021 at 11:47 PM Joel Jacobson wrote:
> PostgreSQL has since long been suffering from the lack of a proper UNIX
> style motd (message of the day).
>
First of all, thanks for your work on this! I think this is an important
feature to have, but I would love to see a way
On 3/30/21 3:08 PM, Joel Jacobson wrote:
> Hi,
>
> Some catalog oid values originate from other catalogs,
> such as pg_aggregate.aggfnoid -> pg_proc.oid
> or pg_attribute.attrelid -> pg_class.oid.
>
> For such oid values, the foreign catalog is the regclass
> which should be passed as the first
On Fri, Apr 2, 2021 at 11:05 AM Bruce Momjian wrote:
> On Thu, Apr 1, 2021 at 09:46:58PM -0700, Bryn Llewellyn wrote:
> > Or am I misunderstanding something?
> >
> > Try this. The result of each “select” is shown as the trailing comment
> on the
> > same line. I added whitespace by hand to line
On 04/02/21 16:46, Joel Jacobson wrote:
> __ ___
> /)/ /
> ( / ___)
> (/ o) ( o) )
>_ (_ )) /
>/_/)_/
> / //| |\
> v | | v
> __/
Slonik's backslashes are falling off. Eww.
Regards,
-Chap
Dear fellow hackers,
This patch is one day late, my apologies for missing the deadline this year.
PostgreSQL has since long been suffering from the lack of a proper UNIX style
motd (message of the day).
DBAs have no ways of conveying important information to users,
having to rely on external
Hi,
On 2021-04-02 13:42:42 -0700, Zhihong Yu wrote:
> I don't see where my_wait_event_info is read (there is no getter method in
> the patch).
There are no reads via my_wait_event_info. Once connected to shared
memory, InitProcess() calls pgstat_set_wait_event_storage() to point it
to
Hi,
Maybe I am not familiar with your patch.
I don't see where my_wait_event_info is read (there is no getter method in
the patch).
In that case, it is fine omitting volatile in the declaration.
Cheers
On Fri, Apr 2, 2021 at 1:10 PM Andres Freund wrote:
> Hi,
>
> On 2021-04-02 13:06:35
On Fri, Apr 2, 2021 at 6:18 PM tsunakawa.ta...@fujitsu.com
wrote:
> The patch looks committable to me.
I checked for performance impact compared to master with pgbench -S,
and didn't see any problem. I thought more about how to write a
decent race-free test but struggled with the lack of a good
Bruce:
Thanks for tackling this issue.
The patch looks good to me.
When you have time, can you include the places which were not covered by
the current diff ?
Cheers
On Fri, Apr 2, 2021 at 11:06 AM Bruce Momjian wrote:
> On Thu, Apr 1, 2021 at 09:46:58PM -0700, Bryn Llewellyn wrote:
> > Or
Hi,
On 2021-04-02 13:06:35 -0700, Zhihong Yu wrote:
> +extern PGDLLIMPORT uint32 *my_wait_event_info;
>
> It seems volatile should be added to the above declaration. Since later:
>
> + *(volatile uint32 *) my_wait_event_info = wait_event_info;
Why? We really just want to make the store
Hi,
+extern PGDLLIMPORT uint32 *my_wait_event_info;
It seems volatile should be added to the above declaration. Since later:
+ *(volatile uint32 *) my_wait_event_info = wait_event_info;
Cheers
On Fri, Apr 2, 2021 at 12:45 PM Andres Freund wrote:
> Hi,
>
> This grew out of my patch to
@cfbot: rebased
>From 686cd8fc644f1f86d81d7748b66feddd634c4dc8 Mon Sep 17 00:00:00 2001
From: Justin Pryzby
Date: Thu, 26 Nov 2020 14:37:08 -0600
Subject: [PATCH v10 1/8] pg_dump: make CLUSTER ON a separate dump object..
..since it needs to be restored after any child indexes are restored *and
On 23.03.21 16:08, Japin Li wrote:
I check the duplicates for newpublist in merge_publications(). The code is
copied from publicationListToArray().
I do not check for all duplicates because it will make the code more complex.
For example:
ALTER SUBSCRIPTION mysub ADD PUBLICATION mypub2,
Hi,
This grew out of my patch to split the waits event code out of
pgstat.[ch], which in turn grew out of the shared memory stats patch
series.
pgstat_report_wait_start() and pgstat_report_wait_end() currently check
pgstat_track_activities before assigning to MyProc->wait_event_info.
Given the
Hi,
For v6-0003-Parallel-Hash-Full-Right-Outer-Join.patch
+* current_chunk_idx: index in current HashMemoryChunk
The above comment seems to be better fit
for ExecScanHashTableForUnmatched(), instead
of ExecParallelPrepHashTableForUnmatched.
I wonder where current_chunk_idx should belong
On Fri, 2021-04-02 at 13:45 +0900, Michael Paquier wrote:
> Attached is what I have come up with as the first building piece,
> which is basically a combination of 0001 and 0002, except that I
> modified things so as the number of arguments remains minimal for all
> the routines. This avoids the
On 4/2/21 3:43 AM, Michael Paquier wrote:
On Thu, Apr 01, 2021 at 09:56:02AM +0900, Michael Paquier wrote:
Okay, that sounds good to me.
Applied and backpatched then as 6fb66c26 & co.
Thank you!
--
-David
da...@pgmasters.net
On Thu, Apr 1, 2021 at 09:46:58PM -0700, Bryn Llewellyn wrote:
> Or am I misunderstanding something?
>
> Try this. The result of each “select” is shown as the trailing comment on the
> same line. I added whitespace by hand to line up the fields.
>
> select interval '-1.7 years';
On 4/2/21, 10:54 AM, "Joe Conway" wrote:
> On 4/2/21 10:21 AM, Laurenz Albe wrote:
>> So I think that documenting this is the way to go. I'll mark it as
>> "ready for committer".
>
> pushed
Thanks!
Nathan
Hi,
attached a patch with some cleanup and a couple of test cases. The lookup is
now done with the parentid and the renaming affects detached partitions as well.
The test cases are not perfectly concise, but only add about 0.4 % to the total
runtime of regression tests at my machine. So I
On 4/2/21 10:21 AM, Laurenz Albe wrote:
On Mon, 2021-03-15 at 17:09 +, Bossart, Nathan wrote:
On 3/15/21, 7:06 AM, "Laurenz Albe" wrote:
> On Fri, 2021-03-12 at 21:41 +, Bossart, Nathan wrote:
> > On 3/12/21, 11:14 AM, "Joe Conway" wrote:
> > > Looking back at the commit history it
On Fri, Apr 2, 2021 at 1:02 PM Andres Freund wrote:
>
> Hi,
>
> On 2021-04-02 10:18:20 -0400, Mike Palmiotto wrote:
> > I can't really speak to the initial points directly relating to
> > pgstat/shmem, but for the overall maze-like nature of the startup
> > code: is there any chance the startup
On Fri, Mar 5, 2021 at 8:31 PM Thomas Munro wrote:
>
> On Tue, Mar 2, 2021 at 11:27 PM Thomas Munro wrote:
> > On Fri, Feb 12, 2021 at 11:02 AM Melanie Plageman
> > wrote:
> > > I just attached the diff.
> >
> > Squashed into one patch for the cfbot to chew on, with a few minor
> > adjustments
Hi,
On 2021-04-02 15:34:54 +0900, Kyotaro Horiguchi wrote:
> At Thu, 1 Apr 2021 19:44:25 -0700, Andres Freund wrote
> in
> > Hi,
> >
> > I spent quite a bit more time working on the patch. There's are large
> > changes:
> >
> > - postmaster/pgstats.c (which is an incorrect location now that
On Thu, Apr 1, 2021 at 4:47 PM Heikki Linnakangas wrote:
> Ok, I wouldn't expect to see much difference in that test, it gets
> drowned in all the other parsing overhead. I tested this now with this:
>
> copy (select repeat('x', 1) from generate_series(1, 10)) to
> '/tmp/copydata-x.txt'
>
Hi,
On 2021-04-02 10:18:20 -0400, Mike Palmiotto wrote:
> I can't really speak to the initial points directly relating to
> pgstat/shmem, but for the overall maze-like nature of the startup
> code: is there any chance the startup centralization patchset would be
> of any help here?
>
On Fri, Apr 2, 2021 at 9:37 AM Tom Lane wrote:
> I propose changing things so that
>
> (A) attType really is the input (heap) data type.
>
> (B) We enforce that leafType agrees with the opclass opckeytype,
> ensuring the index tupdesc can be used for leaf tuples.
>
> (C) The tupdesc passed back
While reviewing Pavel Borisov's patch to enable INCLUDE columns in
SP-GiST, I found some things that seem like pre-existing bugs.
These only accidentally fail to cause any problems in the existing
SP-GiST opclasses:
1. The attType passed to an opclass's config method is documented as
Oid
Sorry for another late reply, finally found some time to formulate couple of
thoughts.
> On Thu, Feb 25, 2021 at 09:22:43AM +0100, Dmitry Dolgov wrote:
> > On Wed, Feb 24, 2021 at 01:45:10PM -0800, Andres Freund wrote:
> >
> > > I'm curious if it makes sense
> > > to explore possibility to have
On 2021/04/02 18:19, shinya11.k...@nttdata.com wrote:
Thanks for your review!
I updated the patch, and attached it.
Thanks for updating the patch! Pushed.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
On 2021-Apr-02, Tom Lane wrote:
> On third thought, maybe we should push your patch too. Although I think
> 53aafdb9f is going to fix the platform-specific aspect of this, we are
> still going to risk some implementation dependence of the libpq_pipeline
> results:
>
> * Every so often, the
On 2021-Apr-02, Amit Langote wrote:
> On Sat, Mar 20, 2021 at 10:21 PM Amit Langote wrote:
> > Updated patches attached. Sorry about the delay.
>
> Rebased over the recent DETACH PARTITION CONCURRENTLY work.
> Apparently, ri_ReferencedKeyExists() was using the wrong snapshot.
Hmm, I wonder if
I wrote:
>> I bet what is happening on drongo is that the compiler has generated a
>> __FILE__ value that contains backslashes not slashes, and this code
>> doesn't know how to shorten those. So maybe instead of lobotomizing
>> this test, we should fix that.
> Did that, but we'll have to wait a
Hi,
+ skip = !ExecLockTableTuple(erm->relation, , markSlot,
+ estate->es_snapshot,
estate->es_output_cid,
+ lockmode, erm->waitPolicy, _needed);
+ if (skip)
It seems the variable skip is only used above. The variable
On 2021-Apr-02, Tom Lane wrote:
> I wrote:
> > I bet what is happening on drongo is that the compiler has generated a
> > __FILE__ value that contains backslashes not slashes, and this code
> > doesn't know how to shorten those. So maybe instead of lobotomizing
> > this test, we should fix that.
On Thu, 2021-04-01 at 17:25 +0900, Fujii Masao wrote:
> Thanks for updating the patch!
>
> +errhint("Use a backup taken after setting
> wal_level to higher than minimal "
> +"or recover to the point in
> time before
On 4/2/21 10:23 AM, Stephen Frost wrote:
Greetings,
* Joe Conway (m...@joeconway.com) wrote:
On 4/2/21 9:57 AM, Isaac Morland wrote:
>Views already run security definer, allowing them to be used for some of
>the same information-hiding purposes as RLS. But I just found something
>strange:
I wrote:
> I bet what is happening on drongo is that the compiler has generated a
> __FILE__ value that contains backslashes not slashes, and this code
> doesn't know how to shorten those. So maybe instead of lobotomizing
> this test, we should fix that.
Did that, but we'll have to wait a few
On Wed, 2021-03-24 at 14:14 +1300, David Rowley wrote:
> On Fri, 19 Mar 2021 at 02:07, Amit Langote wrote:
> > Attached a new version rebased over c8f78b616, with the grouping
> > relation partitioning enhancements as a separate patch 0001. Sorry
> > about the delay.
>
> I had a quick look at
Greetings,
* Joe Conway (m...@joeconway.com) wrote:
> On 4/2/21 9:57 AM, Isaac Morland wrote:
> >Views already run security definer, allowing them to be used for some of
> >the same information-hiding purposes as RLS. But I just found something
> >strange: current_user/_role returns the user's
On Mon, 2021-03-15 at 17:09 +, Bossart, Nathan wrote:
> On 3/15/21, 7:06 AM, "Laurenz Albe" wrote:
> > On Fri, 2021-03-12 at 21:41 +, Bossart, Nathan wrote:
> > > On 3/12/21, 11:14 AM, "Joe Conway" wrote:
> > > > Looking back at the commit history it seems to me that this only works
> >
On Thu, Apr 1, 2021 at 8:22 PM Andres Freund wrote:
>
> I have now worked around this by generous application of ugly, but I
> think we really need to do something about this mazy mess. There's just
> an insane amount of duplication, and it's too complicated to remember
> more than a few
On 4/2/21 9:57 AM, Isaac Morland wrote:
Views already run security definer, allowing them to be used for some of the
same information-hiding purposes as RLS. But I just found something strange:
current_user/_role returns the user's role, not the view owner's role:
postgres=# set role to t1;
On Fri, Apr 2, 2021 at 07:04:18PM +0900, Michael Paquier wrote:
> On Mon, Feb 15, 2021 at 08:25:27PM +0900, Michael Paquier wrote:
> > Again a new rebase, giving v5:
> > - Fixed the APIs to return -1 if the caller gives NULL in input, to be
> > consistent with cryptohash.
> > - Added a length
Alvaro Herrera writes:
> As in the attached patch.
+1, but the comment could be more specific. Maybe like "In regress mode,
suppress the length of ErrorResponse and NoticeResponse messages --- the F
(file name) field, in particular, can vary in length depending on compiler
used."
Actually
On Fri, 2 Apr 2021 at 09:44, Chapman Flack wrote:
> On 04/02/21 09:09, Isaac Morland wrote:
> > If we're going to do this we should do the same for triggers as well.
> >
> > ... it's easy to imagine a situation in which a trigger needs to
> > write to another table which should not be accessible
On Fri, 2 Apr 2021 at 09:30, Stephen Frost wrote:
> Greetings,
>
> * Isaac Morland (isaac.morl...@gmail.com) wrote:
> > On Fri, 2 Apr 2021 at 01:44, Dan Lynch wrote:
> > > RLS policies quals/checks are optimized inline, and so I generally
> avoid
> > > writing a separate procedure so the
On 2021-Apr-02, Alvaro Herrera wrote:
> On 2021-Apr-02, Kyotaro Horiguchi wrote:
>
> > At Fri, 02 Apr 2021 14:40:09 +0900 (JST), Kyotaro Horiguchi
> > wrote in
>
> > > So, the cheapest measure for regression test would be just making the
> >
> > So, the cheapest measure for regression test
On 04/02/21 09:09, Isaac Morland wrote:
> If we're going to do this we should do the same for triggers as well.
>
> ... it's easy to imagine a situation in which a trigger needs to
> write to another table which should not be accessible to the role using the
> table which has the trigger.
Hi, all
I want to know why call pgstat_reset_all function during recovery process,
under what circumstances the data will be invalid after recovery?
Thanks & Best Regard
Greetings,
* Isaac Morland (isaac.morl...@gmail.com) wrote:
> On Fri, 2 Apr 2021 at 01:44, Dan Lynch wrote:
> > RLS policies quals/checks are optimized inline, and so I generally avoid
> > writing a separate procedure so the optimizer can do it's thing.
> >
> > However, if you need a security
On Thu, Apr 1, 2021 at 10:56 AM Masahiko Sawada wrote:
> On Tue, Mar 23, 2021 at 6:27 PM Amit Langote wrote:
> > Actually, I found a big hole in my assumptions around deferrable
> > foreign constraints, invalidating the approach I took in 0002 to use a
> > query-lifetime tuplestore to record
On Fri, 2 Apr 2021 at 01:44, Dan Lynch wrote:
> RLS policies quals/checks are optimized inline, and so I generally avoid
> writing a separate procedure so the optimizer can do it's thing.
>
> However, if you need a security definer to avoid recursive RLS if you're
> doing a more complex query
On Sat, Mar 20, 2021 at 10:21 PM Amit Langote wrote:
> Updated patches attached. Sorry about the delay.
Rebased over the recent DETACH PARTITION CONCURRENTLY work.
Apparently, ri_ReferencedKeyExists() was using the wrong snapshot.
--
Amit Langote
EDB: http://www.enterprisedb.com
On 2021-Apr-02, Kyotaro Horiguchi wrote:
> At Fri, 02 Apr 2021 14:40:09 +0900 (JST), Kyotaro Horiguchi
> wrote in
> > So, the cheapest measure for regression test would be just making the
>
> So, the cheapest measure for regression test would be just *masking* the
>
> > length field, while
On 31.03.21 12:12, Julien Rouhaud wrote:
On Tue, Mar 23, 2021 at 11:28:55PM -0500, Jaime Casanova wrote:
On Fri, Mar 19, 2021 at 8:49 AM Peter Eisentraut
wrote:
Right. Here is a new patch with that fix added and a small conflict
resolved.
Great.
It seems print_function_sqlbody() is not
On Fri, Apr 2, 2021 at 4:23 AM SATYANARAYANA NARLAPURAM
wrote:
> Why pg_walfile_name() can't be executed under recovery?
I believe the issue is that the backend executing the function might
not have an accurate idea about which TLI to use. But I don't
understand why we can't find some solution
On 2021/04/02 2:22, Fujii Masao wrote:
Thanks a lot! Barring any objection, I will commit this version.
Pushed. Thanks!
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
On Mon, Feb 15, 2021 at 08:25:27PM +0900, Michael Paquier wrote:
> Again a new rebase, giving v5:
> - Fixed the APIs to return -1 if the caller gives NULL in input, to be
> consistent with cryptohash.
> - Added a length argument to pg_hmac_final(), wiht sanity checks.
So, this patch has been
On Fri, Apr 02, 2021 at 06:03:21PM +0900, Fujii Masao wrote:
> On 2021/04/02 16:47, Michael Paquier wrote:
>> I have not looked
>> in details and have not looked at the patch yet, though. Fujii-san,
>> are you planning to take care of that?
>
> Yes, I will. Thanks for the consideration!
OK,
pá 2. 4. 2021 v 11:37 odesílatel Laurenz Albe
napsal:
> On Fri, 2021-04-02 at 10:45 +0200, Pavel Stehule wrote:
> > I am checked an query from
> https://www.depesz.com/2021/04/01/waiting-for-postgresql-14-add-unistr-function/
> article.
> >
> > postgres=# SELECT U&'\+01F603';
> > ┌──┐
>
On Fri, 2021-04-02 at 10:45 +0200, Pavel Stehule wrote:
> I am checked an query from
> https://www.depesz.com/2021/04/01/waiting-for-postgresql-14-add-unistr-function/
> article.
>
> postgres=# SELECT U&'\+01F603';
> ┌──┐
> │ ?column? │
> ╞══╡
> │ │
> └──┘
> (1
>-Original Message-
>From: Fujii Masao
>Sent: Friday, April 2, 2021 6:03 PM
>To: Michael Paquier ; shinya11.k...@nttdata.com
>Cc: pgsql-hack...@postgresql.org
>Subject: Re: Fix pg_checksums progress report
>
>
>
>On 2021/04/02 16:47, Michael Paquier wrote:
>> On Fri, Apr 02, 2021 at
On 30.03.21 11:20, Peter Eisentraut wrote:
On 24.03.21 11:52, houzj.f...@fujitsu.com wrote:
+ if (!has_nonconst_input)
+ return ece_evaluate_expr(expr);
That's not okay without a further check to see if the comparison
function used
by the node is immutable.
On 2021/04/02 16:47, Michael Paquier wrote:
On Fri, Apr 02, 2021 at 07:30:32AM +, shinya11.k...@nttdata.com wrote:
I added a comment to the patch, and attached the new patch.
Thanks for updating the patch!
+ /*
+* The current_size is calculated before
1 - 100 of 111 matches
Mail list logo
