On Thursday, March 17, 2022 3:04 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 t
Hello,
While testing on the current PG master, I noticed a problem between
backends communicating over a shared memory queue. I think `shm_mq_sendv()`
fails to flush the queue, even if `force_flush` is set to true, if the
receiver is not yet attached to the queue. This simple fix solves
the probl
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 expect from sslcrldir. It is possible to
> bypass that with something like the attached, but that's a kind of
> ugly hack. Another a
On Thu, Mar 17, 2022 at 07:55:30PM +1300, Thomas Munro wrote:
> I don't really want to spill details of this developer-only stuff onto
> more manual sections... It's not really helping users if we confuse
> them with irrelevant details of a feature they shouldn't be using, is
> it? And the existi
At Thu, 17 Mar 2022 07:42:42 +0100, Peter Eisentraut
wrote in
> 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
On Wed, Mar 16, 2022 at 8:49 PM Ashutosh Sharma wrote:
>
> I can see that the pg_get_wal_records_info function shows the details
> of the WAL record whose existence is beyond the user specified
> stop/end lsn pointer. See below:
>
> ashu@postgres=# select * from pg_get_wal_records_info('0/0128
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 expect from sslcrldir. It is possible to
> > bypass that with s
At Thu, 17 Mar 2022 16:39:52 +0900, Michael Paquier wrote
in
> On Thu, Mar 17, 2022 at 07:55:30PM +1300, Thomas Munro wrote:
> > I don't really want to spill details of this developer-only stuff onto
> > more manual sections... It's not really helping users if we confuse
> > them with irrelevan
On Thu, Mar 17, 2022 at 10:48 AM Kyotaro Horiguchi
wrote:
>
> It still suggests unspecifiable end-LSN..
>
> > select * from pg_get_wal_records_info('4/4B28EB68', '4/4C60');
> > ERROR: cannot accept future end LSN
> > DETAIL: Last known WAL LSN on the database system is 4/4C60.
Thanks Ky
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 1:53 PM Masahiko Sawada
> > wrote:
> > >
> > > I've attached an updated version patch.
> > >
> >
> > The patch LGTM. I have made minor cha
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 WalSndUpdateProgress(), if we have received
> > any reply from the subscriber in last
On 15.03.22 08:41, Julien Rouhaud wrote:
The locale object in ICU is an identifier that specifies a particular locale
and has fields for language, country, and an optional code to specify further
variants or subdivisions. These fields also can be represented as a string
with the fields separated
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 1:53 PM Masahiko Sawada
> > > wrote:
> > > >
> > > > I've attached an up
On 16.03.22 21:27, samay sharma wrote:
The only goal of this patch wasn't to enable support for Azure AD.
That's just one client. Users might have a need to add or change auth
methods in the future and providing that extensibility so we don't need
to have core changes for each one of them would
On Sat, Feb 12, 2022 at 12:52:40PM +0900, Michael Paquier wrote:
> On Fri, Feb 11, 2022 at 10:07:49AM -0500, Robert Haas wrote:
> > Over in
> > http://postgr.es/m/CA+TgmoYUDEJga2qV_XbAZ=pgebaosgfmzz6ac4_srwom_+u...@mail.gmail.com
> > I was noticing that CreateWalTarMethod doesn't support LZ4
> > c
On Wed, Mar 16, 2022 at 12:33 PM Ajin Cherian wrote:
>
> On Mon, Mar 7, 2022 at 11:44 PM Ajin Cherian wrote:
> >
> > Fixed.
> >
Review comments/suggestions:
=
1. Isn't it sufficient to call pgoutput_send_begin from
maybe_send_schema as that is commonplace for all others a
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
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 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
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 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
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
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 >=
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
> 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 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
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 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 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 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
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
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
>
> 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
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 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
> 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.
>
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
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
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 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 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 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 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
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 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
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: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 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 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 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 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
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
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
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
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
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
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
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
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",
>
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
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
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 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
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
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
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
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
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
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
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
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
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 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 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 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
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
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
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
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 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
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
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
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
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
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
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
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 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.
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: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
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 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=
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
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 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
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
>
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
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
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
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",
>> +
1 - 100 of 116 matches
Mail list logo
