On Thu, Mar 17, 2022 at 02:14:52PM +0100, Peter Eisentraut wrote:
> On 17.03.22 13:01, Shinoda, Noriyoshi (PN Japan FSIP) wrote:
> > Thank you to all the developers.
> > I found that the description of the pg_database.daticulocale column was not
> > written in the documentation.
> > The attached s
Hi,
On Thu, Mar 17, 2022 at 11:16:24PM -0700, Paul Martinez wrote:
>
> Adding and removing indexes is a regular part of database maintenance,
> but in a large database, removing an index can be a very risky operation.
> Removing the wrong index could have disastrous consequences for
> performance,
Hey, hackers,
Adding and removing indexes is a regular part of database maintenance,
but in a large database, removing an index can be a very risky operation.
Removing the wrong index could have disastrous consequences for
performance, and it could take tens of minutes, or even hours, to rebuild
t
On Fri, Mar 18, 2022 at 10:27:41AM +0900, Yugo NAGATA wrote:
> I added some queries in the regression test. Attached is the updated patch.
Thanks. This looks rather sane to me. I'll split things into 3
commits in total, as of the psql completion, SET TABLESPACE and SET
ACCESS METHOD. The first
Hi,
On 2022-03-18 00:45:49 -0400, Stephen Frost wrote:
> > I also don’t think that I agree that it’s acceptable to only have the
> > > ability to extend the authentication on the server side as that implies a
> > > whole bunch of client-side work that goes above and beyond just
> > > implementing
On Fri, Mar 18, 2022 at 12:47 AM Tomas Vondra
wrote:
>
> I pushed the second fix. Interestingly enough, wrasse failed in the
> 013_partition test. I don't see how that could be caused by this
> particular commit, though - see the pgsql-committers thread [1].
>
I have a theory about what's going o
On Fri, Mar 18, 2022 at 2:15 AM Nathan Bossart wrote:
>
> On Thu, Mar 17, 2022 at 06:48:43PM +0530, Bharath Rupireddy wrote:
> > Personally, I tend to agree with v4-0001 (option (4)) or v4-0002
> > (option (3)) than v4-0003 (option (1)) as it adds more unreadability
> > with most of the code dupli
On Thu, Mar 9, 2022 at 11:52 AM Kuroda, Hayato/黒田 隼人
wrote:
> Thank you for updating!
Thanks for your comments.
> 1. pgoutput_change
> ```
> + bool is_send = true;
> ```
>
> My first impression is that is_send should be initialized to false, and it
> will change
> to true when OutputPlug
On Thu, Mar 17, 2022 at 7:52 PM Masahiko Sawada wrote:
>
Thanks for your comments.
> On Thu, Mar 17, 2022 at 7:14 PM Amit Kapila wrote:
> >
> > On Thu, Mar 17, 2022 at 12:27 PM Amit Kapila
> wrote:
> > >
> > > On Wed, Mar 16, 2022 at 7:38 PM Masahiko Sawada
> wrote:
> > > >
> > > > After more
Greetings,
On Fri, Mar 18, 2022 at 00:24 Andres Freund wrote:
> Hi,
>
> On 2022-03-18 00:03:37 -0400, Stephen Frost wrote:
> > On Thu, Mar 17, 2022 at 23:25 Andres Freund wrote:
> > > It's imo a separate project to make the client side extensible. There's
> > > plenty
> > > of authentication me
On Fri, Mar 18, 2022 at 1:44 AM Robert Haas wrote:
>
> On Wed, Mar 16, 2022 at 12:53 AM Dilip Kumar wrote:
> > Thanks Ashutosh and Robert. Other pacthes cleanly applied on this
> > patch still generated a new version so that we can find all patches
> > together. There are no other changes.
>
>
Hi,
On 2022-03-18 00:03:37 -0400, Stephen Frost wrote:
> On Thu, Mar 17, 2022 at 23:25 Andres Freund wrote:
> > It's imo a separate project to make the client side extensible. There's
> > plenty
> > of authentication methods that don't need any further client side support
> > than
> > the existin
Greetings,
On Thu, Mar 17, 2022 at 23:25 Andres Freund wrote:
> On 2022-03-17 22:13:27 -0400, Stephen Frost wrote:
> > This isn’t the first time I asked about this on this thread, yet the
> > question about why this is only being discussed as backend changes, and
> > with the only goal seeming t
Hello Michael,
18.03.2022 05:06, Michael Paquier wrote:
Okay. I'll try to look more closely at that, then. It feels like we
are just missing a MAXALIGN() in those code paths. Are you using any
specific CFLAGS or something environment-sensitive (macos, 32b, etc.)?
No, just x86_64, Ubuntu 20.04,
Hi,
On 2022-03-17 22:13:27 -0400, Stephen Frost wrote:
> This isn’t the first time I asked about this on this thread, yet the
> question about why this is only being discussed as backend changes, and
> with the only goal seeming to be to have a backend loadable module, without
> anything on the cl
Hackers,
Over in [1], Joshua proposed a new set of Object Access Type hooks based on
strings rather than Oids.
His patch was written to be applied atop my patch for granting privileges on
gucs.
On review of his patch, I became uncomfortable with the complete lack of
regression test coverage.
Kyotaro Horiguchi writes:
> At Thu, 17 Mar 2022 19:25:00 +0300, Maxim Orlov wrote in
>> +/* printf/elog format compatible with 32 and 64 bit xid. */
>> +typedef unsigned long long XID_TYPE;
>> ...
>> + errmsg_internal("found multixact %llu from before relminmxid %llu",
>> +
Greetings,
On Thu, Mar 17, 2022 at 17:02 Andres Freund wrote:
> On 2022-03-16 18:50:23 -0400, Stephen Frost wrote:
> > First, let's be clear- we aren't actually talking about custom or
> > pluggable authentication here, at least when it comes to PG as a
> > project. For it to actually be plugga
On Wed, Mar 16, 2022 at 08:35:59PM +0300, Alexander Lakhin wrote:
> Yes, I've reproduced that issue on master (46d9bfb0).
Okay. I'll try to look more closely at that, then. It feels like we
are just missing a MAXALIGN() in those code paths. Are you using any
specific CFLAGS or something environ
On Thu, Mar 17, 2022 at 06:12:20AM -0500, Justin Pryzby wrote:
> I think this should use
>
> +#include "lz4frame.h"
>
> commit ba595d2322da095a1e6703171b3f1f2815cb
> Author: Michael Paquier
> Date: Fri Nov 5 11:33:25 2021 +0900
>
> Add support for LZ4 compression in pg_receivewal
Ye
Hi Michael-san,
On Wed, 16 Mar 2022 16:18:09 +0900
Michael Paquier wrote:
> Hi Nagata-san,
>
> On Wed, Mar 16, 2022 at 01:33:37PM +0900, Yugo NAGATA wrote:
> > SET ACCESS METHOD is supported in ALTER TABLE since the commit
> > b0483263dd. Since that time, this also has be allowed SET ACCESS
>
At Fri, 18 Mar 2022 10:20:08 +0900 (JST), Kyotaro Horiguchi
wrote in
> "(XID_TYPE) x" is actually equivalent to "(long long) x" here, but the
> point here is "%llu in format string accepts (long long)" so we should
Of course it's the typo of
"%llu in format string accepts (*unsigned* long long
At Wed, 16 Mar 2022 10:14:56 -0400, Robert Haas wrote
in
> Hmm. I think the last two instances of "buffers" in this comment
> should actually say "blocks".
Ok. I replaced them with "blocks" and it looks nicer. Thanks!
> > I'll try that, if you are already working on it, please inform me. (It
>
At Thu, 17 Mar 2022 19:25:00 +0300, Maxim Orlov wrote in
> Hi!
>
> Here is the v20 patch. 0001 and 0002 are proposed into PG15 as
> discussed above.
> The whole set of patches is added into [1] to be committed into PG16.
>
> In this version we've made a major revision related to printf/elog for
On Thu, Mar 17, 2022 at 02:28:49PM +0100, Daniel Gustafsson wrote:
> One small concern though. This hunk:
>
> +my $default_ssl_connstr = "sslkey=invalid sslcert=invalid
> sslrootcert=invalid sslcrl=invalid sslcrldir=invalid";
> +
> $common_connstr =
> - "user=ssltestuser dbname=trustdb sslcert=
On Thu, Mar 17, 2022 at 1:32 AM Yura Sokolov wrote:
> So I believe it is safe to define PG_HAVE_8BYTE_SINGLE_COPY_ATOMICITY
> for aarch64
Agreed, and pushed. There was another thread that stalled, so I added
a reference and a reviewer from that to your commit message.
This should probably also
On Fri, 18 Mar 2022 at 08:22, Japin Li wrote:
> On Fri, 18 Mar 2022 at 00:22, Zheng Li wrote:
>> Hello Japin,
>>>The new patch change the behavior of publication, when we drop a table
>>>on publisher, the table also be dropped on subscriber, and this made the
>>>regression testa failed, since t
Tom Lane writes:
> =?utf-8?Q?Dagfinn_Ilmari_Manns=C3=A5ker?= writes:
>> I just noticed I left out the = in the match check, here's an updated
>> patch that fixes that.
>
> Hmm is that actually going to be useful in that form?
> Most time zone names contain slashes and will therefore require
On Fri, 18 Mar 2022 at 08:18, Zheng Li wrote:
> Hello,
>
> Attached please find the broken down patch set. Also fixed the failing
> TAP tests Japin reported.
>
Thanks for updating the patchset, I will try it later.
--
Regrads,
Japin Li.
ChengDu WenWu Information Technology Co.,Ltd.
On Fri, 18 Mar 2022 at 00:22, Zheng Li wrote:
> Hello Japin,
>>The new patch change the behavior of publication, when we drop a table
>>on publisher, the table also be dropped on subscriber, and this made the
>>regression testa failed, since the regression test will try to drop the
>>table on su
On Thu, Mar 17, 2022 at 3:03 PM Amit Kapila wrote:
>
> On Wed, Mar 16, 2022 at 1:53 PM Masahiko Sawada wrote:
> >
> > I've attached an updated version patch.
> >
>
> The patch LGTM. I have made minor changes in comments and docs in the
> attached patch. Kindly let me know what you think of the at
Hi,
On 2022-03-17 14:14:52 +0100, Peter Eisentraut wrote:
> On 17.03.22 13:01, Shinoda, Noriyoshi (PN Japan FSIP) wrote:
> > Thank you to all the developers.
> > I found that the description of the pg_database.daticulocale column was not
> > written in the documentation.
> > The attached small pa
I think this one requires some more work, and it needn't be a priority for
v15, so I've adjusted the commitfest entry to v16 and moved it to the next
commitfest.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Thu, Mar 17, 2022 at 04:26:31PM -0700, Swaha Miller wrote:
> On Thu, Mar 17, 2022 at 4:16 PM Nathan Bossart
> wrote:
>
>> It seems unlikely that this will be committed for v15. Swaha, should the
>> commitfest entry be adjusted to v16 and moved to the next commitfest?
>>
>>
> Yes please, thank
On Thu, Mar 17, 2022 at 4:16 PM Nathan Bossart
wrote:
> It seems unlikely that this will be committed for v15. Swaha, should the
> commitfest entry be adjusted to v16 and moved to the next commitfest?
>
>
Yes please, thank you Nathan
Bertand, do you think this has any chance of making it into v15? If not,
are you alright with adjusting the commitfest entry to v16 and moving it to
the next commitfest?
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
It seems unlikely that this will be committed for v15. Swaha, should the
commitfest entry be adjusted to v16 and moved to the next commitfest?
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
It seems unlikely that this will be committed for v15, so I've adjusted the
commitfest entry to v16 and moved it to the next commitfest.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
It seems unlikely that anything discussed in this thread will be committed
for v15, so I've adjusted the commitfest entry to v16 and moved it to the
next commitfest.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
Jacob Champion writes:
> On Fri, 2022-03-04 at 10:45 +0900, Michael Paquier wrote:
>> At the end of the day, Port is an interface used for the communication
>> between the postmaster with the frontends, so I'd like to say that it
>> is correct to not apply this concept to parallel workers because
Aleksander Alekseev writes:
> I understand the concern expressed by Robert in respect of backward
> compatibility. From the user's perspective, personally I would prefer
> a fixed bug over backward compatibility. Especially if we consider the
> fact that the current behaviour of cases like `select
On Fri, 2022-03-04 at 10:45 +0900, Michael Paquier wrote:
> At the end of the day, Port is an interface used for the communication
> between the postmaster with the frontends, so I'd like to say that it
> is correct to not apply this concept to parallel workers because they
> are not designed to co
On Wed, 2022-03-16 at 23:49 +, Jacob Champion wrote:
> Thank you for the explanation -- the misunderstanding was all on my
> end. I thought you were asking me to move the check_cn assignment
> instead of copying it to the end. I agree that your suggestion is much
> clearer, and I'll make that c
On 2022-03-16 18:50:23 -0400, Stephen Frost wrote:
> First, let's be clear- we aren't actually talking about custom or
> pluggable authentication here, at least when it comes to PG as a
> project. For it to actually be pluggable, it needs to be supported on
> both the client side and the server si
On Mon, Mar 14, 2022 at 8:17 PM Julien Rouhaud wrote:
> Great! I'm happy with 0001 and I think it's good to go!
I'll push 0001 today to let the build farm chew on it for a few days
before moving to 0002.
On Thu, Mar 17, 2022 at 06:48:43PM +0530, Bharath Rupireddy wrote:
> Personally, I tend to agree with v4-0001 (option (4)) or v4-0002
> (option (3)) than v4-0003 (option (1)) as it adds more unreadability
> with most of the code duplicated creating more diff with previous
> versions and maintainabi
Hi
čt 17. 3. 2022 v 20:58 odesílatel Greg Stark napsal:
> It looks like this is -- like a lot of plpgsql patches -- having
> difficulty catching the attention of reviewers and committers.
> Aleksander asked for a test and Pavel put quite a bit of work into
> adding a good test case. I actually l
Thanks for the review!
I'll address most of these comments later, but quickly for right now...
On Thu, Mar 17, 2022 at 3:41 PM Justin Pryzby wrote:
> It'd be great if this were re-usable for wal_compression, which I hope in
> pg16 will
> support at least level=N. And eventually pg_dump. But t
Greetings,
* Andres Freund (and...@anarazel.de) wrote:
> On 2022-03-17 14:03:31 -0400, Stephen Frost wrote:
> > * Andres Freund (and...@anarazel.de) wrote:
> > > On 2022-03-17 12:10:51 +0100, Peter Eisentraut wrote:
> > > > Looking at the existing authentication methods
> > > >
> > > > # METHOD c
On Wed, Mar 16, 2022 at 12:53 AM Dilip Kumar wrote:
> Thanks Ashutosh and Robert. Other pacthes cleanly applied on this
> patch still generated a new version so that we can find all patches
> together. There are no other changes.
I committed my v3 of my refactoring patch, here 0001.
I'm workin
On Thu, Mar 17, 2022 at 01:04:17PM -0400, Robert Haas wrote:
> Right, so perhaps the ultimate thing here would be a more fine-grained
> knob than SET STORAGE EXTERNAL -- something that allows you to specify
> that you want to compress only when it really helps. While some people
> might find that u
Greg Stark writes:
> On Fri, 11 Mar 2022 at 15:17, Tom Lane wrote:
>> The patch as-presented isn't very compelling for
>> lack of callers of the new function
> Tom, are you saying you think we're not interested in just adding this
> function unless it's part of this refactoring?
Pretty much, ye
It looks like this is -- like a lot of plpgsql patches -- having
difficulty catching the attention of reviewers and committers.
Aleksander asked for a test and Pavel put quite a bit of work into
adding a good test case. I actually like that there's a test because
it shows the API can be used effect
On Fri, 11 Mar 2022 at 15:17, Tom Lane wrote:
>
> Amul Sul writes:
> > Yeah, that's true, I am too not sure if we really need to refactor
> > all those; If we want, I can give it a try.
>
> The patch as-presented isn't very compelling for
> lack of callers of the new function
Tom, are you say
diff --git a/doc/src/sgml/protocol.sgml b/doc/src/sgml/protocol.sgml
index 9178c779ba..00c593f1af 100644
--- a/doc/src/sgml/protocol.sgml
+++ b/doc/src/sgml/protocol.sgml
@@ -2731,14 +2731,24 @@ The commands accepted in replication mode are:
+
+ For gzip the compression level shoul
On Thu, Mar 17, 2022 at 6:15 AM Peter Eisentraut
wrote:
> committed, thanks
Glad that this finally happened. Thanks to everybody involved!
--
Peter Geoghegan
On Thu, 2022-03-17 at 14:03 -0400, Stephen Frost wrote:
> * Andres Freund (and...@anarazel.de) wrote:
> >
> > trust, reject, md5, password, ident, peer, pam, ldap, radius look trivially
> > possible. I think sspi is doable as well, but I don't know it well enough to
> > be confident. gss without t
Hi,
On 2022-03-17 14:03:31 -0400, Stephen Frost wrote:
> * Andres Freund (and...@anarazel.de) wrote:
> > On 2022-03-17 12:10:51 +0100, Peter Eisentraut wrote:
> > > Looking at the existing authentication methods
> > >
> > > # METHOD can be "trust", "reject", "md5", "password", "scram-sha-256",
>
I pushed the second fix. Interestingly enough, wrasse failed in the
013_partition test. I don't see how that could be caused by this
particular commit, though - see the pgsql-committers thread [1].
I'd like to test & polish the main patch over the weekend, and get it
committed early next week. Unl
On 2022-Mar-17, Alvaro Herrera wrote:
> I'll see what to do about Instrumentation->nfiltered{1,2,3} that was
> complained about by Andres upthread. Maybe some additional macros will
> help.
This turns out not to be as simple as I expected, mostly because we want
to keep Instrumentation as a node
On Thu, Mar 17, 2022 at 12:36 PM Mark Dilger
wrote:
> > On Mar 17, 2022, at 9:29 AM, Joshua Brindle
> > wrote:
> >
> > I hope this patch can be rolled
> > into the contribution from Mark.
>
> Working on it Thanks for the patch!
Great, thanks.
I missed one objectId reference (InvokeObjectDr
So far this commitfest these 10 patches have been marked committed.
That leaves us with 175 "Needs Review" and 28 "Ready for Comitter" so
quite a ways to go ...
* FUNCAPI tuplestore helper function
* parse/analyze API refactoring
* Add wal_compression=zstd
* Add id's to various elements in protoco
Hello Peter,
See attached v16 which removes the libpq workaround.
I suppose this depends on
https://www.postgresql.org/message-id/flat/ab4288f8-be5c-57fb-2400-e3e857f53e46%40enterprisedb.com
getting committed, because right now this makes the psql TAP tests fail
because of the duplicate er
Greetings,
* Andres Freund (and...@anarazel.de) wrote:
> On 2022-03-17 12:10:51 +0100, Peter Eisentraut wrote:
> > Looking at the existing authentication methods
> >
> > # METHOD can be "trust", "reject", "md5", "password", "scram-sha-256",
> > # "gss", "sspi", "ident", "peer", "pam", "ldap", "ra
Hi,
On 2022-03-17 12:10:51 +0100, Peter Eisentraut wrote:
> Looking at the existing authentication methods
>
> # METHOD can be "trust", "reject", "md5", "password", "scram-sha-256",
> # "gss", "sspi", "ident", "peer", "pam", "ldap", "radius" or "cert".
>
> how many of these could have been imple
On Sat, Mar 5, 2022 at 1:26 AM Nathan Bossart wrote:
>
> My point is that there are existing tools for alerting processes when an
> LSN is synchronously replicated and for waking up WAL senders. What I am
> proposing wouldn't involve spinning in XLogSendPhysical() waiting for
> synchronous replic
On Wed, Mar 16, 2022 at 2:36 PM Nathan Bossart wrote:
> Thinking further, is simply reducing the number of TOAST chunks the right
> thing to look at? If I want to add a TOAST attribute that requires 100,000
> chunks, and you told me that I could save 10% in the read path for an extra
> 250 chunks
On Thu, Mar 17, 2022 at 2:42 AM Peter Eisentraut
wrote:
> On 16.03.22 02:25, Kyotaro Horiguchi wrote:
> > Hello, this is a derived topic from [1], summarized as $SUBJECT.
> >
> > This just removes useless hyphens from the words
> > "(crash|emergency)-recovery". We don't have such wordings for "arc
> On Mar 17, 2022, at 9:29 AM, Joshua Brindle
> wrote:
>
> I hope this patch can be rolled
> into the contribution from Mark.
Working on it Thanks for the patch!
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On Thu, Mar 17, 2022 at 12:30 PM Joshua Brindle
wrote:
> I agree with this view, outside of the mixup between MAC and DAC (DAC
> is in-core, MAC is via hooks)
An excellent point! Exactly why we need expert-level help with this stuff! :-)
> So there should be some committers or contributors that
On Thu, Mar 17, 2022 at 12:04 PM Robert Haas wrote:
>
> On Thu, Mar 17, 2022 at 9:25 AM Joshua Brindle
> wrote:
> >
> >
> > > I remain of the opinion that this
> > > patch should not concern itself with that, though.
> >
> > So you are saying that people can add new object types to PG with DAC
>
On Thu, Mar 17, 2022 at 12:19 PM Mark Dilger
wrote:
> Joshua helped test the DAC portion of this patch, and answered a number of my
> questions on the topic, including in-person back in December. I take your
> point, Robert, on the general principle, but the archives should reflect that
> Josh
Hello Alvaro,
> I think this is a pretty interesting and useful feature.
>
> Did you see some old code I wrote towards this goal?
> https://www.postgresql.org/message-id/20150215044814.gl3...@alvh.no-ip.org
> The intention was that DDL would produce some JSON blob that accurately
> describes the D
> On Mar 17, 2022, at 9:04 AM, Robert Haas wrote:
>
> not just in terms of telling other people how they have to write
> their patches.
...
> the burden of maintaining relatively little-used features
> should fall entirely on people who don't care about them.
Joshua helped test the DAC por
On Wed, Mar 16, 2022 at 2:47 PM Tom Lane wrote:
> Stepping back a bit ... do we really want to institutionalize the
> term "setting" for GUC variables? I realize that the view pg_settings
> exists, but the documentation generally prefers the term "configuration
> parameters". Where config.sgml u
On Thu, Mar 17, 2022 at 9:25 AM Joshua Brindle
wrote:
>
>
> > I remain of the opinion that this
> > patch should not concern itself with that, though.
>
> So you are saying that people can add new object types to PG with DAC
> permissions and not concern themselves with MAC capable hooks? Is that
On Thu, 17 Mar 2022 at 05:17, Zheng Li wrote:
> Hi,
>
>>If you don't mind, would you like to share the POC or the branch for this
>>work?
>
> The POC patch is attached. It currently supports the following
> functionalities:
Hi,
When I try to run regression test, there has some errors.
make[
On Mon, Mar 14, 2022 at 1:21 PM Robert Haas wrote:
> There's some appeal to that, but one downside is that it means that
> the client can't be used to fetch data that is compressed in a way
> that the server knows about and the client doesn't. I don't think
> that's great. Why should, for example,
On 3/17/22 10:47, Tom Lane wrote:
> Peter Eisentraut writes:
>> On 16.03.22 19:47, Tom Lane wrote:
>>> ... Perhaps we could just use "SET" and
>>> "ALTER", or "SET" and "SYSTEM"?
>> I think Oracle and MS SQL Server have many multi-word privilege names.
>> So users are quite used to that. And
Peter Eisentraut writes:
> I suppose this depends on
> https://www.postgresql.org/message-id/flat/ab4288f8-be5c-57fb-2400-e3e857f53e46%40enterprisedb.com
> getting committed, because right now this makes the psql TAP tests fail
> because of the duplicate error message.
Umm ... wasn't 618c16707 w
> I forked this thread as requested by several people in the discussion [1].
>
> The new thread contains two patches that are targeting PG15. I replaced
> the thread in the current CF to [1]. This thread was added to the next CF.
> I suggest we continue discussing changes targeting PG >= 16 here.
>
On 12.03.22 17:27, Fabien COELHO wrote:
Are you planning to send a rebased patch for this commit fest?
Argh, I did it in a reply in another thread:-( Attached v15.
So as to help moves things forward, I'd suggest that we should not to
care too much about corner case repetition of some error
Peter Eisentraut writes:
> On 16.03.22 19:47, Tom Lane wrote:
>> ... Perhaps we could just use "SET" and
>> "ALTER", or "SET" and "SYSTEM"?
> I think Oracle and MS SQL Server have many multi-word privilege names.
> So users are quite used to that. And if we want to add more complex
> privileg
>
> On Thu, 17 Mar 2022 at 21:31, Alexander Korotkov
> wrote:
> > On Thu, Mar 17, 2022 at 4:23 PM Peter Eisentraut
> > wrote:
> >> On 17.03.22 14:12, Aleksander Alekseev wrote:
> >> > v19-0001 changes the format string for XIDs from %u to XID_FMT. This
> >> > refactoring allows us to switch to UI
Japin Li writes:
> Maybe, we should format it to string before for localization messages,
> like the following code snippet comes from pg_backup_tar.c.
> However, I do not think it is a good way.
> snprintf(buf1, sizeof(buf1), INT64_FORMAT, (int64) len);
> snprintf(buf2, sizeof(bu
I notice that the publication.sql regression tests contain a number of
comments like
+-- error: replica identity "a" not included in the column list
+ALTER PUBLICATION testpub_fortable ADD TABLE testpub_tbl5 (b, c);
but the error doesn't actually happen, because of the way the replica
identity
On Thu, 17 Mar 2022 at 21:31, Alexander Korotkov wrote:
> On Thu, Mar 17, 2022 at 4:23 PM Peter Eisentraut
> wrote:
>> On 17.03.22 14:12, Aleksander Alekseev wrote:
>> > v19-0001 changes the format string for XIDs from %u to XID_FMT. This
>> > refactoring allows us to switch to UINT64_FORMAT by
On 16.03.22 19:47, Tom Lane wrote:
I'm also fairly allergic to the way that this patch has decided to assign
multi-word names to privilege types (ie SET VALUE, ALTER SYSTEM). There
is no existing precedent for that, and I think it's going to break
client-side code that we don't need to break. I
On 16.03.22 19:59, Mark Dilger wrote:
Informally, we often use "GUC" on this list, but that isn't used formally, leaving "configuration parameter" and "setting" as the
two obvious choices. I preferred "configuration parameter" originally and was argued out of it. My take on "setting" was also
On Thu, Mar 17, 2022 at 4:23 PM Peter Eisentraut
wrote:
> On 17.03.22 14:12, Aleksander Alekseev wrote:
> > v19-0001 changes the format string for XIDs from %u to XID_FMT. This
> > refactoring allows us to switch to UINT64_FORMAT by changing one
> > #define in the future patches.
> >
> > Kyotaro s
> On 17 Mar 2022, at 09:05, Kyotaro Horiguchi wrote:
>
> At Thu, 17 Mar 2022 16:22:14 +0900, Michael Paquier
> wrote in
>> On Thu, Mar 17, 2022 at 02:59:26PM +0900, Michael Paquier wrote:
>>> In both cases, enforcing sslcrl to a value of "invalid" interferes
>>> with the failure scenario we ex
> I remain of the opinion that this
> patch should not concern itself with that, though.
So you are saying that people can add new object types to PG with DAC
permissions and not concern themselves with MAC capable hooks? Is that
an official PG community stance?
On 17.03.22 14:12, Aleksander Alekseev wrote:
v19-0001 changes the format string for XIDs from %u to XID_FMT. This
refactoring allows us to switch to UINT64_FORMAT by changing one
#define in the future patches.
Kyotaro suggested using `errmsg("blah blah %lld ..", (long long)
xid)` instead in or
Hi, Aleksander!
On Thu, Mar 17, 2022 at 4:12 PM Aleksander Alekseev
wrote:
> This thread is a fork of [1], created per request by several people in
> the discussion. It includes two patches from the patchset that we
> believe can be delivered in PG15. The rest of the patches are
> targeting PG >=
Hi hackers,
I forked this thread as requested by several people in the discussion [1].
The new thread contains two patches that are targeting PG15. I replaced the
thread in the current CF to [1]. This thread was added to the next CF. I
suggest we continue discussing changes targeting PG >= 16 her
On Thu, Mar 17, 2022 at 12:12 AM Nathan Bossart
wrote:
>
> On Wed, Mar 16, 2022 at 03:02:41PM +0530, Bharath Rupireddy wrote:
> > On Mon, Mar 14, 2022 at 10:34 PM Nathan Bossart
> > wrote:
> >> I'm -1 on splitting these new statistics to separate LOGs. In addition to
> >> making it more difficul
On 17.03.22 13:01, Shinoda, Noriyoshi (PN Japan FSIP) wrote:
Thank you to all the developers.
I found that the description of the pg_database.daticulocale column was not
written in the documentation.
The attached small patch adds a description of the daticulocale column to
catalogs.sgml.
comm
On Thursday, March 17, 2022 7:56 PM Masahiko Sawada
wrote:
On Thu, Mar 17, 2022 at 5:52 PM Amit Kapila
> wrote:
> >
> > On Thu, Mar 17, 2022 at 12:39 PM osumi.takami...@fujitsu.com
> > wrote:
> > >
> > > On Thursday, March 17, 2022 3:04 PM Amit Kapila
> wrote:
> > > > On Wed, Mar 16, 2022 at
Hi,
Thank you to all the developers.
I found that the description of the pg_database.daticulocale column was not
written in the documentation.
The attached small patch adds a description of the daticulocale column to
catalogs.sgml.
Regards,
Noriyoshi Shinoda
-Original Message-
From: Pe
On Thu, Mar 17, 2022 at 7:14 PM Amit Kapila wrote:
>
> On Thu, Mar 17, 2022 at 12:27 PM Amit Kapila wrote:
> >
> > On Wed, Mar 16, 2022 at 7:38 PM Masahiko Sawada
> > wrote:
> > >
> > > After more thought, can we check only wal_sender_timeout without
> > > skip-count? That is, in WalSndUpdatePr
1 - 100 of 116 matches
Mail list logo
