On Fri, Jan 31, 2020 at 12:42:13AM -0800, Noah Misch wrote:
> On Thu, Jan 30, 2020 at 04:34:33PM +0100, Dmitry Dolgov wrote:
> > Just to clarify, since the CF item for this patch was withdrawn
> > recently. Does it mean that eventually the thread [1] covers this one
> > too?
> >
> > [1]:
> > http
On Fri, Jun 28, 2019 at 10:06:28AM -0700, Noah Misch wrote:
> On Sun, Feb 17, 2019 at 11:31:03PM -0800, Noah Misch wrote:
> > I'm forking this thread from
> > https://postgr.es/m/flat/20190202083822.gc32...@gust.leadboat.com, which
> > reported a race condition involving the "apparent wraparound" s
On Thu, Jan 30, 2020 at 04:34:33PM +0100, Dmitry Dolgov wrote:
> > On Sun, Nov 17, 2019 at 10:14:26PM -0800, Noah Misch wrote:
> > > I'm probably missing something, so just wanted to clarify. Do I
> > > understand correctly, that thread [1] and this one are independent, and
> > > it is assumed in t
> On Sun, Nov 17, 2019 at 10:14:26PM -0800, Noah Misch wrote:
>
> > I'm probably missing something, so just wanted to clarify. Do I
> > understand correctly, that thread [1] and this one are independent, and
> > it is assumed in the scenario above that we're at the end of XID space,
> > but not nec
> On Sun, Nov 17, 2019 at 10:14:26PM -0800, Noah Misch wrote:
>
> Though I did reproduce this bug, I'm motivated by the abstract problem more
> than any particular way to reproduce it. Commit 996d273 inspired me; by
> removing a GetCurrentTransactionId(), it allowed the global xmin to advance at
>
On Sun, Nov 17, 2019 at 12:56:52PM +0100, Dmitry Dolgov wrote:
> > On Wed, Jul 31, 2019 at 11:51:17PM -0700, Noah Misch wrote:
> > > Also, if I understand the data-loss hazard properly, it's what you
> > > said in the other thread: the latest_page_number could advance after
> > > we make our decisi
> On Wed, Jul 31, 2019 at 11:51:17PM -0700, Noah Misch wrote:
Hi,
> > Also, if I understand the data-loss hazard properly, it's what you
> > said in the other thread: the latest_page_number could advance after
> > we make our decision about what to truncate, and then maybe we could
> > truncate n
On Mon, Nov 04, 2019 at 03:43:09PM -0800, Noah Misch wrote:
> On Mon, Nov 04, 2019 at 03:26:35PM +1300, Thomas Munro wrote:
> > On Thu, Aug 1, 2019 at 6:51 PM Noah Misch wrote:
> > > vac_truncate_clog() instance 1 starts, considers segment ABCD eligible to
> > > unlink
> > > vac_truncate_clog() i
On Mon, Nov 04, 2019 at 03:26:35PM +1300, Thomas Munro wrote:
> On Thu, Aug 1, 2019 at 6:51 PM Noah Misch wrote:
> > vac_truncate_clog() instance 1 starts, considers segment ABCD eligible to
> > unlink
> > vac_truncate_clog() instance 2 starts, considers segment ABCD eligible to
> > unlink
> > v
On Thu, Aug 1, 2019 at 6:51 PM Noah Misch wrote:
> vac_truncate_clog() instance 1 starts, considers segment ABCD eligible to
> unlink
> vac_truncate_clog() instance 2 starts, considers segment ABCD eligible to
> unlink
> vac_truncate_clog() instance 1 unlinks segment ABCD
> vac_truncate_clog() i
On Mon, Jul 29, 2019 at 12:58:17PM -0400, Tom Lane wrote:
> > On Sun, Feb 17, 2019 at 11:31:03PM -0800, Noah Misch wrote:
> >>> b. Arrange so only one backend runs vac_truncate_clog() at a time. Other
> >>> than
> >>> AsyncCtl, every SLRU truncation appears in vac_truncate_clog(), in a
> >>> chec
Noah Misch writes:
> On Sun, Feb 17, 2019 at 11:31:03PM -0800, Noah Misch wrote:
>>> b. Arrange so only one backend runs vac_truncate_clog() at a time. Other
>>> than
>>> AsyncCtl, every SLRU truncation appears in vac_truncate_clog(), in a
>>> checkpoint, or in the startup process. Hence, also
On Sun, Feb 17, 2019 at 11:31:03PM -0800, Noah Misch wrote:
> I'm forking this thread from
> https://postgr.es/m/flat/20190202083822.gc32...@gust.leadboat.com, which
> reported a race condition involving the "apparent wraparound" safety check in
> SimpleLruTruncate():
>
> On Wed, Feb 13, 2019 at 1
I'm forking this thread from
https://postgr.es/m/flat/20190202083822.gc32...@gust.leadboat.com, which
reported a race condition involving the "apparent wraparound" safety check in
SimpleLruTruncate():
On Wed, Feb 13, 2019 at 11:26:23PM -0800, Noah Misch wrote:
> 1. The result of the test is valid
14 matches
Mail list logo
