В Ср, 07/09/2022 в 16:13 +1200, David Rowley пишет:
> On Tue, 6 Sept 2022 at 01:41, David Rowley wrote:
> >
> > On Fri, 2 Sept 2022 at 20:11, David Rowley wrote:
> > >
> > > On Thu, 1 Sept 2022 at 12:46, Tom Lane wrote:
> > > >
> > > > David Rowley writes:
> > > > > Maybe we should just cons
On 31.08.22 20:11, Andres Freund wrote:
doc/src/sgml/resolv.xsl: I don't understand what this is doing. Maybe
at least add a comment in the file.
It's only used for building epubs. Perhaps I should extract that into a
separate patch as well? The relevant section is:
#
# epub
#
# This was pre
On Wed, Sep 7, 2022 12:23 PM vignesh C wrote:
>
>
> Thanks for the comments, the attached v47 patch has the changes for the
> same.
>
Thanks for updating the patch.
Here is a comment.
+ for (i = 0; i < subrel_count; i++)
+ {
+ Oid relid = subrel_
At Tue, 6 Sep 2022 14:02:53 +0300, "Anton A. Melnikov"
wrote in
> Can we treat such behavior as a bug?
Depends on how we see the counter value. I think this can be annoying
but not a bug. CreateRestartPoint already handles that case.
While standby is well catching up, startup may make requests
On Fri, Jul 15, 2022 at 1:49 PM Ken Kato wrote:
> On 2022-07-09 03:18, Peter Geoghegan wrote:
> > On Fri, Jul 8, 2022 at 10:47 AM Alvaro Herrera
> > wrote:
> >> Saving some sort of history would be much more useful, but of course a
> >> lot more work.
>
> Thank you for the comments!
> Yes, havin
On Mon, Jul 25, 2022 at 4:03 AM Kenaniah Cerny wrote:
> Hi Antonin,
>
> Thank you again for the detailed review and questions. It was encouraging
> to see the increasing level of nuance in this latest round.
>
> It's not clear from the explanation of the GRANT ... IN DATABASE ... /
>> GRANT
>>
On Tue, Jun 28, 2022 at 4:50 PM Yura Sokolov
wrote:
> В Вт, 28/06/2022 в 14:26 +0300, Yura Sokolov пишет:
> > В Вт, 28/06/2022 в 14:13 +0300, Yura Sokolov пишет:
> >
> > > Tests:
> > > - tests done on 2 socket Xeon 5220 2.20GHz with turbo bust disabled
> > > (ie max frequency is 2.20GHz)
> >
>
On 07.09.22 09:19, Peter Eisentraut wrote:
This could also be combined with the idea of the postgres.sgml.valid
thing you have in the meson patch set.
I'll finish this up and produce a proper patch.
Something like this.
This does make the rules more straightforward and avoids repeated
xmlli
Hi Jonathan,
On 2022-Sep-06, Jonathan S. Katz wrote:
> * [`MERGE`](https://www.postgresql.org/docs/15/sql-merge.html) statements are
> explicitly rejected inside of a
> [common-table
> expression](https://www.postgresql.org/docs/15/queries-with.html)
> (aka `WITH` query) and
> [`COPY`](https://w
At Tue, 06 Sep 2022 17:10:49 -0400, Reid Thompson
wrote in
> On Thu, 2022-09-01 at 13:43 +0900, Kyotaro Horiguchi wrote:
> >
> > > @@ -916,6 +930,7 @@ AllocSetAlloc(MemoryContext context, Size size)
> > > return NULL;
> > >
> > > context->mem_alloc
On Wed, Sep 7, 2022 at 1:09 PM shiy.f...@fujitsu.com
wrote:
>
> On Wed, Sep 7, 2022 12:23 PM vignesh C wrote:
> >
> >
> > Thanks for the comments, the attached v47 patch has the changes for the
> > same.
> >
>
> Thanks for updating the patch.
>
> Here is a comment.
>
> + for (i = 0; i < sub
At Wed, 07 Sep 2022 17:08:41 +0900 (JST), Kyotaro Horiguchi
wrote in
> At Tue, 06 Sep 2022 17:10:49 -0400, Reid Thompson
> wrote in
> > On Thu, 2022-09-01 at 13:43 +0900, Kyotaro Horiguchi wrote:
> > >
> > > > @@ -916,6 +930,7 @@ AllocSetAlloc(MemoryContext context, Size size)
> > > >
On 2022-Sep-06, John Naylor wrote:
> Note that the indentation hasn't changed. My thought there: perltidy
> will be run again next year, at which time it will be part of a listed
> whitespace-only commit. Any objections, since that could confuse
> someone before then?
I think a good plan is to co
On Fri, Aug 26, 2022 at 10:02:26AM +0900, Michael Paquier wrote:
> FWIW, I was also wondering about the need for all this initialization
> stanza and the extra SystemUser in TopMemoryContext. Now that we have
> MyClientConnectionInfo, I was thinking to just build the string in the
> SQL function a
On Wed, Sep 07, 2022 at 03:29:08PM +0900, Michael Paquier wrote:
> At the end, I have not taken the approach to use errdetail() for this
> problem as errormsg_buf is designed to include an error string. So, I
> have finished by refining the error messages generated in
> RestoreBlockImage(), consum
At Tue, 6 Sep 2022 08:53:25 -0700, Andres Freund wrote in
> Hi,
>
> On 2022-09-06 14:15:56 +0100, Dave Page wrote:
> > Vik and I looked at this a little, and found that we actually don't have
> > generally have GetCurrentTransactionStopTimestamp() at this point - a
> > simple 'select * from pg_c
Re: Andrew Dunstan
> Revert SQL/JSON features
>
> The reverts the following and makes some associated cleanups:
-void
+static void
json_categorize_type(Oid typoid,
JsonTypeCategory *tcategory,
Oid *outfuncoid)
This chunk broke PostGIS 3.3.0 compiled wit
On Wed, Sep 7, 2022 at 9:53 AM vignesh C wrote:
>
> Thanks for the comments, the attached v47 patch has the changes for the same.
>
V47-0001* looks good to me apart from below minor things. I would like
to commit this tomorrow unless there are more comments on it.
Few minor suggestions:
Re: To Andrew Dunstan
> The "< 17" part was added on 2022-09-03, probably because of this
> breakage.
>
> Recompiling the (unmodified) 3.3.0 against 15beta4 seems to fix the
> problem.
Err sorry, my local build environment was still on beta3.
PostGIS 3.3.0 is broken now with 15beta4:
10:52:29 l
On Wed, Sep 07, 2022 at 11:07:35AM +0200, Christoph Berg wrote:
> I guess either PostgreSQL or PostGIS need to make a new release to fix that.
Postgis is already planning on it.
https://lists.osgeo.org/pipermail/postgis-devel/2022-September/thread.html
--
Justin
On 06.09.22 08:27, Michael Paquier wrote:
On Tue, Sep 06, 2022 at 01:57:53AM -0400, Tom Lane wrote:
Peter Eisentraut writes:
I think renumbering this makes sense. We could just leave the comment
as is if we don't come up with a better wording.
+1, I see no need to change the comment. We ju
Re: Justin Pryzby
> > I guess either PostgreSQL or PostGIS need to make a new release to fix that.
>
> Postgis is already planning on it.
> https://lists.osgeo.org/pipermail/postgis-devel/2022-September/thread.html
Thanks. I was skimming the postgis-devel list, but did not read the
subjects caref
On 04.09.22 20:17, Andres Freund wrote:
I think, as a followup improvement, we should move gramparse.h to
src/backend/parser, and stop installing gram.h, gramparse.h. gramparse.h
already had this note:
* NOTE: this file is only meant to be included in the core parsing files,
* i.e., parser.c
On Wed, Sep 07, 2022 at 03:57:29AM -0500, Justin Pryzby wrote:
> But that's also what'll happen when attempting to replay WAL using a postgres
> build which doesn't support the necessary compression method. I ran into this
> while compiling postgres locally while reporting the recovery_prefetch bu
Hi
On Tue, 6 Sept 2022 at 16:53, Andres Freund wrote:
> Hi,
>
> On 2022-09-06 14:15:56 +0100, Dave Page wrote:
> > Vik and I looked at this a little, and found that we actually don't have
> > generally have GetCurrentTransactionStopTimestamp() at this point - a
> > simple 'select * from pg_class
> On 6 Sep 2022, at 21:44, Tom Lane wrote:
>
> Daniel Gustafsson writes:
>> Doh, of course. The attached is a quick (lightly make check tested) take on
>> allowing 0, but I'm not sure that's what we want?
>
> Actually, wait a second. At least some of these are not dealing
> with kernel FDs bu
On Tue, Sep 6, 2022 at 2:15 PM Amit Kapila wrote:
>
> On Tue, Sep 6, 2022 at 5:08 AM Peter Smith wrote:
> >
> > You are right - that REFRESH PUBLICATION was not necessary for this
> > example. The patch is modified to use your suggested text.
> >
> > PSA v8
> >
>
> LGTM. I'll push this once the t
On Wed, 7 Sept 2022 at 14:34, Amit Kapila wrote:
>
> On Wed, Sep 7, 2022 at 9:53 AM vignesh C wrote:
> >
> > Thanks for the comments, the attached v47 patch has the changes for the
> > same.
> >
>
> V47-0001* looks good to me apart from below minor things. I would like
> to commit this tomorrow
Hello,
Andres Freund , 2 Eyl 2022 Cum, 01:25 tarihinde şunu
yazdı:
> It'd be good to collect some performance numbers justifying this. I'd
> expect
> decent gains if there's e.g. a bytea or timestamptz column involved.
Experimented the binary copy with a quick setup.
- Created a "temp" table w
On Tue, 6 Sept 2022 at 21:33, Justin Pryzby wrote:
>
> On Tue, Sep 06, 2022 at 04:16:02PM +0100, Simon Riggs wrote:
> > New chapter on transaction management, plus a few related changes.
> >
> > Markup and links are not polished yet, so please comment initially on
> > the topics, descriptions and
On Tue, 6 Sept 2022 at 15:17, David Rowley wrote:
>
> On Tue, 6 Sept 2022 at 14:43, Tom Lane wrote:
> > I think MemoryContextContains' charter is to return
> >
> > GetMemoryChunkContext(pointer) == context
> >
> > *except* that instead of asserting what GetMemoryChunkContext asserts,
> >
Hi,
On Thu, Sep 08, 2022 at 12:29:22AM +1200, David Rowley wrote:
>
> I spent some time looking at our existing usages of
> MemoryContextContains() to satisfy myself that we'll only ever pass in
> a pointer to memory allocated by a MemoryContext and pushed this
> patch.
FYI lapwing isn't happy wi
On Thu, 8 Sept 2022 at 01:05, Julien Rouhaud wrote:
> FYI lapwing isn't happy with this patch:
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=lapwing&dt=2022-09-07%2012%3A40%3A16.
Thanks. It does seem to be because of the nodeWindowAgg.c usage of
MemoryContextContains.
I'll look into
On Tue, Sep 6, 2022 at 7:26 PM Jeff Davis wrote:
> There's at least one other difference: if you specify "GRANTED BY su1"
> for a table grant, it still selects the table owner as the grantor;
> whereas if you specify "GRANTED BY su1" for a role grant, it selects
> "su1".
Right. Personally, I'm in
Hi!
I would make two cosmetic changes.
1. I suggest replace description of function bt_report_duplicate() from
```
/*
* Prepare and print an error message for unique constrain violation in
* a btree index under WARNING level. Also set a flag to report ERROR
* at the end of the check.
*/
```
On Thu, 8 Sept 2022 at 01:22, David Rowley wrote:
>
> On Thu, 8 Sept 2022 at 01:05, Julien Rouhaud wrote:
> > FYI lapwing isn't happy with this patch:
> > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=lapwing&dt=2022-09-07%2012%3A40%3A16.
>
> I'll look into it further.
Looks like my an
On Wed, 2022-09-07 at 09:39 -0400, Robert Haas wrote:
> Now that is not to say that we couldn't decide that
> select_best_grantor() got it wrong and choose to break backward
> compatibility in order to fix it ... but I'm not even convinced that
> the alternative behavior you propose is clearly bett
David Rowley writes:
> Looks like my analysis wasn't that good in nodeWindowAgg.c. The
> reason it's crashing is due to int2int4_sum() returning
> Int64GetDatumFast(transdata->sum).
Ugh. I thought for a bit about whether we could define that as wrong,
but it's returning a portion of its input,
On 9/7/22 4:02 AM, Alvaro Herrera wrote:
Hi Jonathan,
On 2022-Sep-06, Jonathan S. Katz wrote:
* [`MERGE`](https://www.postgresql.org/docs/15/sql-merge.html) statements are
explicitly rejected inside of a
[common-table expression](https://www.postgresql.org/docs/15/queries-with.html)
(aka `WITH
On 9/7/22 1:18 AM, Erik Rijkers wrote:
Op 07-09-2022 om 03:40 schreef Jonathan S. Katz:
Hi,
I've attached a draft of the PostgreSQL 15 Beta 4 release
announcement. Please review for correctness and if there are any
omissions.
Please provide feedback on the draft no later than Sep 8, 2022 0:
On 9/7/22 07:46, Drouvot, Bertrand wrote:
> Except the Nit above, that looks all good to me.
A few additional comments:
> +assigned a database role. It is represented as
> +auth_method:identity or
> +NULL if the user has not been authenticated (for
> +example if h
Noah Misch writes:
> On Thu, Sep 01, 2022 at 03:35:52PM -0400, Tom Lane wrote:
>> I think we should reject Aleksander's patch, on the grounds that
>> it's now unnecessary --- or if you want to argue that it's still
>> necessary, then it's woefully inadequate, because there are surely
>> a bunch of
On Wed, Sep 7, 2022 at 10:56 AM Jeff Davis wrote:
> OK. I suppose the best path forward is to just try to improve the
> ability to administer the system without relying as much on superusers,
> which will allow us to safely ignore some of the weirdness caused by
> superusers issuing grants.
Yeah,
On Wed, Aug 31, 2022 at 5:57 PM Michael Paquier wrote:
> On Wed, Aug 31, 2022 at 04:16:29PM -0700, Jacob Champion wrote:
> > OpenSSL should have an API for that (SSL_get_extms_support); I don't
> > know when it was introduced.
>
> This is only available from 1.1.0, meaning that we'd better disable
After looking at the text more carefully, I thought it could use
a deal more help than Robert has given it. I propose the attached.
regards, tom lane
diff --git a/doc/src/sgml/ref/psql-ref.sgml b/doc/src/sgml/ref/psql-ref.sgml
index 186f8c506a..f8112c1500 100644
--- a/doc
On Wed, Sep 07, 2022 at 08:03:09PM +0300, Dmitry Koval wrote:
> Hi!
>
> Patch stop applying due to changes in upstream.
> Here is a rebased version.
This crashes on freebsd with -DRELCACHE_FORCE_RELEASE
https://cirrus-ci.com/task/6565371623768064
https://cirrus-ci.com/task/6145355992530944
Note
Hi,
On 2022-09-06 18:40:49 -0500, Jaime Casanova wrote:
> I'm not sure what is causing this, but I have seen this twice. The
> second time without activity after changing the set of tables in a
> PUBLICATION.
Can you describe the steps to reproduce?
Which git commit does this happen on?
> gdb
As noted upthread at some point, I'm not overly excited about the parser in
filter.c, for maintainability and readability reasons. So, I've reimplemented
the parser in Flex/Bison in the attached patch, which IMHO provides a clear(er)
picture of the grammar and is more per project standards. This
Hello hackers!
Reading docs for the MERGE statement I've found a little error: a
semicolon in middle of a statement and absence of a semicolon in the end
of it.
Key words in subqueries are written in uppercase everywhere in the docs
but not in an example for MERGE. I think it should be adjus
05.09.2022, 11:12, "Kyotaro Horiguchi" : About the test, don't we need the test for non-varchar/bytea staticvariables like "static int inta, intb, intc;"?Good idea, thanks. I have added tests for static int and bytea. The new patch is in the attachment and here https://github.com/andr-sokolov/postg
Greetings,
* Nathan Bossart (nathandboss...@gmail.com) wrote:
> On Tue, Sep 06, 2022 at 11:24:18AM -0400, Robert Haas wrote:
> > On Tue, Sep 6, 2022 at 11:11 AM Stephen Frost wrote:
> >> If we were to make the specific bits depend on the object type as I'm
> >> suggesting, then we'd have 8 bits u
On Thu, 8 Sept 2022 at 03:08, Tom Lane wrote:
> 4. For aset.c, I'd be inclined to have it compute the AllocBlock
> address implied by the putative chunk header, and then run through
> the context's alloc blocks and see if any of them match. If we
> do find a match, and the chunk address is within
On 8/24/22 17:32, Nathan Bossart wrote:
> I'd like to revive this thread, so I've created a commitfest entry [0] and
> attached a hastily rebased patch that compiles and passes the tests. I am
> aiming to spend some more time on this in the near future.
Just to clarify, was Justin's statement upt
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> Jeff Davis's comment in
> http://postgr.es/m/4f8d536a9221bccc5a33bb784dace0ef2310ec4a.ca...@j-davis.com
> reminds me that I need to update this thread based on the patch posted
> over there. That patch allows you to grant membership in one
> On Jul 22, 2022, at 1:37 PM, Nathan Bossart wrote:
>
> The primary motivation for this is to continue chipping away at things that
> require special privileges or even superuser. VACUUM and ANALYZE typically
> require table ownership, database ownership, or superuser. And only
> superusers
On Wed, Sep 07, 2022 at 05:13:44PM -0400, Stephen Frost wrote:
> I disagree that we should put the onus for addressing this on the next
> person who wants to add bits and just willfully use up the last of them
> right now for what strikes me, at least, as a relatively marginal use
> case. If we ha
On Wed, Sep 07, 2022 at 02:53:57PM -0700, Mark Dilger wrote:
> Assuming for the sake of argument that we should create a role something like
> you propose, can you explain why we should draw the line around just VACUUM
> and ANALYZE? I am not arguing for including these other commands, but don't
On Wed, Sep 7, 2022 at 8:49 PM Amit Kapila wrote:
>
> On Tue, Sep 6, 2022 at 2:15 PM Amit Kapila wrote:
> >
> > On Tue, Sep 6, 2022 at 5:08 AM Peter Smith wrote:
> > >
> > > You are right - that REFRESH PUBLICATION was not necessary for this
> > > example. The patch is modified to use your sugge
> On Sep 7, 2022, at 3:21 PM, Nathan Bossart wrote:
>
> There was some previous discussion around adding a pg_maintenance role that
> could perform all of these commands [0]. I didn't intend to draw a line
> around VACUUM and ANALYZE. Those are just the commands I started with.
> If/when the
Greetings,
On Wed, Sep 7, 2022 at 18:11 Nathan Bossart
wrote:
> On Wed, Sep 07, 2022 at 05:13:44PM -0400, Stephen Frost wrote:
> > I disagree that we should put the onus for addressing this on the next
> > person who wants to add bits and just willfully use up the last of them
> > right now for
> On Sep 7, 2022, at 4:09 PM, Stephen Frost wrote:
>
> Calling this a redesign is over-stating things, imv … and I’d much rather
> have the per-relation granularity than predefined roles for this, so there is
> that to consider too, perhaps.
Ok, now I'm a bit lost. If I want to use Nathan'
On Thu, 8 Sept 2022 at 09:32, David Rowley wrote:
>
> On Thu, 8 Sept 2022 at 03:08, Tom Lane wrote:
> > Step 4 is annoyingly expensive, but perhaps not too awful given
> > the way we step up alloc block sizes. We should make sure that
> > any context we want to use MemoryContextContains with is
At Wed, 7 Sep 2022 11:11:11 +0200, "Drouvot, Bertrand"
wrote in
> On 9/6/22 7:53 AM, Kyotaro Horiguchi wrote:
> > So, I'm fine with just replacing the parent context at the three
> > places.
Looks good to me. To make sure, I ran make check-world with adding an
assertion check that all non-topl
On Wed, Sep 07, 2022 at 08:48:43AM -0700, Jacob Champion wrote:
> Also, this function's placement in the docs (with the System Catalog
> Information Functions) seems wrong to me. I think it should go up above
> in the Session Information Functions, with current_user et al.
Yeah, this had better us
Hi,
There is a buildfarm failure on mylodon at [1] because of the new test
added. I will analyse and share the findings for the same.
[1] -
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=mylodon&dt=2022-09-08%2001%3A40%3A27
Regards,
Vignesh
On Wed, 7 Sept 2022 at 17:10, vignesh C wro
On Thu, Sep 8, 2022 at 7:57 AM vignesh C wrote:
>
> There is a buildfarm failure on mylodon at [1] because of the new test
> added. I will analyse and share the findings for the same.
>
> [1] -
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=mylodon&dt=2022-09-08%2001%3A40%3A27
>
The l
On Tue, Sep 6, 2022 at 5:19 PM Aleksander Alekseev
wrote:
>
> Hi John,
>
> Thanks for the feedback.
>
> > Maybe "00xx 4-byte length word (aligned)," is more clear about
> > what is aligned. Also, adding all those xxx's obscures the point that
> > we only need to examine one byte to figure out
On Wed, Sep 7, 2022 at 1:45 PM Peter Eisentraut
wrote:
>
> On 05.09.22 23:34, Tom Lane wrote:
> > Peter Eisentraut writes:
> >> Why is this being proposed?
> >
> > Andres is annoyed by the long build time of ecpg, which he has to
> > wait for whether he wants to test it or not. I could imagine t
On Thu, 8 Sept 2022 at 08:23, Amit Kapila wrote:
>
> On Thu, Sep 8, 2022 at 7:57 AM vignesh C wrote:
> >
> > There is a buildfarm failure on mylodon at [1] because of the new test
> > added. I will analyse and share the findings for the same.
> >
> > [1] -
> > https://buildfarm.postgresql.org/cg
On Thu, 8 Sept 2022 at 08:57, vignesh C wrote:
>
> On Thu, 8 Sept 2022 at 08:23, Amit Kapila wrote:
> >
> > On Thu, Sep 8, 2022 at 7:57 AM vignesh C wrote:
> > >
> > > There is a buildfarm failure on mylodon at [1] because of the new test
> > > added. I will analyse and share the findings for th
At Wed, 7 Sep 2022 12:16:29 +0200, "Drouvot, Bertrand"
wrote in
> Also, rounding to zero wouldn't occur with "just" displaying
> "oldestLSN - restart_lsn" (as proposed upthread).
..
> Yeah right, but that's already the case in some part of the code, like
> for example in arrayfuncs.c:
Fair poin
On Wed, Sep 07, 2022 at 06:19:42PM -0700, Jeremy Schneider wrote:
> I didn't fully debug yet, but here's the backtrace on my 14.4 build with
> the patch
What happens on HEAD? That would be the target branch for a new
feature.
--
Michael
signature.asc
Description: PGP signature
On Fri, Sep 2, 2022 at 3:19 PM Kyotaro Horiguchi
wrote:
>
> At Fri, 2 Sep 2022 13:43:50 +0700, John Naylor
> wrote in
> > If there is any doubt about including all of Cf, we could also just
> > add a branch in wchar.c to hard-code the 200B-200F range.
>
> If every way has defect to the similar e
On Wed, Sep 07, 2022 at 07:09:05PM -0400, Stephen Frost wrote:
> Yes, that seems to be the consensus among those involved in this thread
> thus far. Basically, I imagine this involves passing around the object
> type along with the acl info and then using that to check the bits and
> such. I doub
čt 8. 9. 2022 v 7:39 odesílatel John Naylor
napsal:
> On Fri, Sep 2, 2022 at 3:19 PM Kyotaro Horiguchi
> wrote:
> >
> > At Fri, 2 Sep 2022 13:43:50 +0700, John Naylor <
> john.nay...@enterprisedb.com> wrote in
> > > If there is any doubt about including all of Cf, we could also just
> > > add a
On Thu, Sep 08, 2022 at 02:23:19PM +0900, Michael Paquier wrote:
> On Wed, Sep 07, 2022 at 06:19:42PM -0700, Jeremy Schneider wrote:
> > I didn't fully debug yet, but here's the backtrace on my 14.4 build with
> > the patch
>
> What happens on HEAD? That would be the target branch for a new
> fea
On Mon, Sep 5, 2022 at 6:34 PM houzj.f...@fujitsu.com
wrote:
>
> Attach the correct patch set this time.
>
Few comments on v28-0001*:
===
1.
+ /* Whether the worker is processing a transaction. */
+ bool in_use;
I think this same comment applies to in_parallel_apply_xact flag
77 matches
Mail list logo