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 least
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 f
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 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 dif
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:
> post
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 want
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 pu
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 replicati
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
> v
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)
> + {
> +
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
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 changes.
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 m
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 that.
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 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.
>
> Y
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 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
>
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 t
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
> loa
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 re
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 explorat
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
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 at
> 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 dif
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 s
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
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 nee
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
XLogSetAsyncXact
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 t
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 par
"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 p
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,
S
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 cachesi
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
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
> incon
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: Thi
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 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
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;
>
> 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
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 l
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 func
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 t
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 i
> 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
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 FU
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 co
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 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/
> 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 worki
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 -o
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 prefe
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 ba
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
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 n
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 think
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 grounds
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 compress
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 correcte
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 membe
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 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 unif
> 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 https://vmware
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 t
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 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 t
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 ReplicationSlotOnDiskNotChecksummedSize
> 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/
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]
I'
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 achieve
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 that
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 n
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 t
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 a
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 *after
> 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 Fun
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
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 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
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. We
> 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.
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 an
84 matches
Mail list logo
