On Mon, Nov 22, 2021 at 03:57:45PM -0800, Andres Freund wrote:
> It does however change symbol binding, basically making all symbols bound
> eagerly. Which I guess theoretically could be considered an ABI change,
> because it removes the ability to intercept symbols referenced in a previously
>
On Tue, Nov 23, 2021 at 4:31 AM Tom Lane wrote:
> "Bossart, Nathan" writes:
> > I periodically hear rumblings about this behavior as well. At the
> > very least, it certainly ought to be documented if it isn't yet. I
> > wouldn't mind trying my hand at that. Perhaps we could also add a new
>
On 11/22/21 9:42 PM, Jeremy Schneider wrote:
> On 11/22/21 12:31, Tom Lane wrote:
>> "Bossart, Nathan" writes:
>>> I periodically hear rumblings about this behavior as well. At the
>>> very least, it certainly ought to be documented if it isn't yet. I
>>> wouldn't mind trying my hand at
The PG docs are not quite as clear as they might be regarding the
default value of the "partition_via_partition_root" option.
This small change originated from the row-filter thread [RF], but then
it was decided it should really be a separate patch (hence this post).
[Tomas 11/7] comment 2: "Why
On Thu, Nov 11, 2021 at 4:34 AM Peter Eisentraut
wrote:
>
> I have reviewed your patch
> referential-actions-on-delete-only-set-cols-v3.patch. Attached are two
> patches that go on top of yours that contain my recommended changes.
>
> Basically, this all looks pretty good to me. My changes are
On Mon, Nov 22, 2021 at 10:21 PM Zhihong Yu wrote:
>
> Hi,
> + If a foreign key with a SET NULL or SET
> + DEFAULT delete action, which columns should be updated.
>
> which columns should be updated -> the columns that should be updated
Done.
> + if (fk_del_set_cols)
> + {
> +
Hi,
There's two related, but somewhat different aspects to $subject.
TL;DR: We use use -fvisibility=hidden + explicit symbol visiblity,
-Wl,-Bdynamic, -fno-plt
1) Cross-translation-unit calls in extension library
A while ago I was looking at a profile of a workload that spent a good chunk
of
On Mon, Nov 22, 2021 at 7:47 PM Alvaro Herrera wrote:
>
> On 2021-Nov-22, Amit Kapila wrote:
>
> > +1 for this change. This seems to be introduced by commit ec5896aed3
> > [1] and I think it is just a typo to name these macros starting with
> > SnapBuildOnDisk* unless I am missing something.
>
>
On Tue, Nov 23, 2021 at 9:30 AM Tomas Vondra
wrote:
> On 11/22/21 9:42 PM, Jeremy Schneider wrote:
> > On 11/22/21 12:31, Tom Lane wrote:
> >> "Bossart, Nathan" writes:
> >>> I periodically hear rumblings about this behavior as well. At the
> >>> very least, it certainly ought to be documented
There was an earlier comment by Andres that asyncXactLSN should also be
atomic, to avoid an ugly spinlock interaction with the new atomic-based
logwrtResult. The 0002 here is an attempt at doing that; I found that
it also needed to change WalWriterSleeping to use atomics, to avoid
Hi,
On 2021-09-25 22:05:43 +0200, Hannu Krosing wrote:
> If our aim is just to make sure that all user-visible data in
> *transactional* tables is consistent with sequence state then one
> very much simplified approach to this could be to track the results of
> nextval() calls in a transaction
On 11/23/21 5:22 AM, Dilip Kumar wrote:
> On Tue, Nov 23, 2021 at 9:30 AM Tomas Vondra
> wrote:
>
>> On 11/22/21 9:42 PM, Jeremy Schneider wrote:
>>> On 11/22/21 12:31, Tom Lane wrote:
"Bossart, Nathan" writes:
> I periodically hear rumblings about this behavior as well. At the
>
On Sat, Nov 20, 2021 at 1:11 AM Masahiko Sawada wrote:
>
> I'm concerned that these new names will introduce confusion; if we
> have last_error_relid, last_error_command, last_error_message,
> last_error_time, and last_error_xid, I think users might think that
> first_error_time is the timestamp
On Mon, Nov 22, 2021 at 11:29 AM Andres Freund wrote:
> Hm. I'm a bit doubtful that there's all that many cases where it's worth not
> pruning during vacuum. However, it seems much more common for opportunistic
> pruning during non-write accesses.
Fair enough. I just wanted to suggest an
On Mon, Nov 22, 2021 6:48 PM Amit Kapila wrote:
> On Mon, Nov 22, 2021 at 1:45 PM Amit Langote
> wrote:
> >
> > On Sat, Nov 20, 2021 at 8:31 PM Amit Kapila
> wrote:
> > > On Fri, Nov 19, 2021 at 10:58 AM Amit Kapila
> wrote:
> > > > On Fri, Nov 19, 2021 at 7:19 AM Amit Langote
> wrote:
> > >
On Mon, Nov 22, 2021 at 8:04 PM Paul Martinez wrote:
> On Thu, Nov 11, 2021 at 4:34 AM Peter Eisentraut
> wrote:
> >
> > I have reviewed your patch
> > referential-actions-on-delete-only-set-cols-v3.patch. Attached are two
> > patches that go on top of yours that contain my recommended
Hi,
On 2021-11-22 20:13:28 -0500, Bruce Momjian wrote:
> On Mon, Nov 22, 2021 at 03:57:45PM -0800, Andres Freund wrote:
> > It does however change symbol binding, basically making all symbols bound
> > eagerly. Which I guess theoretically could be considered an ABI change,
> > because it removes
Hi,
The replication slots data is stored in binary format on the disk under the
pg_replslot/<> directory which isn't human readable. If the
server is crashed/down (for whatever reasons) and unable to come up,
currently there's no way for the user/admin/developer to know what were all
the
> On Nov 16, 2021, at 7:03 AM, Robert Haas wrote:
>
> It's also going to be important to think about what happens with
> extension GUCs. If somebody installs an extension, we can't ask them
> to perform a manual step in order to be able to grant privileges. And
> if somebody then loads up a
Hi,
Attached patch covers a case where TLI in the filename for a
record being read is different from where it belongs to. In other
words, it covers following case noted in StartupXLOG():
/*
* EndOfLogTLI is the TLI in the filename of the XLOG segment containing
* the end-of-log. It could be
On Thu, Nov 18, 2021 at 7:04 AM Peter Smith wrote:
>
> PSA new set of v40* patches.
Few comments:
1) When a table is added to the publication, replica identity is
checked. But while modifying the publish action to include
delete/update, replica identity is not checked for the existing
tables. I
On 17/09/2021 06:10, Kyotaro Horiguchi wrote:
recoveryStopReason is always acquired but it is used only after
archive recovery. I'm not sure about reason for the variable to
live in that wide context. Couldn't we remove the variable then
call getRecoveryStopReason() directly at the
On Sat, 2021-11-20 at 16:16 -0500, Tom Lane wrote:
> One more point is that the proposed business about
>
> * ImpersonateDatabaseUser will either succeed silently (0-RTT), or
> fail. Upon failure, no further commands will be processed until
> ImpersonateDatabaseUser succeeds.
>
> seems to
On Tue, Nov 23, 2021 at 7:28 AM houzj.f...@fujitsu.com
wrote:
>
> On Mon, Nov 22, 2021 6:48 PM Amit Kapila wrote:
> > On Mon, Nov 22, 2021 at 1:45 PM Amit Langote
> > wrote:
> > >
> > > On Sat, Nov 20, 2021 at 8:31 PM Amit Kapila
> > wrote:
> > > > On Fri, Nov 19, 2021 at 10:58 AM Amit Kapila
On Thursday, November 18, 2021 9:34 AM Peter Smith
wrote:
>
> PSA new set of v40* patches.
>
I found a problem on v40. The check for Replica Identity in WHERE clause is not
working properly.
For example:
postgres=# create table tbl(a int primary key, b int);
CREATE TABLE
postgres=# create
Hi,
On 2021-11-22 17:07:46 -0800, Peter Geoghegan wrote:
> Sure, it wouldn't be okay to wait *indefinitely* for any one pin in a
> non-aggressive VACUUM -- so "at least waiting for one or two pins
> during non-aggressive VACUUM" might not have been the best way of
> expressing the idea that I
Andres Freund writes:
> Basically they way we currently build our extensions, the compiler & linker
> assume every symbol inside the extension libraries needs to be interceptable
> by the main binary. Which means that all function calls to symbols visible
> outside the current translation unit
Hi,
On 2021-11-22 17:32:21 -0500, Tom Lane wrote:
> > The easier approach for this class of issues is to use the linker option
> > -Bsymbolic.
>
> I don't recall details, but we've previously rejected the idea of
> trying to use -Bsymbolic widely; apparently it has undesirable
> side-effects on
On Tue, Nov 23, 2021 at 4:40 PM tanghy.f...@fujitsu.com
wrote:
>
> On Thursday, November 18, 2021 9:34 AM Peter Smith
> wrote:
> >
> > PSA new set of v40* patches.
> >
>
> I found a problem on v40. The check for Replica Identity in WHERE clause is
> not working properly.
>
> For example:
>
On Mon, Nov 22, 2021 at 03:44:37PM +0300, Alexander Kuzmenkov wrote:
> On 21.11.2021 07:53, Ilya Anfimov wrote:
> > DISCLAIMER: I am both seeing this first time and I don't have a
> > good understanding of the PosgreSQL development practices.
>
> > pure evil
> > ridiculous
> No worries, at
> 21 нояб. 2021 г., в 23:58, Michail Nikolaev
> написал(а):
>
>
Write barrier must be issued after write, not before.
Don't we need to issue read barrier too?
Best regards, Andrey Borodin.
Hello, Andrey.
> Write barrier must be issued after write, not before.
> Don't we need to issue read barrier too?
The write barrier is issued after the changes to KnownAssignedXidsNext
and KnownAssignedXidsValid arrays and before the update of
headKnownAssignedXids.
So, it seems to be correct.
On Sat, Nov 20, 2021 at 8:31 PM Amit Kapila wrote:
> On Fri, Nov 19, 2021 at 10:58 AM Amit Kapila wrote:
> > On Fri, Nov 19, 2021 at 7:19 AM Amit Langote
> > wrote:
> > > The problematic case is attaching the partition *after* the subscriber
> > > has already marked the root parent as synced
On Mon, Nov 22, 2021 at 1:45 PM Amit Langote wrote:
>
> On Sat, Nov 20, 2021 at 8:31 PM Amit Kapila wrote:
> > On Fri, Nov 19, 2021 at 10:58 AM Amit Kapila
> > wrote:
> > > On Fri, Nov 19, 2021 at 7:19 AM Amit Langote
> > > wrote:
> > > > The problematic case is attaching the partition
On Fri, Nov 19, 2021 at 2:05 PM Soumyadeep Chakraborty
wrote:
>
> Hi Daniel,
>
> Thanks for checking in on this patch.
> Attached rebased version.
Hi, I've not gone through the patch or this thread entirely, yet, can
you please confirm if there's any relation between this thread and
another one
On Tue, Nov 16, 2021 at 11:23 AM Masahiko Sawada wrote:
>
> I've incorporated these comments and attached an updated patch.
>
Review comments:
1.
index_can_participate_parallel_vacuum()
{
..
+ /*
+ * Not safe, if the index supports parallel cleanup conditionally,
+ * but we have
Currently there's a test [1] in the regression suite that ensures that
a SAVEPOINT cannot be initialized outside a transaction.
Instead of throwing an error, if we allowed it such that a SAVEPOINT
outside a transaction implicitly started a transaction, and the
corresponding ROLLBACK TO or RELEASE
On 19.11.21 08:31, Michael Paquier wrote:
On Mon, Nov 01, 2021 at 07:28:16AM +0100, Peter Eisentraut wrote:
Small rebase of this patch set.
Regarding 0001, I find the existing code a bit more self-documenting
if we keep those checks flagInhAttrs() and guessConstraintInheritance().
So I would
> On 21 Nov 2021, at 03:05, Todd Hubers wrote:
> 10) Tom said: "How would this interact with the "on login" triggers that
> people keep asking for?
>
> That's a good point. I would imagine that SET ROLE (which is currently
> unsuitable) would have the same requirement. The answer is Shared
> On 19 Nov 2021, at 04:59, Bharath Rupireddy
> wrote:
> It seems like some of the XLogReaderAllocate failure check errors are
> not having errdetail "Failed while allocating a WAL reading
> processor." but just the errmsg "out of memory". The "out of memory"
> message without the errdetail is
On Sun, Nov 14, 2021 at 11:45 AM Dilip Kumar wrote:
>
> On Wed, Oct 27, 2021 at 1:01 AM Mahendra Singh Thalor
> wrote:
>
> I was going through and patch and trying to understand the idea that
> what we are trying to achieve here. So basically, generally we start
> the WAL receiver when we want
Hi,
I cannot compile postgresql for armv7. I tested a bunch of versions of gcc
and all have the same issue. Sometimes disabling optimization allows me to
compile failed files but it is not a rule. The same error will happen in
another file and changing optimization parameters or lto options does
Hi,
I'm seeing the following annoying build warnings on Windows (without
asserts, latest Postgres source):
pruneheap.c(858): warning C4101: 'htup': unreferenced local variable
pruneheap.c(870): warning C4101: 'tolp': unreferenced local variable
I notice that these are also reported here: [1]
Hi hackers,
>
> > I guess the declaration needs PGDLLIMPORT.
>
> Indeed, thanks!
>
> Attached v16 adds that.
It looks like the patch is in pretty good shape. I noticed that the
return value of pg_prng_strong_seed() is not checked in several
places, also there was a typo in pg_trgm.c. The
On Mon, Nov 22, 2021 at 4:25 PM Bharath Rupireddy
wrote:
>
> On Sun, Nov 14, 2021 at 11:45 AM Dilip Kumar wrote:
> >
> > On Wed, Oct 27, 2021 at 1:01 AM Mahendra Singh Thalor
> > wrote:
> >
> > I was going through and patch and trying to understand the idea that
> > what we are trying to
> On 22 Nov 2021, at 12:10, Greg Nancarrow wrote:
> I've attached a patch to fix these warnings.
LGTM.
--
Daniel Gustafsson https://vmware.com/
On Sat, Nov 20, 2021 at 7:43 PM Bharath Rupireddy
wrote:
>
> It seems like the same macro names for
> SnapBuildOnDiskNotChecksummedSize and SnapBuildOnDiskChecksummedSize
> are being used in slot.c and snapbuild.c. I think, in slot.c, we can
> rename them to
On 21.11.2021 07:53, Ilya Anfimov wrote:
DISCLAIMER: I am both seeing this first time and I don't have a
good understanding of the PosgreSQL development practices.
pure evil
ridiculous
No worries, at least you got the etiquette just right.
There are two points in your mail that I'd like
> On 10 Nov 2021, at 18:14, David Christensen
> wrote:
> Modulo other issues/discussions, here is a version of this patch..
This patch fails to compile since you renamed the if_not_exists member in
CreateRoleStmt but still set it in the parser.
--
Daniel Gustafsson
On Mon, Nov 22, 2021 at 4:50 AM Gurjeet Singh wrote:
> Instead of throwing an error, if we allowed it such that a SAVEPOINT
> outside a transaction implicitly started a transaction, and the
> corresponding ROLLBACK TO or RELEASE command finished that
> transaction, I believe it will provide a
On Mon, 2021-11-22 at 15:43 +0800, Andy Fan wrote:
> > > The reason is because we never flush the xlog for the nextval_internal
> > > for the above case. So if
> > > the system crashes, there is nothing to redo from. It can be fixed
> > > with the following online change
> > > code.
> > >
> > >
On Thu, 11 Nov 2021 at 18:08, David Rowley wrote:
>
> On Thu, 30 Sept 2021 at 10:54, Tom Lane wrote:
> > Actually, the more I look at this the more unhappy I get, because
> > it's becoming clear that you have made unfounded semantic
> > assumptions. The hash functions generally only promise
Le lun. 22 nov. 2021 à 19:58, Daniel Gustafsson a écrit :
> > On 19 Nov 2021, at 04:59, Bharath Rupireddy <
> bharath.rupireddyforpostg...@gmail.com> wrote:
>
> > It seems like some of the XLogReaderAllocate failure check errors are
> > not having errdetail "Failed while allocating a WAL reading
On Mon, Nov 22, 2021 at 6:49 AM Daniel Gustafsson wrote:
> > On 10 Nov 2021, at 18:14, David Christensen <
> david.christen...@crunchydata.com> wrote:
>
> > Modulo other issues/discussions, here is a version of this patch..
>
> This patch fails to compile since you renamed the if_not_exists
On Mon, Nov 22, 2021 at 12:46 AM Jeevan Ladhe
wrote:
> Fair enough. But, still I have a doubt in mind what benefit would that
> really bring to us here, because we are immediately also freeing the
> lz4buf without using it anywhere.
Yeah, I'm also doubtful about that. If we're freeng the
On Mon, Nov 22, 2021 at 7:14 AM Greg Nancarrow wrote:
>
> On Thu, Nov 18, 2021 at 12:33 PM Peter Smith wrote:
> >
> > PSA new set of v40* patches.
> >
I have a few more comments on 0007,
@@ -783,9 +887,28 @@ pgoutput_row_filter(PGOutputData *data, Relation
relation, HeapTuple oldtuple, H
Marek Kulik writes:
> I cannot compile postgresql for armv7. I tested a bunch of versions of gcc
> and all have the same issue.
> Maybe someone encountered something similar. I'm using Fedora Rawhide. Here
> is the error:
> sh-5.1# gcc -I../../../../src/include -I/usr/include/libxml2
> -c
Daniel Gustafsson writes:
> Fair enough. Looking at where we use PG_USED_FOR_ASSERTS_ONLY (and where it
> works), these two warnings are the only places where we apply it to a pointer
> typedef (apart from one place where the variable is indeed used outside of
> asserts). Since it clearly works
On 22.11.21 01:47, Tomas Vondra wrote:
So I think just decoding the sequence tuples is a better solution - for
large transactions (consuming many values from the sequence) it may be
more expensive (i.e. send more records to replica). But I doubt that
matters too much - it's likely negligible
On 2021-Nov-22, Amit Kapila wrote:
> +1 for this change. This seems to be introduced by commit ec5896aed3
> [1] and I think it is just a typo to name these macros starting with
> SnapBuildOnDisk* unless I am missing something.
Yeah, it looks pretty weird. +1 for the change on consistency
On 2021-Nov-22, Daniel Gustafsson wrote:
> > On 22 Nov 2021, at 12:10, Greg Nancarrow wrote:
>
> > I've attached a patch to fix these warnings.
>
> LGTM.
.. but see
https://postgr.es/m/cah2-wznwwu+9on9nzcnztk7ua238mctgpxyr1ty7u_msn5z...@mail.gmail.com
where this was already discussed. I
Hi,
I cannot compile postgresql for armv7. I tested a bunch of versions of gcc
and all have the same issue. Sometimes disabling optimization allows me to
compile failed files but it is not a rule. The same error will happen in
another file and changing optimization parameters or lto options does
On 2021-Oct-31, Zhihong Yu wrote:
> It seems there were some missing words in one of the comments.
>
> See patch attached.
You're right. Fix pushed, thanks.
--
Álvaro Herrera Valdivia, Chile — https://www.EnterpriseDB.com/
Hi,
This example in the docs declares a function returning an anonymous
2-component record:
CREATE FUNCTION dup(in int, out f1 int, out f2 text)
AS $$ SELECT $1, CAST($1 AS text) || ' is text' $$
LANGUAGE SQL;
The same declaration can be changed to have just one OUT parameter:
CREATE
On Mon, Nov 22, 2021 at 2:48 PM Kyotaro Horiguchi
wrote:
>
> At Mon, 22 Nov 2021 15:38:23 +0900 (JST), Kyotaro Horiguchi
> wrote in
> > * queryId is supposed to be a valid value, otherwise this function dosen't
> > * calucate it by its own as before then returns immediately.
>
> Mmm. That's
Alvaro Herrera writes:
> .. but see
> https://postgr.es/m/cah2-wznwwu+9on9nzcnztk7ua238mctgpxyr1ty7u_msn5z...@mail.gmail.com
> where this was already discussed. I think if we're going to workaround
> PG_USED_FOR_ASSERTS_ONLY not actually working, we may as well get rid of
> it entirely. My
> On 22 Nov 2021, at 16:06, Tom Lane wrote:
>
> Alvaro Herrera writes:
>> .. but see
>> https://postgr.es/m/cah2-wznwwu+9on9nzcnztk7ua238mctgpxyr1ty7u_msn5z...@mail.gmail.com
>> where this was already discussed. I think if we're going to workaround
>> PG_USED_FOR_ASSERTS_ONLY not actually
> On 22. 11. 2021, at 16:44, Peter Eisentraut
> wrote:
>
> On 22.11.21 01:47, Tomas Vondra wrote:
>> So I think just decoding the sequence tuples is a better solution - for
>> large transactions (consuming many values from the sequence) it may be more
>> expensive (i.e. send more records to
In an attempt to get this patch set off the ground again, I took a
look at the first 5 patches.
0001: This one is a very small documentation update for pg_stat_file
to point out that isdir will be true for symbolic links to
directories. Given this is true, I think the patch looks good.
0002:
po 22. 11. 2021 v 18:43 odesílatel Chapman Flack
napsal:
> On 11/22/21 11:59, Pavel Stehule wrote:
> > And if we allow RETURNS RECORD, then there will be new inconsistency
> > between OUT variables and RETURNS TABLE
>
> I don't really see it as a new inconsistency, so much as the same old
>
Hi,
On 2021-11-21 18:13:51 -0800, Peter Geoghegan wrote:
> I have heard many stories about anti-wraparound/aggressive VACUUMs
> where the cure (which suddenly made autovacuum workers
> non-cancellable) was worse than the disease (not actually much danger
> of wraparound failure). For example:
>
On 11/21/21, 11:15 AM, "Tom Lane" wrote:
> "Bossart, Nathan" writes:
>> Yeah, I was looking for a way to simplify this, too. Your approach
>> seems reasonable enough to me.
>
> Hearing no contrary opinions, pushed that way.
Thanks!
Nathan
On 11/22/21, 5:10 AM, "Laurenz Albe" wrote:
> On Mon, 2021-11-22 at 15:43 +0800, Andy Fan wrote:
>> The performance argument was expected before this writing. If we look at the
>> nextval_interval more carefully, we can find it would not flush the xlog
>> every
>> time even the sequence's
Chapman Flack writes:
> The same declaration can be changed to have just one OUT parameter:
> CREATE FUNCTION dup(in int, out f text)
> AS $$ SELECT CAST($1 AS text) || ' is text' $$
> LANGUAGE SQL;
> But it then behaves as a function returning a text scalar, not a record.
Yup, that's
On 2021-Oct-28, Bharath Rupireddy wrote:
> Thanks all for reviewing this. Here's the CF entry -
> https://commitfest.postgresql.org/35/3378/
Thanks, pushed. I changed a couple of things though -- notably changed
the elog() to ereport() as suggested by Nathan early on, but never
materialized in
> Marek Kulik writes:
>> I cannot compile postgresql for armv7. I tested a bunch of versions of gcc
>> and all have the same issue.
FWIW, I just tried a build with --enable-dtrace on up-to-date Fedora 35
aarch64, and that worked fine. So this definitely seems like a problem
in the toolchain not
Hi
po 22. 11. 2021 v 17:00 odesílatel Chapman Flack
napsal:
> Hi,
>
> This example in the docs declares a function returning an anonymous
> 2-component record:
>
> CREATE FUNCTION dup(in int, out f1 int, out f2 text)
> AS $$ SELECT $1, CAST($1 AS text) || ' is text' $$
> LANGUAGE SQL;
>
Hi Robert,
Please find the lz4 compression patch here that basically has:
1. Documentation
2. pgindent run over it.
3. your comments addressed for using "+="
I have not included the compression level per your comment below:
-
> "On second thought, maybe we don't need to do this. There's
On 11/22/21 11:15, Tom Lane wrote:
> Yup, that's intentional, and documented.
I think I found where it's documented; nothing under argmode/column_type
/column_name, but just enough under rettype to entail the current behavior.
> It seems more useful to allow you to declare a scalar-returning
On 2021-Nov-19, Bharath Rupireddy wrote:
> It seems like some of the XLogReaderAllocate failure check errors are
> not having errdetail "Failed while allocating a WAL reading
> processor." but just the errmsg "out of memory". The "out of memory"
> message without the errdetail is too generic and
On 11/22/21 11:59, Pavel Stehule wrote:
> And if we allow RETURNS RECORD, then there will be new inconsistency
> between OUT variables and RETURNS TABLE
I don't really see it as a new inconsistency, so much as the same old
inconsistency but with an escape hatch if you really mean the other thing.
Hi Bharath,
Yes, that thread has been discussed here. Asim had x-posted the patch to
[1]. This thread
was more recent when Ashwin and I picked up the patch in Aug 2021, so we
continued here.
The patch has been significantly updated by us, addressing Michael's long
outstanding feedback.
Regards,
"Bossart, Nathan" writes:
> I periodically hear rumblings about this behavior as well. At the
> very least, it certainly ought to be documented if it isn't yet. I
> wouldn't mind trying my hand at that. Perhaps we could also add a new
> configuration parameter if users really want to take the
On 11/22/21 12:31, Tom Lane wrote:
> "Bossart, Nathan" writes:
>> I periodically hear rumblings about this behavior as well. At the
>> very least, it certainly ought to be documented if it isn't yet. I
>> wouldn't mind trying my hand at that. Perhaps we could also add a new
>> configuration
84 matches
Mail list logo
