Hi all,
I have bumped into $subject, causing a replica identity index to
be considered as dropped if running REINDEX CONCURRENTLY on it. This
means that the old tuple information would get lost in this case, as
a REPLICA IDENTITY USING INDEX without a dropped index is the same as
NOTHING.
Attach
Le mer. 3 juin 2020 à 04:16, David Fetter a écrit :
> On Tue, Jun 02, 2020 at 09:28:48PM +0200, Vik Fearing wrote:
> > On 6/2/20 7:54 PM, David G. Johnston wrote:
> > > At this point, given the original goal of the patch was to try and
> > > grease a smoother path to changing the default for BUFF
On Wed, 3 Jun 2020 at 14:50, Amit Kapila wrote:
>
> On Tue, May 19, 2020 at 12:33 PM Masahiko Sawada
> wrote:
> >
> > I think that the current three values are useful for users. The
> > ‘required’ mode is used when users want to ensure all writes involved
> > with the transaction are committed at
At Wed, 03 Jun 2020 02:00:53 -0400, Tom Lane wrote in
> ... and InvalidateObsoleteReplicationSlots(), too.
>
> I am detecting a pattern here.
I looked through 224 locations where SpinLockAcquire and found some.
LogicalIncreaseRestartDecodingForSlot is spotted by Michael.
pg_get_replication_slo
On Wed, 3 Jun 2020 at 08:30, Cary Huang wrote:
>
> Hi
>
>
>
> I took a step back today and started to think about the purpose of internal
> KMS and what it is supposed to do, and how it compares to external KMS. Both
> are intended to manage the life cycle of encryptions keys including their
>
On Tue, Jun 02, 2020 at 04:46:55PM +0900, Masahiko Sawada wrote:
> How about avoiding such an inconsistent situation? In that case,
> replica identity works as NOTHING, but pg_class.relreplident is still
> ‘i’, confusing users. It seems to me that dropping an index specified
> by REPLICA IDENTITY U
... and InvalidateObsoleteReplicationSlots(), too.
I am detecting a pattern here.
regards, tom lane
Michael Paquier writes:
> On Wed, Jun 03, 2020 at 01:27:51AM -0400, Tom Lane wrote:
>> I'm inclined to think that memcpy'ing the ReplicationSlot struct
>> into a local variable might be the best way, replacing all the
>> piecemeal copying these stanzas are doing right now.
> +1. And I guess that
On Tue, May 19, 2020 at 12:33 PM Masahiko Sawada
wrote:
>
> I think that the current three values are useful for users. The
> ‘required’ mode is used when users want to ensure all writes involved
> with the transaction are committed atomically. That being said, as
> some FDW plugin might not suppo
On Wed, Jun 03, 2020 at 01:27:51AM -0400, Tom Lane wrote:
> I'm inclined to think that memcpy'ing the ReplicationSlot struct
> into a local variable might be the best way, replacing all the
> piecemeal copying these stanzas are doing right now. memcpy() of
> a fixed amount of data isn't quite stra
I wrote:
> Ugh, that is just horrid. I experimented with the attached patch
> but it did not find any other problems.
It occurred to me to add NotHoldingSpinLock() into palloc and
friends, and look what I found in copy_replication_slot:
SpinLockAcquire(&s->mutex);
src_isl
On Tue, Jun 02, 2020 at 02:45:11PM -0400, Andrew Dunstan wrote:
> Honestly, I think we've spent plenty of time on this already. I don't
> see a problem with each module having its own certificate(s) - that
> makes them more self-contained - nor any great need to have the targets
> named the same.
On Tue, Jun 02, 2020 at 02:23:50PM +0900, Fujii Masao wrote:
> On 2020/06/02 13:24, Michael Paquier wrote:
>> Still unconvinced as this restriction stands for logical decoding
>> requiring a database connection but it is not necessarily true now as
>> physical replication has less restrictions than
On Wed, Jun 03, 2020 at 12:36:34AM -0400, Tom Lane wrote:
> Ugh, that is just horrid. I experimented with the attached patch
> but it did not find any other problems.
Oh. I can see the same "ifndef FRONTEND" logic all around the place
as I did on my local branch :)
> Still, that only proves som
On Wed, Jun 03, 2020 at 08:52:08AM +0530, Amit Kapila wrote:
> Do you mean to say correct?
Nope, I really meant that the code before caa3c42 is incorrect, and I
am glad that it got fixed. Sorry if that sounded confusing.
--
Michael
signature.asc
Description: PGP signature
Michael Paquier writes:
> Indeed, this was incorrect. And you may not have noticed, but we have
> a second instance of that in LogicalIncreaseRestartDecodingForSlot()
> that goes down to 9.4 and b89e151. I used a dirty-still-efficient
> hack to detect that, and that's the only instance I have sp
On Wed, Jun 3, 2020 at 8:35 AM Michael Paquier wrote:
>
> On Wed, Jun 03, 2020 at 09:18:19AM +0900, Kyotaro Horiguchi wrote:
> > Thanks to all!
>
> Indeed, this was incorrect.
>
Do you mean to say correct?
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
Hi David,
On Fri, May 29, 2020 at 2:16 PM David Rowley wrote:
> In [1] I mentioned that I'd like to look into coding a data structure
> to allow Node types to be looked up more efficiently than what List
> allows. There are many places in the planner where we must determine
> if a given Node is
At Wed, 3 Jun 2020 09:43:17 +0900, Fujii Masao
wrote in
> I will change the status back to Needs Review.
record = ReadCheckpointRecord(xlogreader, checkPointLoc, 1, false);
if (record != NULL)
{
- fast_promoted = true;
+ promoted = true;
Even if we
On Wed, Jun 03, 2020 at 09:18:19AM +0900, Kyotaro Horiguchi wrote:
> Thanks to all!
Indeed, this was incorrect. And you may not have noticed, but we have
a second instance of that in LogicalIncreaseRestartDecodingForSlot()
that goes down to 9.4 and b89e151. I used a dirty-still-efficient
hack to
I wrote:
> It looks like table_beginscan_tid wouldn't need to be exported anymore
> either.
Ah, scratch that, I misread it.
regards, tom lane
>
>
> Thanks for running those tests. I had a quick look at the results and
> I think to say that all 4 are better is not quite right. One is
> actually a tiny bit slower and one is only faster due to a plan
> change.
>
>
Yes.. Thanks for pointing it out.
> Q18 uses a result cache for 2 x neste
Michael Paquier writes:
> I would like to remove those two functions and the surrounding code
> for v14, leading to some cleanup:
+1
> While on it, I have noticed that heap_get_latest_tid() is still
> located within heapam.c, but we can just move it within
> heapam_handler.c.
It looks like tabl
On Tue, Jun 02, 2020 at 09:28:48PM +0200, Vik Fearing wrote:
> On 6/2/20 7:54 PM, David G. Johnston wrote:
> > At this point, given the original goal of the patch was to try and
> > grease a smoother path to changing the default for BUFFERS, and
> > that people seem OK with doing just that without
Hi all,
I have been looking at the ODBC driver and the need for currtid() as
well as currtid2(), and as mentioned already in [1], matching with my
lookup of things, these are actually not needed by the driver as long
as we connect to a server newer than 8.2 able to support RETURNING. I
am adding
On Wed, Jun 03, 2020 at 10:56:13AM +1200, Thomas Munro wrote:
> Sorry for my radio silence, I got tangled up with a couple of
> conferences. I'm planning to look at 0001 and 0002 shortly.
Thanks!
--
Michael
signature.asc
Description: PGP signature
Hi,
On 2020-05-18 12:38:05 -0400, Tom Lane wrote:
> Andres Freund writes:
> >> FWIW, I've also observed, in another thread (the node func generation
> >> thing [1]), that inlining enlargeStringInfo() helps a lot, especially
> >> when inlining some of its callers. Moving e.g. appendStringInfo() in
On 2020/06/03 3:38, Hamid Akhtar wrote:
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: not tested
Spec compliant: not tested
Documentation:not tested
I've applied the v2 patch on
On Tue, Jun 2, 2020 at 11:58:51PM +0200, Vik Fearing wrote:
> On 6/2/20 10:51 PM, Bruce Momjian wrote:
> > On Tue, Jun 2, 2020 at 09:29:09PM +0200, Vik Fearing wrote:
> >> On 6/2/20 7:25 PM, Bruce Momjian wrote:
> >>> I think it would have been helpful if an email explaining this idea for
> >>> d
At Tue, 2 Jun 2020 19:24:16 +0900, Fujii Masao
wrote in
> Thanks! I pushed the patch.
Thanks to all!
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
Hi
I took a step back
today and started to think about the purpose of internal KMS and what it is
supposed to do, and how it compares to external KMS. Both are intended to
manage the life cycle of encryptions keys including their generation,
protection, storage and rotation. External KMS, on th
On Tue, Jun 2, 2020 at 9:38 PM Dmitry Dolgov <9erthali...@gmail.com> wrote:
> > On Tue, Jun 02, 2020 at 08:36:31PM +0800, Andy Fan wrote:
> >
> > > Other than that to summarize current open points for future readers
> > > (this thread somehow became quite big):
> > >
> > > * Making UniqueKeys usag
On Tue, Jun 2, 2020 at 5:24 PM Michael Paquier wrote:
> On Sun, May 31, 2020 at 09:11:35PM +, Bossart, Nathan wrote:
> > Thanks for the feedback. I've attached a new set of patches.
>
> Thanks for splitting the set. 0001 and 0002 are the minimum set for
> back-patching, and it would be bette
On 6/2/20 10:51 PM, Bruce Momjian wrote:
> On Tue, Jun 2, 2020 at 09:29:09PM +0200, Vik Fearing wrote:
>> On 6/2/20 7:25 PM, Bruce Momjian wrote:
>>> I think it would have been helpful if an email explaining this idea for
>>> discussion would have been posted before a patch was generated and
>>> p
On Tue, 2 Jun 2020 at 21:05, Andy Fan wrote:
> Today I tested the correctness & performance of this patch based on TPC-H
> workload, the environment is setup based on [1]. Correctness is tested by
> storing the result into another table when this feature is not introduced and
> then enable this fe
On Tue, Jun 2, 2020 at 09:29:09PM +0200, Vik Fearing wrote:
> On 6/2/20 7:25 PM, Bruce Momjian wrote:
> > On Wed, May 27, 2020 at 11:10:35AM +0200, Vik Fearing wrote:
> >> On 5/27/20 7:27 AM, David G. Johnston wrote:
> Would you propose we just error out in that case, or should we
> sile
On 6/2/20 7:25 PM, Bruce Momjian wrote:
> On Wed, May 27, 2020 at 11:10:35AM +0200, Vik Fearing wrote:
>> On 5/27/20 7:27 AM, David G. Johnston wrote:
Would you propose we just error out in that case, or should we
silently enable the required option, or disable the conflicting
option
On 6/2/20 7:54 PM, David G. Johnston wrote:
> At this point, given the original goal of the patch was to try and grease a
> smoother path to changing the default for BUFFERS, and that people seem OK
> with doing just that without having this patch, I'd say we should just
> change the default and fo
On 6/2/20 4:57 AM, Peter Eisentraut wrote:
> On 2020-06-01 15:23, Andrew Dunstan wrote:
>>
>> On 6/1/20 8:03 AM, Daniel Gustafsson wrote:
On 1 Jun 2020, at 13:58, Andrew Dunstan
wrote:
If you want I can add a rule for it to the Makefile, although who
knows
what commands
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: not tested
Spec compliant: not tested
Documentation:not tested
I've applied the v2 patch on the master branch. There some hunks, but the
On Tue, Jun 2, 2020 at 10:25 AM Bruce Momjian wrote:
> On Wed, May 27, 2020 at 11:10:35AM +0200, Vik Fearing wrote:
> > On 5/27/20 7:27 AM, David G. Johnston wrote:
> > >> Would you propose we just error out in that case, or should we
> > >> silently enable the required option, or disable the con
On Mon, Jun 1, 2020 at 3:20 PM Tom Lane wrote:
> Robert Haas writes:
> > As has already been pointed out, it could definitely happen, but we
> > could solve that by just using a longer version number, say, including
> > the month and, in case we ever do multiple major releases in the same
> > mon
On Wed, May 27, 2020 at 11:10:35AM +0200, Vik Fearing wrote:
> On 5/27/20 7:27 AM, David G. Johnston wrote:
> >> Would you propose we just error out in that case, or should we
> >> silently enable the required option, or disable the conflicting
> >> option?
> >>
> > The same thing we do today...ign
On Tue, May 26, 2020 at 10:13:56AM -0400, Chapman Flack wrote:
> At $work, when I make a certificate request and send it off to our
> own in-house bureau of making certificates happen, what you might
> expect is that they would be running the first level of CA right
> in house (and IIRC that was th
> On Jun 2, 2020, at 9:58 AM, Mark Dilger wrote:
>
>>
>> On Mar 4, 2020, at 7:43 PM, Mark Dilger wrote:
>>
>> Hackers,
>>
>> as mentioned in [1], I have created an implementation of command counter
>> statistics very similar in purpose to the one already pending in the
>> commitfest going
> On Mar 4, 2020, at 7:43 PM, Mark Dilger wrote:
>
> Hackers,
>
> as mentioned in [1], I have created an implementation of command counter
> statistics very similar in purpose to the one already pending in the
> commitfest going by the name "pg_stat_sql". I don't really care if this
> imple
Hi Stephen,
> > I have no problem adding it to this ROLE, but we'd have to amend the
> > doc for default-roles to reflect that SELECT for this view is also
> > granted to `pg_read_all_stats`.
>
> I agree in general that pg_monitor shouldn't have privileges granted
> directly to it. If this needs
Greetings,
* Martín Marqués (mar...@2ndquadrant.com) wrote:
> > > $ git diff
> > > diff --git a/src/backend/catalog/system_views.sql
> > > b/src/backend/catalog/system_views.sql
> > > index c16061f8f00..97ee72a9cfc 100644
> > > --- a/src/backend/catalog/system_views.sql
> > > +++ b/src/backend/cat
On Tue, Jun 2, 2020 at 4:56 PM Amit Kapila wrote:
>
> On Tue, Jun 2, 2020 at 3:59 PM Dilip Kumar wrote:
> >
> > On Thu, May 28, 2020 at 5:22 PM Amit Kapila wrote:
> > >
> > >
> > > Also, what if the changes file size overflows "OS file size limit"?
> > > If we agree that the above are problems t
Hi,
> > $ git diff
> > diff --git a/src/backend/catalog/system_views.sql
> > b/src/backend/catalog/system_views.sql
> > index c16061f8f00..97ee72a9cfc 100644
> > --- a/src/backend/catalog/system_views.sql
> > +++ b/src/backend/catalog/system_views.sql
> > @@ -1494,9 +1494,6 @@ GRANT EXECUTE ON FUN
On Mon, 1 Jun 2020 12:44:26 +0500
godjan • wrote:
> Hi, sorry for 2 weeks latency in answer :)
>
> >> It fixed out trouble, but there is one another. Now we should wait when all
> >> ha alive hosts finish replaying WAL to failover. It might take a while(for
> >> example WAL contains wal_record a
> On Tue, Jun 02, 2020 at 08:36:31PM +0800, Andy Fan wrote:
>
> > Other than that to summarize current open points for future readers
> > (this thread somehow became quite big):
> >
> > * Making UniqueKeys usage more generic to allow using skip scan for more
> > use cases (hopefully it was covere
On Tue, 2 Jun 2020 at 16:00, Kyotaro Horiguchi wrote:
>
> At Tue, 2 Jun 2020 15:17:36 +0900, Masahiko Sawada
> wrote in
> > Hi all,
> >
> > Tracking of spilled transactions has been introduced to PG13. These
> > new statistics values, spill_txns, spill_count, and spill_bytes, are
> > cumulative
On Wed, Apr 8, 2020 at 3:41 AM Dmitry Dolgov <9erthali...@gmail.com> wrote:
> > On Mon, Apr 06, 2020 at 06:31:08PM +, Floris Van Nee wrote:
> >
> > > Hm, I wasn't aware about this one, thanks for bringing this up. Btw,
> Floris, I
> > > would appreciate if in the future you can make it more vi
On Tue, Jun 2, 2020 at 3:59 PM Dilip Kumar wrote:
>
> On Thu, May 28, 2020 at 5:22 PM Amit Kapila wrote:
> >
> >
> > Also, what if the changes file size overflows "OS file size limit"?
> > If we agree that the above are problems then do you think we should
> > explore using BufFile interface (see
On Thu, May 28, 2020 at 5:22 PM Amit Kapila wrote:
>
> On Wed, May 27, 2020 at 8:22 PM Dilip Kumar wrote:
> >
> > On Tue, May 26, 2020 at 7:45 AM Dilip Kumar wrote:
> > >
> > >
> > > Okay, sending again.
> >
> > While reviewing/testing I have found a couple of problems in 0005 and
> > 0006 which
On 2020/06/02 17:42, Amit Kapila wrote:
On Tue, Jun 2, 2020 at 2:05 PM Fujii Masao wrote:
On 2020/06/02 16:15, Kyotaro Horiguchi wrote:
Hello.
I noticed that UpdateSpillStats calls "elog(DEBUG2" within
SpinLockAcquire section on MyWalSnd. The lock doesn't protect rb and
in the first plac
On Tue, Jun 2, 2020 at 1:52 PM Fujii Masao wrote:
>
> On 2020/06/02 16:00, Kyotaro Horiguchi wrote:
> > At Tue, 2 Jun 2020 15:17:36 +0900, Masahiko Sawada
> > wrote in
> >> Hi all,
> >>
> >> Tracking of spilled transactions has been introduced to PG13. These
> >> new statistics values, spill_txn
On Tue, 2 Jun 2020 at 17:22, Fujii Masao wrote:
>
>
>
> On 2020/06/02 16:00, Kyotaro Horiguchi wrote:
> > At Tue, 2 Jun 2020 15:17:36 +0900, Masahiko Sawada
> > wrote in
> >> Hi all,
> >>
> >> Tracking of spilled transactions has been introduced to PG13. These
> >> new statistics values, spill_t
On Tue, Jun 2, 2020 at 11:48 AM Masahiko Sawada
wrote:
>
> Hi all,
>
> Tracking of spilled transactions has been introduced to PG13. These
> new statistics values, spill_txns, spill_count, and spill_bytes, are
> cumulative total values unlike other statistics values in
> pg_stat_replication. How c
No. I think the message be sent to the log.
i created diagram.
May be check postgresql.conf of valid or invalid?
[image: contains errors unaffected changes were applied.png]
вс, 31 мая 2020 г. в 23:31, Justin Pryzby :
> On Sun, May 31, 2020 at 01:43:45PM +0600, Антон Пацев wrote:
> > Hello!
> > W
On 2020-05-29 19:24, Robert Haas wrote:
On Tue, May 19, 2020 at 7:02 AM Peter Eisentraut
wrote:
That thread didn't resolve why check_canonical_path() is necessary
there. Maybe the existing uses could be removed?
This first sentence of this reply seems worthy of particualr
attention. We have
On 2020-06-01 15:23, Andrew Dunstan wrote:
On 6/1/20 8:03 AM, Daniel Gustafsson wrote:
On 1 Jun 2020, at 13:58, Andrew Dunstan wrote:
If you want I can add a rule for it to the Makefile, although who knows
what commands will actually apply when the certificate runs out?
Being able to easily r
On Tue, Jun 2, 2020 at 2:05 PM Fujii Masao wrote:
>
> On 2020/06/02 16:15, Kyotaro Horiguchi wrote:
> > Hello.
> >
> > I noticed that UpdateSpillStats calls "elog(DEBUG2" within
> > SpinLockAcquire section on MyWalSnd. The lock doesn't protect rb and
> > in the first place the rb cannot be modifi
On 2020/06/02 16:15, Kyotaro Horiguchi wrote:
Hello.
I noticed that UpdateSpillStats calls "elog(DEBUG2" within
SpinLockAcquire section on MyWalSnd. The lock doesn't protect rb and
in the first place the rb cannot be modified during the function is
running.
It should be out of the lock sect
On 2020/06/02 16:00, Kyotaro Horiguchi wrote:
At Tue, 2 Jun 2020 15:17:36 +0900, Masahiko Sawada
wrote in
Hi all,
Tracking of spilled transactions has been introduced to PG13. These
new statistics values, spill_txns, spill_count, and spill_bytes, are
cumulative total values unlike other st
On Fri, 22 May 2020 at 12:50, Michael Paquier wrote:
>
> Hi all,
>
> While working on some other logical decoding patch recently, I bumped
> into the fact that we have special handling for the case of REPLICA
> IDENTITY USING INDEX when the dependent index is dropped, where the
> code handles that
Hello.
I noticed that UpdateSpillStats calls "elog(DEBUG2" within
SpinLockAcquire section on MyWalSnd. The lock doesn't protect rb and
in the first place the rb cannot be modified during the function is
running.
It should be out of the lock section.
regards.
--
Kyotaro Horiguchi
NTT Open Sour
At Tue, 2 Jun 2020 15:17:36 +0900, Masahiko Sawada
wrote in
> Hi all,
>
> Tracking of spilled transactions has been introduced to PG13. These
> new statistics values, spill_txns, spill_count, and spill_bytes, are
> cumulative total values unlike other statistics values in
> pg_stat_replication.
69 matches
Mail list logo
