On Thu, 12 Aug 2021 at 14:02, John Naylor wrote:
>
>
> On Wed, Aug 11, 2021 at 8:13 PM David Rowley wrote:
> >
> > On Thu, 12 Aug 2021 at 05:11, John Naylor
> > wrote:
> > > 0001 moves some declarations around so that "slow" popcount functions are
> > > called directly on non-x86 platforms.
>
On Wed, Aug 11, 2021 at 7:45 PM Mark Dilger
wrote:
>
> > On Aug 10, 2021, at 10:59 PM, vignesh C wrote:
> >
> > Also, the behavior of "Alter publication drop table" for which the
> > user is not the owner is successful, Is this behavior correct?
>
> I think that dropping a table from a
On Wed, Aug 11, 2021 at 8:47 PM Tom Lane wrote:
>
> Robert Haas writes:
> > I have to admit that after working with Amit on all the work to make
> > hash indexes WAL-logged a few years ago, I was somewhat disillusioned
> > with the whole AM. It seems like a cool idea to me but it's just not
> >
On Thu, Aug 12, 2021 at 12:53 PM Masahiko Sawada wrote:
>
> Yeah, I prefer my original patch over this idea. On the other hand, I
> can see the point of review comment on it that Amit pointed out[1].
>
> Regards,
>
> [1]
>
On Thu, Aug 12, 2021 at 9:09 AM Dilip Kumar wrote:
>
> On Wed, Aug 11, 2021 at 8:47 PM Tom Lane wrote:
>
> > As far as the specific point at hand is concerned, I think storing
> > a hash value per index column, while using only the first column's
> > hash for bucket selection, is what to do for
On Wed, Aug 11, 2021 at 8:47 PM Tom Lane wrote:
> As far as the specific point at hand is concerned, I think storing
> a hash value per index column, while using only the first column's
> hash for bucket selection, is what to do for multicol indexes.
> We still couldn't set amoptionalkey=true
Hi Amit,
Thanks for your review.
> Can you please explain why you have the restriction for including
> replica identity columns and do we want to put a similar restriction
> for the primary key? As far as I understand, if we allow default
> values on subscribers for replica identity, then
Hi,
I've updated the patch to remove unnecessary changes and added tests.
On Fri, Jul 16, 2021 at 9:09 PM vignesh C wrote:
> pg_dump support plain, custom, tar and directory format, I think,
> cascade option will be added by pg_dump only for plain format and for
> the other format pg_restore
On Wed, Aug 11, 2021 at 5:42 PM Daniel Gustafsson wrote:
>
> > On 11 Aug 2021, at 09:57, Masahiko Sawada wrote:
>
> > Additionally, refresh options as described in
> > refresh_option of
> > REFRESH PUBLICATION may be specified,
> > except in the case of DROP PUBLICATION.
>
> Since this paragraph
Hi.
By using Kyotaro's "counting" patch I was able to reproduce very
similar results to what he had earlier posted [1].
AFAIK I have the same test scenario that he was using.
Test setup:
- using async pub/sub
- subscription is for the pgbench_history table
- pgbench is run for 10 seconds
-
On Wed, Aug 11, 2021 at 8:13 PM David Rowley wrote:
>
> On Thu, 12 Aug 2021 at 05:11, John Naylor
wrote:
> > 0001 moves some declarations around so that "slow" popcount functions
are called directly on non-x86 platforms.
>
> I was wondering if there was a reason that you didn't implement this
>
On 8/11/21 8:53 PM, Jonathan S. Katz wrote:
> On 8/11/21 7:25 PM, David Rowley wrote:
> I've updated it to:
>
> "This release marks the third beta release of PostgreSQL 14 and puts the
> community one step closer to general availability around the end of the
> third quarter."
And made another
On 8/11/21 7:25 PM, David Rowley wrote:
> Thanks for drafting this up.
>
> On Thu, 12 Aug 2021 at 04:32, Jonathan S. Katz wrote:
>> Please ensure you have your feedback in no later than midnight today
>> (Aug 11) AoE[1].
>
> It might not be the exact technical feedback you had in mind, but I
>
On Thu, 12 Aug 2021 at 05:11, John Naylor wrote:
> 0001 moves some declarations around so that "slow" popcount functions are
> called directly on non-x86 platforms.
I was wondering if there was a reason that you didn't implement this
by just changing pg_popcount32 and pg_popcount64 to be actual
On Wed, 11 Aug 2021 at 19:50, Gavin Flower
wrote:
> Living in New Zealand, I'd definitely agreed with not using seasons as
> they are hemispheric specific.
>
> Does anybody, other than the Americans, use 'Fall'' for Autumn???
>
Canadian here. We often use “Fall”, and we’re not Americans even
On 12/08/21 11:25 am, David Rowley wrote:
Thanks for drafting this up.
On Thu, 12 Aug 2021 at 04:32, Jonathan S. Katz wrote:
Please ensure you have your feedback in no later than midnight today
(Aug 11) AoE[1].
It might not be the exact technical feedback you had in mind, but I
think the
On 8/11/21 2:48 AM, Peter Geoghegan wrote:
On Wed, Jun 23, 2021 at 7:19 AM Andrey V. Lepikhov
wrote:
Ivan Frolkov reported a problem with choosing a non-optimal index during
a query optimization. This problem appeared after building of an
extended statistics.
Any thoughts on this, Tomas?
Thanks for drafting this up.
On Thu, 12 Aug 2021 at 04:32, Jonathan S. Katz wrote:
> Please ensure you have your feedback in no later than midnight today
> (Aug 11) AoE[1].
It might not be the exact technical feedback you had in mind, but I
think the following could be improved:
+ This release
On 8/12/21 12:48 AM, Mark Dilger wrote:
On Aug 11, 2021, at 3:45 PM, Tomas Vondra
wrote:
As I said in my last reply, I'm not sure it's particularly useful
to look at overall results from data sets with independent columns.
That's not what extended statistics are for, and people should not
> On Aug 11, 2021, at 3:45 PM, Tomas Vondra
> wrote:
>
> As I said in my last reply, I'm not sure it's particularly useful to look at
> overall results from data sets with independent columns. That's not what
> extended statistics are for, and people should not create them in those cases
On 8/12/21 12:02 AM, Mark Dilger wrote:
...
Once the data is made deterministic, the third set looks slightly
better than the first, rather than slightly worse. But almost 20% of
the query types still look worse after applying the patch. I'm going to
dig deeper into those to see if that
After thinking about the described issues for a while, my proposal is to
completely revamp the way this feature works. See below.
Now, the proposal seems awfully invasive, but it's *the* way I see to
avoid the pgstat traffic. For pg14, maybe we can live with it, and just
use the smaller patches
On Thu, Aug 12, 2021 at 1:45 AM Robert Haas wrote:
> I think that worked for me on older macOS releases, and then it
> stopped working at some point after some update or reinstall or
> something. Unfortunately I don't know any more precisely than that,
> but it does seem like we have to find some
> On Aug 11, 2021, at 10:38 AM, Tomas Vondra
> wrote:
>
> So I'm a bit puzzled about the claim that random data make the problems more
> extreme. Can you explain?
Hmm... you appear to be right.
I changed the gentest.pl script to fill the tables with randomized data, but
the random data
On Wed, Aug 11, 2021 at 4:11 PM Melanie Plageman
wrote:
>
> On Tue, Aug 3, 2021 at 2:13 PM Andres Freund wrote:
> >
> > > @@ -2895,6 +2948,20 @@ FlushBuffer(BufferDesc *buf, SMgrRelation reln)
> > > /*
> > >* bufToWrite is either the shared buffer or a copy, as appropriate.
> > >
On 8/11/21 5:17 PM, Mark Dilger wrote:
On Aug 11, 2021, at 7:51 AM, Mark Dilger wrote:
I'll go test random data designed to have mcv lists of significance
Done. The data for column_i is set to floor(random()^i*20).
column_1 therefore is evenly distributed between 0..19, with
> Sure, DECLARE does not matter as it is new. However, please note
> that
> the specific point I was trying to make with my link [2] from
> upthread
> is related to the use of cached connection names with DEALLOCATE, as
> of this line in the new test declare.pgc:
> EXEC SQL DEALLOCATE PREPARE
On Tue, Aug 3, 2021 at 2:13 PM Andres Freund wrote:
>
> Hi,
>
> On 2021-08-02 18:25:56 -0400, Melanie Plageman wrote:
> > Thanks for the feedback!
> >
> > I agree it makes sense to count strategy writes separately.
> >
> > I thought about this some more, and I don't know if it makes sense to
> >
On Wed, Aug 11, 2021 at 8:32 AM Greg Nancarrow wrote:
> This is explained by the TransactionSnapshot being a later snapshot in
> this case.
> So this is why it seems to be wrong to call GetTransactionSnapshot()
> in InitializeParallelDSM() and use a separate, potentially later,
> snapshot than
On 8/11/21 2:46 PM, Justin Pryzby wrote:
> On Wed, Aug 11, 2021 at 12:32:41PM -0400, Jonathan S. Katz wrote:
>
>> * walsenders now show their latest replication commands in
>> `pg_stat_activity`,
>> instead of just showing the latest SQL command.
>
> singular "command" in pg_stat_activity ?
On Wed, Aug 11, 2021 at 12:32:41PM -0400, Jonathan S. Katz wrote:
> * walsenders now show their latest replication commands in `pg_stat_activity`,
> instead of just showing the latest SQL command.
singular "command" in pg_stat_activity ?
> * `pg_settings.pending_restart` now show as true when a
On Wed, Aug 11, 2021 at 11:42 AM Jonathan S. Katz wrote:
> So perhaps:
>
> "* `pg_upgrade` now carries forward the old installation's `oldestXID`
> value and no longer forces an anti-wraparound `VACUUM`."
>
> or maybe even:
>
> "* `pg_upgrade` no longer forces an anti-wraparound `VACUUM`."
I
On 8/11/21 2:29 PM, Peter Geoghegan wrote:
> On Wed, Aug 11, 2021 at 11:23 AM Jonathan S. Katz
> wrote:
>> How about:
>>
>> * `pg_upgrade` now carries forward the old installation's `oldestXID`
>> value, which can improve things from a performance standpoint by no
>> longer forcing an
On Wed, Aug 11, 2021 at 11:23 AM Jonathan S. Katz wrote:
> How about:
>
> * `pg_upgrade` now carries forward the old installation's `oldestXID`
> value, which can improve things from a performance standpoint by no
> longer forcing an anti-wraparound `VACUUM`.
I don't think that framing this as a
On 8/11/21 1:35 PM, Peter Geoghegan wrote:
> On Wed, Aug 11, 2021 at 9:32 AM Jonathan S. Katz wrote:
>> Please ensure you have your feedback in no later than midnight today
>> (Aug 11) AoE[1].
>
> I think that the pg_upgrade item should say that we now avoid forcing
> an anti-wraparound VACUUM
On 8/11/21 4:51 PM, Mark Dilger wrote:
On Aug 11, 2021, at 5:08 AM, Dean Rasheed wrote:
This feels like rather an artificial example though. Is there any real
use for this sort of clause?
The test generated random combinations of clauses and then checked if
any had consistently worse
On Wed, Aug 11, 2021 at 9:32 AM Jonathan S. Katz wrote:
> Please ensure you have your feedback in no later than midnight today
> (Aug 11) AoE[1].
I think that the pg_upgrade item should say that we now avoid forcing
an anti-wraparound VACUUM on upgrade. This was never necessary.
--
Peter
Thanks Dagfinn for the updated patches.
I do not get these errors, neither with the patch file I still have
> locally, or by saving the attachment from my original email. Are you
> sure something in your download process hasn't converted it to Windows
> line endings (\r\n), or otherwise mangled
Currently, all platforms must indirect through a function pointer to call
popcount on a word-sized input, even though we don't arrange for a fast
implementation on non-x86 to make it worthwhile.
0001 moves some declarations around so that "slow" popcount functions are
called directly on non-x86
On Wed, Aug 11, 2021 at 11:17 AM Tom Lane wrote:
> Yeah, agreed. The whole buckets-are-integral-numbers-of-pages scheme
> is pretty well designed to ensure bloat, but trying to ameliorate that
> by reducing the number of buckets creates its own problems (since, as
> you mention, we have no
Hi,
Attached is a draft for the 2021-08-12 release announcement. Please
review for technical accuracy.
Please ensure you have your feedback in no later than midnight today
(Aug 11) AoE[1].
Thanks!
Jonathan
[1] https://en.wikipedia.org/wiki/Anywhere_on_Earth
The PostgreSQL Global Development
On Mon, Dec 14, 2020 at 7:09 AM Ashutosh Bapat
wrote:
> But we write what's guaranteed. Anything not written in
> the documents is not guaranteed.
>
In the case of LIMIT we go to great lengths to write what isn't
guaranteed. I suggest that this is similar enough in nature to warrant the
same
John Naylor writes:
> (Standard disclaimer that I'm not qualified to design index AMs) I've seen
> one mention in the literature about the possibility of simply having a
> btree index over the hash values.
Yeah, that's been talked about in the past --- we considered it
moderately seriously back
On Wed, Aug 11, 2021 at 10:54 AM Robert Haas wrote:
> don't know how the present patch tries to solve that problem.) It's
> tempting to think that we should think about creating something
> altogether new instead of hacking on the existing implementation, but
> that's a lot of work and I'm not
On 8/11/21 4:51 PM, Mark Dilger wrote:
On Aug 11, 2021, at 5:08 AM, Dean Rasheed wrote:
This feels like rather an artificial example though. Is there any real
use for this sort of clause?
The test generated random combinations of clauses and then checked if any had
consistently worse
Robert Haas writes:
> I have to admit that after working with Amit on all the work to make
> hash indexes WAL-logged a few years ago, I was somewhat disillusioned
> with the whole AM. It seems like a cool idea to me but it's just not
> that well-implemented.
Yeah, agreed. The whole
> On Aug 11, 2021, at 7:51 AM, Mark Dilger wrote:
>
> I'll go test random data designed to have mcv lists of significance
Done. The data for column_i is set to floor(random()^i*20). column_1
therefore is evenly distributed between 0..19, with successive columns weighted
more towards
On 8/11/21 2:08 PM, Dean Rasheed wrote:
On Wed, 11 Aug 2021 at 00:05, Tomas Vondra
wrote:
So with the statistics, the estimate gets a bit worse. The reason is
fairly simple - if you look at the two parts of the OR clause, we get this:
clause actualno stats
On Wed, Aug 11, 2021 at 10:30 AM Tom Lane wrote:
> Robert Haas writes:
> > I suspect it would be hard to store multiple hash values, one per
> > column. It seems to me that what we ought to do is combine the hash
> > values for the individual columns using hash_combine(64) and store the
> >
> On Aug 11, 2021, at 5:08 AM, Dean Rasheed wrote:
>
> This feels like rather an artificial example though. Is there any real
> use for this sort of clause?
The test generated random combinations of clauses and then checked if any had
consistently worse performance. These came up. I don't
On Wed, Aug 11, 2021 at 5:54 AM Robert Haas wrote:
> Yeah. I tend to feel like this is the kind of thing where it's not
> likely to be 100% obvious to users how it all works no matter what we
> put in the documentation, and that some of the behavior of a system
> has to be learned just by trying
Robert Haas writes:
> I suspect it would be hard to store multiple hash values, one per
> column. It seems to me that what we ought to do is combine the hash
> values for the individual columns using hash_combine(64) and store the
> combined value. I can't really imagine why we would NOT do that.
On Tue, Aug 10, 2021 at 8:44 AM Dilip Kumar wrote:
> I was looking into the hash_multicoul.v3.patch, I have a question
>
>
> - Hash indexes support only single-column indexes and do not allow
> - uniqueness checking.
> + Hash indexes support uniqueness checking.
> + Hash indexes support
> On Aug 10, 2021, at 10:59 PM, vignesh C wrote:
>
> Also, the behavior of "Alter publication drop table" for which the
> user is not the owner is successful, Is this behavior correct?
I think that dropping a table from a publication should be allowed for the
publication owner, without
Greg Sabino Mullane writes:
> v3 looks good, but I'm still not sure how to test the bit mentioned above.
> I'm not familiar with this part of the code (SubPostmasterMain etc.), but
> running make check-world with EXEC_BACKEND does not seem to execute that
> code, as I added exit(1) to
Andrew Dunstan writes:
> initdb also runs postgres a bunch of times via system(), similarly to
> pg_regress but without the "exec". Does it also need adjusting?
That shouldn't be an issue, because we're only running the single
"standalone backend" process, not a cluster.
On Tue, Aug 10, 2021 at 7:59 PM Thomas Munro wrote:
> I saw claims that you can also link with -Wl,-no_pie or toggle the PIE
> bit on your executable and libraries, but that didn't work for me on
> 11, Intel (no effect) or ARM (linker option gone).
I think that worked for me on older macOS
On Mon, Aug 9, 2021 at 8:22 PM Bossart, Nathan wrote:
> > Is this going to get tripped by a call from restore_backend_variables?
>
> I ran 'make check-world' with EXEC_BACKEND with no problems, so I
> don't think so.
>
v3 looks good, but I'm still not sure how to test the bit mentioned above.
Alvaro Herrera writes:
> I'll recast my vote to make this line be
> my $node = PgTest::Cluster->new('nodename');
> which seems succint enough. I could get behind PgTest::PgCluster too,
> but having a second Pg there seems unnecessary.
Either of those WFM.
regards,
On 2021-Aug-10, Andrew Dunstan wrote:
> If we were publishing them on CPAN that would be reasonable. But we're
> not, nor are we likely to, I believe. I'd rather not have to add two
> level of directory hierarchy for this, and this also seems a bit
> long-winded:
>
> my $node =
On Wed, Aug 11, 2021 at 3:59 AM Paul Guo wrote:
> Thanks for reviewing. Let me explain a bit. The patch series includes
> four patches.
>
> 0001 and 0002 are test changes for the fix (0003).
>- 0001 is the test framework change that's needed by 0002.
>- 0002 is the test for the code fix
On Tue, Aug 10, 2021 at 5:53 PM David G. Johnston
wrote:
>> The final portion of the patch adds new regression tests. I'm not
>> going to say that this is completely without merit, because it can be
>> useful to know if some patch changes the behavior, but I guess I don't
>> really see a whole
On Wed, Aug 11, 2021 at 10:30 AM Amit Kapila wrote:
>
> On Tue, Aug 10, 2021 at 8:08 PM Alvaro Herrera
> wrote:
> >
> > On 2021-Jul-30, Amit Kapila wrote:
> >
> > Reading Dilip's last posted patch that day, I had some reservations
> > about the API of ExtractReplicaIdentity. The new argument
On 8/10/21 7:59 PM, Thomas Munro wrote:
> On Wed, Aug 11, 2021 at 7:07 AM Thomas Munro wrote:
>> On Wed, Aug 11, 2021 at 2:12 AM Andres Freund wrote:
>>> On Tue, Aug 10, 2021, at 15:19, Thomas Munro wrote:
Yeah, make check always fails for me on macOS 11. With the attached
On Tue, Aug 10, 2021 at 12:35 AM Robert Haas wrote:
>
> Now there is evidently something wrong with this line of reasoning
> because the code is buggy and my proposed fix doesn't work, but I
> don't know what is wrong with it. You seem to think that it's crazy
> that we try to replicate the
On 2021-08-11 00:21, Fujii Masao wrote:
On 2021/08/10 21:22, torikoshia wrote:
I have updated the patch in this way.
Thanks for updating the patch!
In this patch, getting the plan to the DO statement is as follows.
Looks good to me.
Any thoughts?
+ ereport(LOG_SERVER_ONLY,
+
On Wed, 11 Aug 2021 at 00:05, Tomas Vondra
wrote:
>
> So with the statistics, the estimate gets a bit worse. The reason is
> fairly simple - if you look at the two parts of the OR clause, we get this:
>
> clause actualno statswith stats
>
On Wed, 11 Aug 2021 at 07:37, Amit Kapila wrote:
> On Wed, Aug 11, 2021 at 4:57 PM Dave Cramer wrote:
> >
> > On Wed, 11 Aug 2021 at 07:24, Amit Kapila
> wrote:
> >>
> >> On Wed, Aug 11, 2021 at 1:18 AM Dave Cramer
> wrote:
> >> >
> >> > Reviving this thread
> >> >
> >> > 2021-08-10
On Wed, Aug 11, 2021 at 4:57 PM Dave Cramer wrote:
>
> On Wed, 11 Aug 2021 at 07:24, Amit Kapila wrote:
>>
>> On Wed, Aug 11, 2021 at 1:18 AM Dave Cramer wrote:
>> >
>> > Reviving this thread
>> >
>> > 2021-08-10 19:05:09.096 UTC [3738] LOG: logical replication apply worker
>> > for
On Wed, 11 Aug 2021 at 07:24, Amit Kapila wrote:
> On Wed, Aug 11, 2021 at 1:18 AM Dave Cramer wrote:
> >
> > Reviving this thread
> >
> > 2021-08-10 19:05:09.096 UTC [3738] LOG: logical replication apply
> worker for subscription "sub_mycluster_alltables" has started
> > 2021-08-10
On Wed, Aug 11, 2021 at 1:18 AM Dave Cramer wrote:
>
> Reviving this thread
>
> 2021-08-10 19:05:09.096 UTC [3738] LOG: logical replication apply worker for
> subscription "sub_mycluster_alltables" has started
> 2021-08-10 19:05:09.107 UTC [3739] LOG: logical replication table
>
On Tue, Aug 10, 2021 at 6:14 PM Dilip Kumar wrote:
>
> On Fri, Jul 23, 2021 at 6:16 PM Simon Riggs
> wrote:
> >
> > On Thu, 22 Jul 2021 at 06:10, Amit Kapila wrote:
>
> > Complete patch for hash_multicol.v3.patch attached, slightly updated
> > from earlier patch.
> > Docs, tests, passes make
On 8/10/21 11:27 PM, 孙诗浩(思才) wrote:
> we can use regular expressions (<>|!=) to cover "<>" and "!=".
> There is no
> need to have two definitions less_greater and not_equals, because it
> will confuse developer.
> So, we can use only not_equals to cover this operator set.
>
>
I don't
> On 11 Aug 2021, at 09:57, Masahiko Sawada wrote:
> Additionally, refresh options as described in
> refresh_option of
> REFRESH PUBLICATION may be specified,
> except in the case of DROP PUBLICATION.
Since this paragraph is under the literal option “refresh”, which takes a
value, I still find
On Wed, Aug 11, 2021 at 2:48 PM Masahiko Sawada wrote:
>
>
> I've attached the new patches. Please review them.
Please note that newly added tap tests fail due to known assertion
failure in pgstats that I reported here[1].
Regards,
[1]
On Wed, Aug 11, 2021 at 11:19 AM Masahiko Sawada wrote:
>
> On Tue, Aug 10, 2021 at 7:18 PM Amit Kapila wrote:
> > ==
> >
> > 1. While applying DML operations, we are setting up the error context
> > multiple times due to which the
On Wed, Aug 11, 2021 at 4:56 AM Robert Haas wrote:
>
> On Thu, Aug 5, 2021 at 6:20 AM Paul Guo wrote:
> > Rebased.
>
> The commit message for 0001 is not clear enough for me to understand
> what problem it's supposed to be fixing. The code comments aren't
> really either. They make it sound like
On Tue, Aug 10, 2021 at 12:28 PM Amit Kapila wrote:
>
> On Tue, Aug 10, 2021 at 6:31 AM Masahiko Sawada wrote:
> >
> > On Mon, Aug 9, 2021 at 1:01 PM Peter Smith wrote:
> > >
> > > On Mon, Aug 9, 2021 at 12:46 PM Amit Kapila
> > > wrote:
> >
> > But "REFRESH PUBLICATION refresh_option" seems
On Fri, May 28, 2021 at 2:39 AM Stephen Frost wrote:
>
> Greetings,
>
> * Bruce Momjian (br...@momjian.us) wrote:
> > On Thu, May 27, 2021 at 04:09:13PM -0400, Stephen Frost wrote:
> > > The above article, at least, suggested encrypting the sector number
> > > using the second key and then
On Fri, Aug 06, 2021 at 04:59:55PM -0700, Soumyadeep Chakraborty wrote:
> Rebased. Also added a stronger check to see if the standby is stuck in
> recovery_min_apply_delay:
>
> $node_standby->poll_query_until('postgres', qq{
> SELECT wait_event = 'RecoveryApplyDelay' FROM pg_stat_activity
> WHERE
On Tue, Aug 10, 2021 at 8:15 PM Ha Ka wrote:
>
> sob., 19 cze 2021 o 12:14 Amit Kapila napisał(a):
>
> We increased logical_decoding_work_mem for our production database
> from 64 to 192 MB and it looks like the issue still persists. The
> frequency with which replication hangs has remained the
On Tue, Aug 03, 2021 at 09:29:48AM +, liuhuail...@fujitsu.com wrote:
> There was a problem with the before patch when testing.
> So resubmit it.
FWIW, I see no problems with patch version 1 or 2, as long as you
apply patch version 1 with a command like patch -p2. One thing of
patch 2 is
On Mon, Aug 9, 2021 at 9:50 PM Mark Dilger wrote:
>
>
>
> > On Aug 6, 2021, at 1:32 AM, vignesh C wrote:
> >
> > the attached v19 patch
>
> With v19 applied, a schema owner can publish the contents of a table
> regardless of ownership or permissions on that table:
>
> +CREATE ROLE user1;
>
83 matches
Mail list logo
