At Mon, 13 Jul 2020 13:52:12 -0400, Alvaro Herrera
wrote in
> On 2020-Jul-13, Alvaro Herrera wrote:
>
> > A much more sensible answer is to initialize the segno to the segment
> > currently being written, as in the attached.
>
> Ran the valgrind test locally and it passes. Pushed it now.
-
On 2020-Jul-13, Alvaro Herrera wrote:
> A much more sensible answer is to initialize the segno to the segment
> currently being written, as in the attached.
Ran the valgrind test locally and it passes. Pushed it now.
Thanks,
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
A much more sensible answer is to initialize the segno to the segment
currently being written, as in the attached.
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>From 699e3a25e0673353fcb10fa92577f7534e594227
On 2020-Jul-11, Tom Lane wrote:
> Alvaro Herrera writes:
> > On 2020-Jul-09, Alvaro Herrera wrote:
> >> I think we should define InvalidXLogSegNo to be ~((uint64)0) and add a
> >> macro to test for that.
>
> > That's overkill really. I just used zero. Running
> > contrib/test_decoding under
Alvaro Herrera writes:
> On 2020-Jul-09, Alvaro Herrera wrote:
>> I think we should define InvalidXLogSegNo to be ~((uint64)0) and add a
>> macro to test for that.
> That's overkill really. I just used zero. Running
> contrib/test_decoding under valgrind, this now passes.
> I think I'd rather
On 2020-Jul-09, Alvaro Herrera wrote:
> I think we should define InvalidXLogSegNo to be ~((uint64)0) and add a
> macro to test for that.
That's overkill really. I just used zero. Running
contrib/test_decoding under valgrind, this now passes.
I think I'd rather do away with the compare to
On 2020-Jul-09, Tom Lane wrote:
> and even the most cursory look at the code confirms that there's a
> real bug here. KeepLogSeg expects *logSegNo to be defined on entry,
> but GetWALAvailability hasn't bothered to initialize oldestSlotSeg.
> It is not clear to me which one is in the wrong; the
... or on the other hand, maybe these animals are just showing more
sensitivity than others to an actual code bug. skink is showing
valgrind failures in this very area, on both HEAD and v13:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=skink=2020-07-08%2021%3A13%3A02
==3166208==
Alvaro Herrera writes:
> On 2020-Jul-08, Tom Lane wrote:
>> We did not. If it's a compiler bug, and one as phase-of-the-moon-
>> dependent as this seems to be, I'd have zero confidence that any
>> specific source code change would fix it (barring someone confidently
>> explaining exactly what
On 2020-Jul-08, Tom Lane wrote:
> Alvaro Herrera writes:
> > Ouch. So 12 builds with -O0 but 13 does not?
>
> Unless Tom's changed the animal's config since that thread, yes.
I verified the configs in branches 12 and 13 in one of the failing
animals, and yes that's still the case.
> > Did
Alvaro Herrera writes:
> On 2020-Jul-08, Tom Lane wrote:
>> We've previously noted what seem to be compiler optimization bugs on
>> both sparc32 and sparc64; the latest thread about that is
>> https://www.postgresql.org/message-id/flat/f28f842d-e82b-4e30-a81a-2a1f9fa4a8e1%40www.fastmail.com
>>
On 2020-Jul-08, Tom Lane wrote:
> Alvaro Herrera writes:
> > Anyway the error is pretty strange: only GetWALAvailability is showing a
> > problem, but the size calculation in the view function def is returning
> > a negative number, as expected.
>
> We've previously noted what seem to be
Alvaro Herrera writes:
> On 2020-Jul-08, Tom Lane wrote:
>> The buildfarm's sparc64 members seem unhappy with this.
> Hmm. Some of them are, yeah, but it's not universal. For example
> mussurana and ibisbill are not showing failures.
Ah, right, I was thinking they hadn't run since this
On 2020-Jul-08, Tom Lane wrote:
> Alvaro Herrera writes:
> > In absence of other suggestions I gave this the name XLogMBVarToSegs,
> > and redefined ConvertToXSegs to use that. Didn't touch callers in
> > xlog.c to avoid pointless churn. Pushed to both master and 13.
>
> The buildfarm's
Alvaro Herrera writes:
> In absence of other suggestions I gave this the name XLogMBVarToSegs,
> and redefined ConvertToXSegs to use that. Didn't touch callers in
> xlog.c to avoid pointless churn. Pushed to both master and 13.
The buildfarm's sparc64 members seem unhappy with this.
On 2020-Jul-06, Alvaro Herrera wrote:
> On 2020-Jul-07, Kyotaro Horiguchi wrote:
> > Couldn't we move ConvertToXSegs from xlog.c to xlog_ingernals.h and
> > use it intead of the bare expression?
>
> I was of two minds about that, and the only reason I didn't do it is
> that we'll need to give
On 2020-Jul-07, Kyotaro Horiguchi wrote:
> At Mon, 6 Jul 2020 20:54:36 -0400, Alvaro Herrera
> wrote in
> > I propose the attached. This is pretty much what was proposed by
> > Kyotaro, but I made a couple of changes. Most notably, I moved the
> > calculation to the view code itself rather
Thanks!
At Mon, 6 Jul 2020 20:54:36 -0400, Alvaro Herrera
wrote in
> On 2020-Jul-06, Alvaro Herrera wrote:
>
> > Hmm, I like safe_wal_size.
I agree to the name, too.
> > I've been looking at this intermittently since late last week and I
> > intend to get it done in the next couple of days.
On 2020-Jul-06, Alvaro Herrera wrote:
> Hmm, I like safe_wal_size.
>
> I've been looking at this intermittently since late last week and I
> intend to get it done in the next couple of days.
I propose the attached. This is pretty much what was proposed by
Kyotaro, but I made a couple of
On 2020-Jul-04, Amit Kapila wrote:
> Fair enough. It would be good if we can come up with something better
> than 'distance' for this column. Some ideas safe_wal_limit,
> safe_wal_size?
Hmm, I like safe_wal_size.
I've been looking at this intermittently since late last week and I
intend to
On Wed, Jul 1, 2020 at 8:44 PM Alvaro Herrera wrote:
>
> On 2020-Jul-01, Amit Kapila wrote:
>
> > Okay, but do we think it is better to display this in
> > pg_replication_slots or some new view like pg_stat_*_slots as being
> > discussed in [1]? It should not happen that we later decide to move
On 2020-Jul-02, mich...@paquier.xyz wrote:
> pg_replication_slots would make sense to me than a stat view for a
> distance column. Now, I have to admit that I am worried when seeing
> design discussions on this thread for 13 after beta2 has been shipped,
We already had this discussion and one
On Wed, Jul 01, 2020 at 11:14:21AM -0400, Alvaro Herrera wrote:
> On 2020-Jul-01, Amit Kapila wrote:
>> Okay, but do we think it is better to display this in
>> pg_replication_slots or some new view like pg_stat_*_slots as being
>> discussed in [1]? It should not happen that we later decide to
On 2020-Jul-01, Amit Kapila wrote:
> Okay, but do we think it is better to display this in
> pg_replication_slots or some new view like pg_stat_*_slots as being
> discussed in [1]? It should not happen that we later decide to move
> this or similar stats to that view.
It seems that the main
On Tue, Jun 30, 2020 at 7:53 PM Fujii Masao wrote:
>
> On 2020/06/30 17:07, Fujii Masao wrote:
> >
> >
> > On 2020/06/26 13:45, Amit Kapila wrote:
> >>
> >> Can we consider an option to "Remove min_safe_lsn; document how a user
> >> can monitor the distance"? We have a function to get current
At Tue, 30 Jun 2020 23:23:30 +0900, Fujii Masao
wrote in
> >> Can we consider an option to "Remove min_safe_lsn; document how a user
> >> can monitor the distance"? We have a function to get current WAL
> >> insert location and other things required are available either via
> >> view or as guc
On 2020-Jun-30, Fujii Masao wrote:
> Sorry this is not true. That distance can be calculated without those
> operators.
> For example,
>
> SELECT restart_lsn - pg_current_wal_lsn() + (SELECT setting::numeric * 1024 *
> 1024 FROM pg_settings WHERE name = 'max_slot_wal_keep_size') distance FROM
On 2020/06/30 17:07, Fujii Masao wrote:
On 2020/06/26 13:45, Amit Kapila wrote:
On Fri, Jun 26, 2020 at 4:54 AM Alvaro Herrera wrote:
On 2020-Jun-26, Michael Paquier wrote:
On Thu, Jun 25, 2020 at 11:24:27AM -0400, Alvaro Herrera wrote:
I don't understand the proposal. Michael
On 2020/06/26 13:45, Amit Kapila wrote:
On Fri, Jun 26, 2020 at 4:54 AM Alvaro Herrera wrote:
On 2020-Jun-26, Michael Paquier wrote:
On Thu, Jun 25, 2020 at 11:24:27AM -0400, Alvaro Herrera wrote:
I don't understand the proposal. Michael posted a patch that adds
pg_wal_oldest_lsn(),
On Fri, Jun 26, 2020 at 4:54 AM Alvaro Herrera wrote:
>
> On 2020-Jun-26, Michael Paquier wrote:
>
> > On Thu, Jun 25, 2020 at 11:24:27AM -0400, Alvaro Herrera wrote:
> > > I don't understand the proposal. Michael posted a patch that adds
> > > pg_wal_oldest_lsn(), and you say we should apply
On 2020-Jun-26, Michael Paquier wrote:
> On Thu, Jun 25, 2020 at 11:24:27AM -0400, Alvaro Herrera wrote:
> > I don't understand the proposal. Michael posted a patch that adds
> > pg_wal_oldest_lsn(), and you say we should apply the patch except the
> > part that adds that function -- so what
On Thu, Jun 25, 2020 at 11:24:27AM -0400, Alvaro Herrera wrote:
> I don't understand the proposal. Michael posted a patch that adds
> pg_wal_oldest_lsn(), and you say we should apply the patch except the
> part that adds that function -- so what part would be applying?
I have sent last week a
On 2020-Jun-25, Amit Kapila wrote:
> +1. I also think let's drop the idea of exposing a function for this
> value and revert the min_safe_lsn part of the work as proposed by
> Michael above [1] excluding the function pg_wal_oldest_lsn() in that
> patch. Then, we can expose this as a new stat
On Wed, Jun 24, 2020 at 8:45 PM Alvaro Herrera wrote:
>
> On 2020-Jun-24, Fujii Masao wrote:
>
> > On 2020/06/24 8:39, Alvaro Herrera wrote:
>
> > > I think we should publish the value from wal_keep_segments separately
> > > from max_slot_wal_keep_size. ISTM that the user might decide to change
On 2020-Jun-24, Fujii Masao wrote:
> On 2020/06/24 8:39, Alvaro Herrera wrote:
> > I think we should publish the value from wal_keep_segments separately
> > from max_slot_wal_keep_size. ISTM that the user might decide to change
> > or remove wal_keep_segments and be suddenly at risk of losing
On Wed, Jun 24, 2020 at 2:37 PM Fujii Masao wrote:
>
> On 2020/06/23 15:27, Amit Kapila wrote:
> >
> > Having a separate function for this seems like a good idea but can we
> > consider displaying it in a view like pg_stat_replication_slots as we
> > are discussing a nearby thread to have such a
On 2020/06/24 8:39, Alvaro Herrera wrote:
On 2020-Jun-23, Kyotaro Horiguchi wrote:
At Tue, 23 Jun 2020 11:50:34 +0530, Amit Kapila wrote
in
On Mon, Jun 22, 2020 at 6:32 PM Fujii Masao wrote:
We should expose the LSN calculated from
"the current WAL LSN - max(wal_keep_segments * 16MB,
On 2020/06/23 15:27, Amit Kapila wrote:
On Tue, Jun 23, 2020 at 7:47 AM Fujii Masao wrote:
On 2020/06/23 10:10, Kyotaro Horiguchi wrote:
At Mon, 22 Jun 2020 22:02:51 +0900, Fujii Masao
wrote in
I feel such a function is good to have but I am not sure if there is a
need to tie it with
On 2020-Jun-23, Kyotaro Horiguchi wrote:
> At Tue, 23 Jun 2020 11:50:34 +0530, Amit Kapila
> wrote in
> > On Mon, Jun 22, 2020 at 6:32 PM Fujii Masao
> > wrote:
> > > We should expose the LSN calculated from
> > > "the current WAL LSN - max(wal_keep_segments * 16MB,
> > >
At Tue, 23 Jun 2020 11:50:34 +0530, Amit Kapila wrote
in
> On Mon, Jun 22, 2020 at 6:32 PM Fujii Masao
> wrote:
> >
> > On 2020/06/22 21:01, Amit Kapila wrote:
> > > On Mon, Jun 22, 2020 at 11:19 AM Michael Paquier
> > > wrote:
> > >>
> > >> On Sat, Jun 20, 2020 at 03:53:54PM +0900, Michael
On Tue, Jun 23, 2020 at 7:47 AM Fujii Masao wrote:
>
> On 2020/06/23 10:10, Kyotaro Horiguchi wrote:
> > At Mon, 22 Jun 2020 22:02:51 +0900, Fujii Masao
> > wrote in
> >>
> >>> I feel such a function is good to have but I am not sure if there is a
> >>> need to tie it with the removal of
On Mon, Jun 22, 2020 at 6:32 PM Fujii Masao wrote:
>
> On 2020/06/22 21:01, Amit Kapila wrote:
> > On Mon, Jun 22, 2020 at 11:19 AM Michael Paquier
> > wrote:
> >>
> >> On Sat, Jun 20, 2020 at 03:53:54PM +0900, Michael Paquier wrote:
> >>> On Sat, Jun 20, 2020 at 09:45:52AM +0530, Amit Kapila
On 2020/06/23 10:10, Kyotaro Horiguchi wrote:
At Mon, 22 Jun 2020 22:02:51 +0900, Fujii Masao
wrote in
On 2020/06/22 21:01, Amit Kapila wrote:
On Mon, Jun 22, 2020 at 11:19 AM Michael Paquier
wrote:
On Sat, Jun 20, 2020 at 03:53:54PM +0900, Michael Paquier wrote:
On Sat, Jun 20,
On Tue, Jun 23, 2020 at 10:10:37AM +0900, Kyotaro Horiguchi wrote:
> At Mon, 22 Jun 2020 22:02:51 +0900, Fujii Masao
> wrote in
>> Isn't this confusing? I think that we should store the last removed
>> WAL segment to somewhere (e.g., pg_control) and restore it at
>> the startup, so that we can
At Mon, 22 Jun 2020 22:02:51 +0900, Fujii Masao
wrote in
>
>
> On 2020/06/22 21:01, Amit Kapila wrote:
> > On Mon, Jun 22, 2020 at 11:19 AM Michael Paquier
> > wrote:
> >>
> >> On Sat, Jun 20, 2020 at 03:53:54PM +0900, Michael Paquier wrote:
> >>> On Sat, Jun 20, 2020 at 09:45:52AM +0530,
On 2020/06/22 21:01, Amit Kapila wrote:
On Mon, Jun 22, 2020 at 11:19 AM Michael Paquier wrote:
On Sat, Jun 20, 2020 at 03:53:54PM +0900, Michael Paquier wrote:
On Sat, Jun 20, 2020 at 09:45:52AM +0530, Amit Kapila wrote:
Isn't this information specific to checkpoints, so maybe better to
On Mon, Jun 22, 2020 at 11:19 AM Michael Paquier wrote:
>
> On Sat, Jun 20, 2020 at 03:53:54PM +0900, Michael Paquier wrote:
> > On Sat, Jun 20, 2020 at 09:45:52AM +0530, Amit Kapila wrote:
> >> Isn't this information specific to checkpoints, so maybe better to
> >> display in view
On Sat, Jun 20, 2020 at 03:53:54PM +0900, Michael Paquier wrote:
> On Sat, Jun 20, 2020 at 09:45:52AM +0530, Amit Kapila wrote:
>> Isn't this information specific to checkpoints, so maybe better to
>> display in view pg_stat_bgwriter?
>
> Not sure that's a good match. If we decide to expose
On Sat, Jun 20, 2020 at 09:45:52AM +0530, Amit Kapila wrote:
> On Sat, Jun 20, 2020 at 7:12 AM Alvaro Herrera
> wrote:
>> I don't disagree with removing the LSN column, but at the same time we
>> need to provide *some* way for users to monitor this, so let's add a
>> function to extract the
On Sat, Jun 20, 2020 at 7:12 AM Alvaro Herrera wrote:
>
> On 2020-Jun-19, Michael Paquier wrote:
>
> > If we want to make this happen, I am afraid that the time is short as
> > beta2 is planned for next week. As the version will be likely tagged
> > by Monday US time, it would be good to get
On 2020-Jun-19, Michael Paquier wrote:
> If we want to make this happen, I am afraid that the time is short as
> beta2 is planned for next week. As the version will be likely tagged
> by Monday US time, it would be good to get this addressed within 48
> hours to give some room to the buildfarm
On 2020-Jun-20, Fujii Masao wrote:
> It's better if we can do that. But I think that we should hear Alvaro's
> opinion
> about this before rushing to push the patch. Even if we miss beta2 as the
> result
> of that, I'm ok. We would be able to push something better into beta3.
> So, CC Alvaro.
On 2020/06/19 21:15, Michael Paquier wrote:
On Fri, Jun 19, 2020 at 05:34:01PM +0900, Fujii Masao wrote:
On 2020/06/19 16:43, Kyotaro Horiguchi wrote:
At Fri, 19 Jun 2020 16:36:09 +0900, Michael Paquier wrote
in
So we usually avoid to do that between betas, but my take here is that
a
At Fri, 19 Jun 2020 21:15:52 +0900, Michael Paquier wrote
in
> On Fri, Jun 19, 2020 at 05:34:01PM +0900, Fujii Masao wrote:
> > On 2020/06/19 16:43, Kyotaro Horiguchi wrote:
> >> At Fri, 19 Jun 2020 16:36:09 +0900, Michael Paquier
> >> wrote in
> >>> So we usually avoid to do that between
On Fri, Jun 19, 2020 at 05:34:01PM +0900, Fujii Masao wrote:
> On 2020/06/19 16:43, Kyotaro Horiguchi wrote:
>> At Fri, 19 Jun 2020 16:36:09 +0900, Michael Paquier
>> wrote in
>>> So we usually avoid to do that between betas, but my take here is that
>>> a catalog bump is better than regretting
On 2020/06/19 16:43, Kyotaro Horiguchi wrote:
At Fri, 19 Jun 2020 16:36:09 +0900, Michael Paquier wrote
in
On Fri, Jun 19, 2020 at 04:13:27PM +0900, Fujii Masao wrote:
Agreed. But isn't it too late to remove the columns (i.e., change
the catalog) for v13? Because v13 beta1 was already
At Fri, 19 Jun 2020 16:36:09 +0900, Michael Paquier wrote
in
> On Fri, Jun 19, 2020 at 04:13:27PM +0900, Fujii Masao wrote:
> > Agreed. But isn't it too late to remove the columns (i.e., change
> > the catalog) for v13? Because v13 beta1 was already released.
> > IIUC the catalog should not be
On Fri, Jun 19, 2020 at 04:13:27PM +0900, Fujii Masao wrote:
> Agreed. But isn't it too late to remove the columns (i.e., change
> the catalog) for v13? Because v13 beta1 was already released.
> IIUC the catalog should not be changed since beta1 release so that
> users can upgrade PostgreSQL
On 2020/06/19 10:39, Michael Paquier wrote:
On Fri, Jun 19, 2020 at 10:02:54AM +0900, Kyotaro Horiguchi wrote:
At Thu, 18 Jun 2020 18:18:37 +0530, Amit Kapila wrote
in
It is a little unclear to me how this or any proposed patch will solve
the original problem reported by Fujii-San?
At Fri, 19 Jun 2020 08:59:48 +0530, Amit Kapila wrote
in
> > > > Mmm. pg_walfile_name seems too specialize to
> > > > pg_stop_backup(). (pg_walfile_name_offset() returns wrong result for
> > > > segment boundaries.) I'm not willing to do that only to follow such
> > > > suspicious(?)
At Fri, 19 Jun 2020 09:09:03 +0530, Amit Kapila wrote
in
> On Fri, Jun 19, 2020 at 8:44 AM Kyotaro Horiguchi
> wrote:
> >
> > At Fri, 19 Jun 2020 10:39:58 +0900, Michael Paquier
> > wrote in
> > > Honestly, I find a bit silly the design to compute and use the same
> > > minimum LSN value for
On Fri, Jun 19, 2020 at 8:44 AM Kyotaro Horiguchi
wrote:
>
> At Fri, 19 Jun 2020 10:39:58 +0900, Michael Paquier
> wrote in
> > Honestly, I find a bit silly the design to compute and use the same
> > minimum LSN value for all the tuples returned by
> > pg_get_replication_slots, and you can
On Fri, Jun 19, 2020 at 6:32 AM Kyotaro Horiguchi
wrote:
>
> At Thu, 18 Jun 2020 18:18:37 +0530, Amit Kapila
> wrote in
> > On Thu, Jun 18, 2020 at 11:52 AM Kyotaro Horiguchi
> > wrote:
> > >
> > > At Wed, 17 Jun 2020 21:37:55 +0900, Fujii Masao
> > > wrote in
> > > > On 2020/06/15 16:35,
At Fri, 19 Jun 2020 10:39:58 +0900, Michael Paquier wrote
in
> On Fri, Jun 19, 2020 at 10:02:54AM +0900, Kyotaro Horiguchi wrote:
> > At Thu, 18 Jun 2020 18:18:37 +0530, Amit Kapila
> > wrote in
> >> It is a little unclear to me how this or any proposed patch will solve
> >> the original
On Fri, Jun 19, 2020 at 10:02:54AM +0900, Kyotaro Horiguchi wrote:
> At Thu, 18 Jun 2020 18:18:37 +0530, Amit Kapila
> wrote in
>> It is a little unclear to me how this or any proposed patch will solve
>> the original problem reported by Fujii-San? Basically, the problem
>> arises because we
At Thu, 18 Jun 2020 18:18:37 +0530, Amit Kapila wrote
in
> On Thu, Jun 18, 2020 at 11:52 AM Kyotaro Horiguchi
> wrote:
> >
> > At Wed, 17 Jun 2020 21:37:55 +0900, Fujii Masao
> > wrote in
> > > On 2020/06/15 16:35, Kyotaro Horiguchi wrote:
> > > Isn't it better to use 1 as the second
On Thu, Jun 18, 2020 at 11:52 AM Kyotaro Horiguchi
wrote:
>
> At Wed, 17 Jun 2020 21:37:55 +0900, Fujii Masao
> wrote in
> > On 2020/06/15 16:35, Kyotaro Horiguchi wrote:
> > Isn't it better to use 1 as the second argument of the above,
> > in order to address the issue that I reported
Thanks for the comments.
At Wed, 17 Jun 2020 21:37:55 +0900, Fujii Masao
wrote in
> On 2020/06/15 16:35, Kyotaro Horiguchi wrote:
> > At Mon, 15 Jun 2020 13:44:31 +0900, Michael Paquier
> > wrote in
> >> On Mon, Jun 15, 2020 at 12:40:03PM +0900, Fujii Masao wrote:
> >>> BTW, I just wonder why
On 2020/06/15 16:35, Kyotaro Horiguchi wrote:
At Mon, 15 Jun 2020 13:44:31 +0900, Michael Paquier wrote
in
On Mon, Jun 15, 2020 at 12:40:03PM +0900, Fujii Masao wrote:
BTW, I just wonder why each row in pg_replication_slots needs to have
min_safe_lsn column? Basically min_safe_lsn should
At Mon, 15 Jun 2020 13:44:31 +0900, Michael Paquier wrote
in
> On Mon, Jun 15, 2020 at 12:40:03PM +0900, Fujii Masao wrote:
> > BTW, I just wonder why each row in pg_replication_slots needs to have
> > min_safe_lsn column? Basically min_safe_lsn should be the same between
> > every replication
On Mon, Jun 15, 2020 at 12:40:03PM +0900, Fujii Masao wrote:
> BTW, I just wonder why each row in pg_replication_slots needs to have
> min_safe_lsn column? Basically min_safe_lsn should be the same between
> every replication slots.
Indeed, that's confusing in its current shape. I would buy
Hi,
Per the docs, pg_replication_slots.min_safe_lsn inedicates "the minimum
LSN currently available for walsenders". When I executed pg_walfile_name()
with min_safe_lsn, the function returned the name of the last removed
WAL file instead of minimum available WAL file name. This happens because
72 matches
Mail list logo
