On Wed, Nov 3, 2021 at 11:37 AM Peter Smith wrote:
>
> While you are changing these, maybe also change:
>
> Before: PUBLICATIONOBJ..._CURRSCHEMA
> After: PUBLICATIONOBJ..._CUR_SCHEMA
>
> Which seems more readable to me.
Thanks for the comment, the attached patch has the changes for the same.
While you are changing these, maybe also change:
Before: PUBLICATIONOBJ..._CURRSCHEMA
After: PUBLICATIONOBJ..._CUR_SCHEMA
Which seems more readable to me.
--
Kind Regards,
Peter Smith.
Fujitsu Australia
On Wed, Nov 3, 2021 at 11:07 AM houzj.f...@fujitsu.com
wrote:
>
> On Wed, Nov 3, 2021 12:25 PM vignesh C wrote:
> > On Wed, Nov 3, 2021 at 8:30 AM Amit Kapila
> > wrote:
> > >
> > > On Tue, Nov 2, 2021 at 8:13 PM Tomas Vondra
> > > wrote:
> > > >
> > > >
> > > > >
> > > > > Yeah, that is also
Hi,
I took a quick look at the latest patch version. In general the patch
looks pretty complete and clean, and for now I have only some basic
comments. The attached patch tweaks some of this, along with a couple
additional minor changes that I'll not discuss here.
1) Not sure why we need to
> On 30 Jun 2021, at 11:59, Simon Riggs wrote:
> For PITR, getRecordTimestamp() did not include all record types that
> contain times.
> Add handling for checkpoints, end of recovery and prepared xact record types.
+
This breaks doc compilation, and looks like a stray tag as you want this
Hi,
I looked at this patch today - it's pretty simple and in pretty good
shape, I can't think of anything that'd need fixing. Perhaps the test
might also do EXPLAIN like for other types, to verify the new index is
actually used. But that's minor enough to handle during commit.
I've marked this
On Thu, Oct 28, 2021 at 1:55 PM Amit Langote wrote:
>
> On Thu, Oct 28, 2021 at 4:35 PM houzj.f...@fujitsu.com
> wrote:
> > As there are basically two separate issues mentioned in the thread, I tried
> > to
> > summarize the discussion so far which might be helpful to others.
> >
> > * The
On Wed, Nov 03, 2021 at 11:07:58AM +0100, Vik Fearing wrote:
> On 11/2/21 12:19 PM, Himanshu Upadhyaya wrote:
> > Hi,
> >
> > Trying to insert NULL value to the Identity column defined by "GENERATED BY
> > DEFAULT" is disallowed, but there can be use cases where the user would
> > like to have an
As a preliminary comment, it would be quite useful to get Tom Lane's
opinion on this, since it's not an area I understand especially well,
and I think he understands it better than anyone.
On Fri, May 7, 2021 at 12:30 PM James Coleman wrote:
> The basic idea is that we need to track (both on
> On 1 Nov 2021, at 14:38, Daniel Gustafsson wrote:
>
> It is now November 1st AOE and thus the 2021-11 commitfest is now in progress.
> I've switched the status and opened 2022-01 for new patches, but noone has so
> far raised their hand to run it AFAICT? Do we have a volunteer Commitfest
>
This patch no longer applies on top of HEAD, please submit a rebased version.
--
Daniel Gustafsson https://vmware.com/
> On 30 Oct 2021, at 14:11, Peter Eisentraut
> wrote:
>
> On 24.08.21 11:13, Peter Eisentraut wrote:
>> So I'm tempted to suggest that we remove the built-in, non-OpenSSL cipher
>> and hash implementations in pgcrypto (basically INT_SRCS in
>> pgcrypto/Makefile), and then also pursue the
On Tue, Nov 2, 2021 at 12:46 AM Robert Haas wrote:
>
> [...]
> I would like to clean this up. Attached is a series of patches which
> try to do that. For ease of review, this is separated out into quite a
> few separate patches, but most likely we'd combine some of them for
> commit. Patches 0001
> On 2 Nov 2021, at 10:12, Alexander Pyhalov wrote:
> Updated and rebased patch.
+ state = (Int128AggState *) palloc0(sizeof(Int128AggState));
+ state->calcSumX2 = false;
+
+ if (!PG_ARGISNULL(0))
+ {
+#ifdef HAVE_INT128
+ do_int128_accum(state, (int128)
> On 15 Oct 2021, at 23:54, Cary Huang wrote:
> I scanned through the GUC list and found that the following parameters can
> potentially be categorized in the "special_disabled0" group, just for your
> reference.
This patch no longer applies, can you please submit a rebased version? Also,
do
This patch doesn't compile on Windows according to Appveyor, seemingly because
of a syntax error in the new win32ntdll.h file, but the MSVC logs are hard on
the eye so it might be unrelated.
--
Daniel Gustafsson https://vmware.com/
On Tue, Nov 2, 2021 at 11:18 PM Jan Wieck wrote:
> The thing I don't want to see us doing is *nothing at all* when pretty
> much everyone with some customer experience in the field is saying "this
> is the information we want to see post incident and nobody has it so we
> sit there waiting for
> On 26 Jul 2021, at 09:33, Bharath Rupireddy
> wrote:
> PSA v7.
This patch no longer applies on top of HEAD, please submit a rebased version.
--
Daniel Gustafsson https://vmware.com/
On Tue, Nov 2, 2021 at 7:46 PM Bruce Momjian wrote:
> I realize in this thread that Robert Haas mentioned foreign key
> violations that would like also appear in logs, but those are
> ERROR/WARNING etc. messages that can be filtered out with
> log_min_message.
I think that's pretty impractical.
On Wed, Sep 8, 2021 at 8:47 AM James Coleman wrote:
> See updated patch series attached.
Jaime,
I noticed on 3-October you moved this into "waiting on author"; I
don't see anything waiting in this thread, however. Am I missing
something?
I'm planning to change it back to "needs review".
Daniel Gustafsson писал 2021-11-03 16:45:
On 2 Nov 2021, at 10:12, Alexander Pyhalov
wrote:
Updated and rebased patch.
+ state = (Int128AggState *) palloc0(sizeof(Int128AggState));
+ state->calcSumX2 = false;
+
+ if (!PG_ARGISNULL(0))
+ {
+#ifdef HAVE_INT128
+
On 11/2/21 12:19 PM, Himanshu Upadhyaya wrote:
> Hi,
>
> Trying to insert NULL value to the Identity column defined by "GENERATED BY
> DEFAULT" is disallowed, but there can be use cases where the user would
> like to have an identity column where manual NULL insertion is required(and
> it should
The commitfest CI times out on all platforms and never finishes when running
make check with this patch, so unless the patch is dropped due to concerns
already raised then that seems like a good thing to fix.
--
Daniel Gustafsson https://vmware.com/
On Tue, Nov 2, 2021 at 8:02 PM Tom Lane wrote:
> I'm still of the position that the default ought to be that a
> normally-functioning server generates no ongoing log output.
> Only people who have got Nagios watching their logs, or some
> such setup, are going to want anything different. And
On Wed, Nov 3, 2021 at 08:45:46AM -0400, Robert Haas wrote:
> If log_checkpoints=on wouldn't fill up the disk on my 5+-year old
> Raspberry Pi in less time that it takes to raise multiple children to
> adulthood even after disabling the OS-provided log rotation and
> compression, then it seems
> On 28 Oct 2021, at 08:09, Takashi Menjo wrote:
> Rebased, and added the patches below into the patchset.
Looks like the 0001 patch needs to be updated to support Windows and MSVC. See
src/tools/msvc/Mkvcbuild.pm and Solution.pm et.al for inspiration on how to add
the MSVC equivalent of
> On 2 Nov 2021, at 19:26, Stephen Frost wrote:
>> Otherwise, I see a couple of warnings when compiling:
>>xlogfuncs.c:54: warning: implicit declaration of function
>> ‘RequestCheckpoint’
>>xlogfuncs.c:56: warning: control reaches end of non-void function
>
> Yeah, such things
Robert Haas writes:
> When I last worked on this, I had hoped that extParam or allParam
> would be the thing that would answer the question: are there any
> parameters used under this node that are not also set under this node?
> But I seem to recall that neither seemed to be answering precisely
On Tue, Nov 2, 2021 at 08:02:41PM -0400, Tom Lane wrote:
> I'm still of the position that the default ought to be that a
> normally-functioning server generates no ongoing log output.
> Only people who have got Nagios watching their logs, or some
> such setup, are going to want anything
On Wed, Nov 3, 2021 at 9:04 AM Bruce Momjian wrote:
> Well, another issue is that if something unusual does happen, it appears
> very visibly if you are looking just for LOG messages, while if you have
> many checkpoint log messages, it might get lost.
That's a theoretical risk, but in practice
On Wed, Nov 3, 2021 at 9:12 AM Amul Sul wrote:
> 0002:
> -GetFlushRecPtr(void)
> +GetFlushRecPtr(TimeLineID *insertTLI)
>
> Should we rename this argument to more generic as "tli", like
> GetStandbyFlushRecPtr, since the caller in 003 patch trying to fetch a
> TLI that means different for them,
On Wed, 3 Nov 2021 at 14:39, David Fetter wrote:
> Unfortunately, the PREPARE/EXECUTE infrastructure, and not just for
> PostgreSQL, has no way of passing along DEFAULT explicitly, i.e. it
>
My $.02: I'd be much happier with the idea of changing those
obviously-deficient interfaces to allow
> On 19 Oct 2021, at 22:12, David Christensen
> wrote:
>
> Greetings -hackers,
>
> Enclosed is a patch that implements CREATE ROLE IF NOT EXISTS (along with the
> same support for USER/GROUP). This is a fairly straightforward approach in
> that we do no validation of anything other than
Em ter., 2 de nov. de 2021 às 15:33, Andres Freund
escreveu:
> On 2021-11-02 13:43:46 -0400, Tom Lane wrote:
> > Ranier Vilela writes:
> > > It seems that 1ec7679f1b67e84be688a311dce234eeaa1d5de8 caused the
> problem.
> >
> > Indeed. Fix pushed.
>
> Thanks to both of you!
>
You are welcome,
> On 28 Sep 2021, at 15:23, Magnus Hagander wrote:
> On Fri, Sep 10, 2021 at 1:44 AM Jacob Champion wrote:
>> The TAP test will need to be rebased over the changes in 201a76183e.
>
> Done
And now the TAP test will need to be rebased over the changes in
On Fri, Jul 16, 2021 at 3:16 PM James Coleman wrote:
>
> On Thu, May 27, 2021 at 9:01 PM Greg Nancarrow wrote:
> >
> > On Tue, Dec 8, 2020 at 10:46 AM James Coleman wrote:
> > >
> > > While I haven't actually tracked down to guarantee this is handled
> > > elsewhere, a thought experiment -- I
Michael Paquier writes:
> I would follow the practice of upstream to include both if were me
> to be consistent, but I'm also fine if you just add x509v3.h to
> be-secure-openssl.c.
24f9e49e4 has not fixed it, so I have no idea what to do next.
We definitely need some input from the machine's
This patch no longer applies following the Perl namespace changes, can you
please submit a rebased version? Marking the patch "Waiting on Author".
--
Daniel Gustafsson https://vmware.com/
On Wed, Nov 3, 2021 at 09:09:18AM -0400, Robert Haas wrote:
> I think that's pretty impractical. In order to get rid of all of the
> harmless application errors, you'd have to set log_min_messages to
> FATAL. That's a bad idea for two reasons. First, it wouldn't even
> filter out all the garbage
FWIW the patch was marked as RFC for about a year, but there was plenty
of discussion / changes since then, so that seemed premature. I've
switched it back to WoA.
regards
--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On Thu, 21 Oct 2021 at 05:01, Kyotaro Horiguchi wrote:
>
> At Wed, 20 Oct 2021 08:55:12 -0700, Stan Hu wrote in
> > On Wed, Oct 20, 2021 at 4:00 AM Andrey Borodin wrote:
> >
> > >
> > >
> > > > 17 окт. 2021 г., в 21:55, Dmitry Dolgov <9erthali...@gmail.com>
> > > написал(а):
> > > > I wonder
Wu Haotian writes:
> here's the rebased patch.
Looks like it needs rebasing again, probably as a result of our recent
renaming of our Perl test modules.
FWIW, I'd strongly recommend that it's time to pull all that SQL code
hacking out of RestoreArchive and put it in its own function.
> On 3 Nov 2021, at 16:06, Peter Eisentraut
> wrote:
>
> On 03.11.21 11:16, Daniel Gustafsson wrote:
>>> On 30 Oct 2021, at 14:11, Peter Eisentraut
>>> wrote:
>>>
>>> On 24.08.21 11:13, Peter Eisentraut wrote:
So I'm tempted to suggest that we remove the built-in, non-OpenSSL cipher
On Wed, 3 Nov 2021 at 13:28, Daniel Gustafsson wrote:
>
> > On 30 Jun 2021, at 11:59, Simon Riggs wrote:
>
> > For PITR, getRecordTimestamp() did not include all record types that
> > contain times.
> > Add handling for checkpoints, end of recovery and prepared xact record
> > types.
>
> +
Greetings,
* Bossart, Nathan (bossa...@amazon.com) wrote:
> On 11/2/21, 11:27 AM, "Stephen Frost" wrote:
> > * Bossart, Nathan (bossa...@amazon.com) wrote:
> >> The approach in the patch looks alright to me, but another one could
> >> be to build a SelectStmt when parsing CHECKPOINT. I think
Greetings,
* Bruce Momjian (br...@momjian.us) wrote:
> On Mon, Nov 1, 2021 at 02:24:36PM -0400, Stephen Frost wrote:
> > I can understand the general idea that we should be sure to engineer
> > this in a way that multiple methods can be used, as surely one day folks
> > will say that AES128
Michail Nikolaev wrote:
> > * Is the purpose of the repeatable read (RR) snapshot to test that
> > heap_hot_search_buffer() does not set deadness->all_dead if some
> > transaction
> > can still see a tuple of the chain?
>
> The main purpose is to test xactStartedInRecovery logic after the
On 11/3/21 09:09, Robert Haas wrote:
For better or for worse, the
distinction between ERROR, FATAL, and PANIC is entirely based on what
we do after printing the message, and NOT on how serious the message
is.
THAT is a real problem with our error handling and logging system. Often
using
On Wed, Nov 3, 2021 at 11:14 AM Tom Lane wrote:
> FWIW, I've never been very happy with those fields either. IIRC the
> design in that area was all Vadim's, but to the extent that there's
> any usable documentation of extParam/allParam, it was filled in by me
> while trying to understand what
Mark Dilger writes:
> [ v1-0001-Reject-patterns-with-too-many-parts-or-wrong-db.patch ]
This needs a rebase over the recent renaming of our Perl test modules.
(Per the cfbot, so do several of your other pending patches.)
regards, tom lane
Dear colleagues,
Please see my suggestions below and the updated patch attached.
>Среда, 29 сентября 2021, 15:14 +03:00 от Teodor Sigaev < teo...@sigaev.ru >:
>
>Hi!
>
>Nice feature, but, sorry, I see some design problem in suggested feature.
>AFAIK,
>there is two use cases for this
> On Nov 1, 2021, at 10:58 AM, Mark Dilger wrote:
>
> ALTER SUBSCRIPTION..[ENABLE | DISABLE] do not synchronously start or stop
> subscription workers. The ALTER command updates the catalog's subenabled
> field, but workers only lazily respond to that. Disabling and enabling the
>
Robert Haas writes:
> One thing I discovered when I was looking at this a few years ago is
> that there was only one query in the regression tests where extParam
> and allParam were not the same. The offending query was select 1 =
> all(select (select 1)), and the resulting plan has a Materialize
"Daniel Westermann (DWE)" writes:
> just compiled PostgreSQL head on RedHat 9 beta. Generally seems to be fine
> but when building contrib, a lot of these warnings pop up:
> /usr/lib64/perl5/CORE/inline.h:2635:5: warning: '}' and ')' tokens
> terminating statement expression appear in
Hi Robert, thanks for the detailed reply.
On Wed, Nov 3, 2021 at 10:48 AM Robert Haas wrote:
>
> As a preliminary comment, it would be quite useful to get Tom Lane's
> opinion on this, since it's not an area I understand especially well,
> and I think he understands it better than anyone.
>
> On
On 11/4/21 12:19 AM, Justin Pryzby wrote:
> On Wed, Nov 03, 2021 at 11:48:44PM +0100, Tomas Vondra wrote:
>> On 10/8/21 12:45 AM, Justin Pryzby wrote:
>>> On Thu, Oct 07, 2021 at 03:26:46PM -0500, Jaime Casanova wrote:
On Sun, Sep 26, 2021 at 03:25:50PM -0500, Justin Pryzby wrote:
> On
FYI - I found a small problem with one of the new PublicationObjSpec
parser error messages that was introduced by the recent schema
publication commit [1].
The error message text is assuming that the error originates from
CREATE PUBLICATION, but actually that same error can also come from
ALTER
Good catch on doing this in ExpireAllKnownAssignedTransactionIds() as well.
Thanks. Looks good to me!
As Nikolay mentioned, I think this is an important bug that we are seeing
in production and would appreciate a backport to v12 if possible.
On Wed, Nov 3, 2021 at 3:07 PM Alexander Korotkov
> On 3 Nov 2021, at 17:15, Ivan Panchenko wrote:
> Среда, 29 сентября 2021, 15:14 +03:00 от Teodor Sigaev >:
> 2 For logging purpose failing of trigger will cause impossibility to login, it
> could be workarounded by catching error in trigger function, but it's not so
> obvious for DBA.
> If the
On Tue, Nov 02, 2021 at 08:02:41PM -0400, Tom Lane wrote:
> I'm still of the position that the default ought to be that a
> normally-functioning server generates no ongoing log output.
> Only people who have got Nagios watching their logs, or some
> such setup, are going to want anything
The code in gistvacuum.c is closely based on similar code in nbtree.c,
except that it only acquires an exclusive lock -- not a
super-exclusive lock. I suspect that that's because it seemed
unnecessary; nbtree plain index scans have their own special reasons
for this, that don't apply to GiST.
> On Nov 3, 2021, at 12:07 PM, Tom Lane wrote:
>
> Mark Dilger writes:
>> [ v1-0001-Reject-patterns-with-too-many-parts-or-wrong-db.patch ]
>
> This needs a rebase over the recent renaming of our Perl test modules.
> (Per the cfbot, so do several of your other pending patches.)
>
>
>
>
> This fails the roleattributes test in "make check", with what seems to be a
> trivial change in the output. Can you please submit a rebased version
> fixing
> the test?
>
Updated version attached.
David
CREATE-ROLE-IF-NOT-EXISTS-v2.patch
Description: Binary data
Hi!
On Wed, Nov 3, 2021 at 8:51 PM Simon Riggs wrote:
> It is however, an undocumented modularity violation. I think that is
> acceptable because of the ProcArrayLock traffic, but needs to have a
> comment to explain this at the call to
> ExpireOldKnownAssignedTransactionIds() i.e. " and
Jean-Christophe Arnu writes:
>> (By the same token, I think there's a good argument for
>> tsvector_delete_arr to just ignore nulls, not throw an error.
>> That's a somewhat orthogonal issue, though.)
> Nulls are now ignored in tsvector_delete_arr().
I think setweight() with an array should
On Wed, Nov 03, 2021 at 11:48:44PM +0100, Tomas Vondra wrote:
> On 10/8/21 12:45 AM, Justin Pryzby wrote:
> > On Thu, Oct 07, 2021 at 03:26:46PM -0500, Jaime Casanova wrote:
> >> On Sun, Sep 26, 2021 at 03:25:50PM -0500, Justin Pryzby wrote:
> >>> On Sat, Sep 25, 2021 at 05:31:52PM -0500, Justin
On Wed, Nov 3, 2021 at 5:41 PM Thomas Munro wrote:
> 'generic' is not a recognized processor for this target (ignoring processor)
I still don't know what's wrong but I spent 20 minutes searching for
more clues this morning...
First, 'generic' is coming from LLVMGetHostCPUName(), and yet it's
> On Nov 3, 2021, at 5:35 AM, Daniel Gustafsson wrote:
>
>
>>
>>> On 15 Oct 2021, at 23:54, Cary Huang wrote:
>>
>> I scanned through the GUC list and found that the following parameters can
>> potentially be categorized in the "special_disabled0" group, just for your
>> reference.
>
>
>
On Tue, Nov 2, 2021 at 10:44 PM Ajin Cherian wrote:
>
> Here's a rebase of the first 4 patches of the row-filter patch. Some
> issues still remain:
>
> 1. the following changes for adding OptWhereClause to the
> PublicationObjSpec has not been added
> as the test cases for this has not been yet
David Christensen writes:
> Updated version attached.
I'm generally pretty down on IF NOT EXISTS semantics in all cases,
but it seems particularly dangerous for something as fundamental
to privilege checks as a role. It's not hard at all to conjure up
scenarios in which this permits privilege
> On Oct 20, 2021, at 12:06 PM, Mark Dilger
> wrote:
>
> Ok. How about:
Done that way.
v3-0001-Adding-more-toast-pointer-checks-to-amcheck.patch
Description: Binary data
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On 10/8/21 12:45 AM, Justin Pryzby wrote:
> On Thu, Oct 07, 2021 at 03:26:46PM -0500, Jaime Casanova wrote:
>> On Sun, Sep 26, 2021 at 03:25:50PM -0500, Justin Pryzby wrote:
>>> On Sat, Sep 25, 2021 at 05:31:52PM -0500, Justin Pryzby wrote:
It seems like your patch should also check "inh" in
> On Oct 1, 2021, at 12:34 PM, Mark Dilger wrote:
>
> The patch does it this way.
A rebased patch is attached.
v2-0001-Reject-storage-options-in-toast-namespace-in-view.patch
Description: Binary data
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL
> On Oct 21, 2021, at 3:23 PM, Bossart, Nathan wrote:
>
> Do we intend to proceed with those, or should we just
> close out the Commmitfest entry?
I have withdrawn the patch. The issues were intermittent on the buildfarm, and
committing other changes along with what Tom already committed
On Tue, 2 Nov 2021 23:11:39 +0900
Fujii Masao wrote:
>
>
> On 2021/11/01 23:01, Fujii Masao wrote:
> >> The remainings are the changes of handling of initial connection or
> >> logfile open failures. I agree to push them at least for the master.
> >> But I'm not sure if they should be
On Thurs, Nov 4, 2021 8:12 AM Peter Smith wrote:
> FYI - I found a small problem with one of the new PublicationObjSpec parser
> error messages that was introduced by the recent schema publication commit
> [1].
>
> The error message text is assuming that the error originates from CREATE
>
On Thu, Nov 04, 2021 at 10:56:13AM +0900, 近藤雄太 wrote:
> We'll check it again, but there is no difference between HEAD and v14 branch.
> We simply added v14 branch to build recently, and did not change any settings
> of HEAD at that time.
Thanks for checking.
Could it be possible to copy-paste
On Wed, 2021-11-03 at 11:25 +0530, Amit Kapila wrote:
> You have modeled DecodeLogicalInsert based on current DecodeInsert
> and
> it generates the same change message, so not sure how exactly these
> new messages will be different from current heap_insert/update/delete
> messages?
Is there a
On Thu, Nov 4, 2021 at 11:55 AM houzj.f...@fujitsu.com
wrote:
>
> On Thurs, Nov 4, 2021 8:12 AM Peter Smith wrote:
> > FYI - I found a small problem with one of the new PublicationObjSpec parser
> > error messages that was introduced by the recent schema publication commit
> > [1].
> >
> > The
On Thu, Nov 4, 2021 at 3:16 PM Michael Paquier wrote:
> On Thu, Nov 04, 2021 at 10:56:13AM +0900, 近藤雄太 wrote:
> > We'll check it again, but there is no difference between HEAD and v14
> > branch.
> > We simply added v14 branch to build recently, and did not change any
> > settings of HEAD at
On Wed, 03 Nov 2021 10:35:36 -0400
Tom Lane wrote:
> Michael Paquier writes:
> > I would follow the practice of upstream to include both if were me
> > to be consistent, but I'm also fine if you just add x509v3.h to
> > be-secure-openssl.c.
>
> 24f9e49e4 has not fixed it, so I have no idea
On Thu, Nov 4, 2021 at 12:49 AM James Coleman wrote:
>
> Greg,
>
> Do you believe this is now ready for committer?
>
The patch LGTM.
I have set the status to "Ready for Committer".
Regards,
Greg Nancarrow
Fujitsu Australia
On Thu, Nov 04, 2021 at 12:44:45AM +0100, Tomas Vondra wrote:
> > I probably did this to make the code change small, to avoid indentin the
> > whole
> > block.
>
> But indenting the block is not necessary. It's possible to do something
> like this:
>
> if (!rel->inh)
> return 1.0;
>
Hi.
During some ad-hoc filter testing I observed a quirk when there are
duplicate tables. I think we need to define/implement some proper
rules for this behaviour.
=
BACKGROUND
When the same table appears multiple times in a CREATE PUBLICATION
then those duplicates are simply ignored. The
On Tue, Nov 2, 2021 at 12:18 AM osumi.takami...@fujitsu.com
wrote:
>
> On Thursday, October 28, 2021 11:19 PM I wrote:
> > I've created a new patch that extends pg_stat_subscription_workers to
> > include
> > other transaction statistics.
> >
> > Note that this patch depends on v18 patch-set in
On Thu, Nov 4, 2021 at 3:39 PM Thomas Munro wrote:
> On Thu, Nov 4, 2021 at 3:16 PM Michael Paquier wrote:
> > Could it be possible to copy-paste on this thread some of the
> > buildfarm logs that show the compilation failure? No issues from me
> > even if these are in Japanese.
>
> BTW It
On Thu, Nov 4, 2021 at 5:41 AM Peter Smith wrote:
>
> FYI - I found a small problem with one of the new PublicationObjSpec
> parser error messages that was introduced by the recent schema
> publication commit [1].
>
> The error message text is assuming that the error originates from
> CREATE
On Wed, Nov 3, 2021 at 6:21 PM Daniel Gustafsson wrote:
>
> > On 26 Jul 2021, at 09:33, Bharath Rupireddy
> > wrote:
>
> > PSA v7.
>
> This patch no longer applies on top of HEAD, please submit a rebased version.
Here's a rebased v8 patch. Please review it.
Regards,
Bharath Rupireddy.
On Thu, Nov 4, 2021 at 4:33 PM Tom Lane wrote:
> But I don't get the point about where HEAD is different from v14?
> be-secure-openssl.c isn't.
I don't understand what's going on and I don't have the headers to
look at, but I was thinking that WIN32_LEAN_AND_MEAN must be causing a
different
Thomas Munro writes:
> On Thu, Nov 4, 2021 at 4:33 PM Tom Lane wrote:
>> But I don't get the point about where HEAD is different from v14?
>> be-secure-openssl.c isn't.
> I don't understand what's going on and I don't have the headers to
> look at, but I was thinking that WIN32_LEAN_AND_MEAN
On Wed, Nov 3, 2021 at 1:08 PM Amit Kapila wrote:
>
> On Tue, Nov 2, 2021 at 11:17 AM Masahiko Sawada wrote:
> >
> > On Tue, Nov 2, 2021 at 5:57 AM Peter Geoghegan wrote:
> > >
> >
> > > Rather than inventing PARALLEL_VACUUM_KEY_INDVAC_CHECK (just for
> > > assert-enabled builds), we should
On Thu, Nov 4, 2021 at 3:24 PM vignesh C wrote:
>
> On Thu, Nov 4, 2021 at 5:41 AM Peter Smith wrote:
> >
> > FYI - I found a small problem with one of the new PublicationObjSpec
> > parser error messages that was introduced by the recent schema
> > publication commit [1].
> >
> > The error
On Wednesday, November 3, 2021 8:51 PM Ajin Cherian wrote:
> On Tue, Nov 2, 2021 at 10:44 PM Ajin Cherian wrote:
> .
> >
> > The patch 0005 and 0006 has not yet been rebased but will be updated
> > in a few days.
> >
>
> Here's a rebase of all the 6 patches. Issue remaining:
Thanks for the
On Mon, Nov 1, 2021 at 6:42 AM Kyotaro Horiguchi
wrote:
>
> At Fri, 29 Oct 2021 22:25:04 +0530, Bharath Rupireddy
> wrote in
> > On Mon, Oct 11, 2021 at 9:55 AM Bharath Rupireddy
> > wrote:
> > >
> > > On Mon, Oct 11, 2021 at 8:21 AM torikoshia
> > > wrote:
> > > > If we can use debuggers,
Thomas Munro writes:
> Ahh, I think this contains some relevant bits, and we have indeed
> messed around with mentioned Windows headers in master.
> https://stackoverflow.com/questions/49504648/x509-name-macro-in-c-wont-compile/49504794
Oooh note the comment there about
This helped me
On Thu, Nov 4, 2021 at 8:17 AM Peter Smith wrote:
>
>
> PROPOSAL
>
> I propose that we change the way duplicate tables are processed to
> make it so that it is always the *last* one that takes effect (instead
> of the *first* one).
>
I don't have a good reason to prefer one over another but I
On Wed, Nov 3, 2021 at 3:43 PM Amit Kapila wrote:
>
> On Thu, Oct 28, 2021 at 1:55 PM Amit Langote wrote:
> >
> >
> > Thanks for the summary, Hou-san, and sorry about my late reply.
> >
> > I had thought about this some last week and I am coming around to
> > recognizing the confusing user
On Thu, Nov 4, 2021 at 2:08 PM Amit Kapila wrote:
>
> On Thu, Nov 4, 2021 at 8:17 AM Peter Smith wrote:
> >
> >
> > PROPOSAL
> >
> > I propose that we change the way duplicate tables are processed to
> > make it so that it is always the *last* one that takes effect (instead
> > of the *first*
On Wed, Nov 3, 2021 at 11:55 AM vignesh C wrote:
>
> On Wed, Nov 3, 2021 at 11:37 AM Peter Smith wrote:
> >
> > While you are changing these, maybe also change:
> >
> > Before: PUBLICATIONOBJ..._CURRSCHEMA
> > After: PUBLICATIONOBJ..._CUR_SCHEMA
> >
> > Which seems more readable to me.
>
>
( a.On Wed, Nov 3, 2021 at 11:44 AM Andrey Borodin wrote:
> > 21 окт. 2021 г., в 09:01, Kyotaro Horiguchi
> > написал(а):
> >
> > If the discussion so far is correct, the following diff will fix the
> > issue.
> >
> > diff --git a/src/backend/storage/ipc/procarray.c
> >
1 - 100 of 105 matches
Mail list logo
