James Coleman writes:
> On Wed, Jan 13, 2021 at 5:00 PM Tom Lane wrote:
>> [ raised eyebrow ] Surely REINDEX and VACUUM can't run on the same
>> table at the same time.
> + Like any long-running transaction, CREATE INDEX on a
> + table can affect which tuples can be removed by concurrent
> +
On Wed, Jan 13, 2021 at 5:00 PM Tom Lane wrote:
>
> James Coleman writes:
> > On Wed, Jan 13, 2021 at 4:29 PM Tom Lane wrote:
> >> but the antecedent of "a table" is a bit unclear; people might
> >> wonder if it means the table being reindexed.
>
> > It does mean the table being reindexed; the
James Coleman writes:
> On Wed, Jan 13, 2021 at 4:29 PM Tom Lane wrote:
>> but the antecedent of "a table" is a bit unclear; people might
>> wonder if it means the table being reindexed.
> It does mean the table being reindexed; the last phrase says "any
> table" meaning "any other table".
[
On Wed, Jan 13, 2021 at 4:29 PM Tom Lane wrote:
>
> Alvaro Herrera writes:
> > On 2021-Jan-13, James Coleman wrote:
> This is true. So I propose
> Like any long-running transaction, REINDEX can
> affect which tuples can be removed by concurrent
> VACUUM
> on any table.
Alvaro Herrera writes:
> On 2021-Jan-13, James Coleman wrote:
This is true. So I propose
Like any long-running transaction, REINDEX can
affect which tuples can be removed by concurrent VACUUM
on any table.
>> Looks like what got committed is "REINDEX on a table" not "on
On 2021-Jan-13, James Coleman wrote:
> On Wed, Jan 13, 2021 at 4:05 PM Alvaro Herrera
> wrote:
> >
> > On 2021-Jan-13, James Coleman wrote:
> >
> > > On Wed, Jan 13, 2021 at 12:33 PM Alvaro Herrera
> > > wrote:
> >
> > > > This is true. So I propose
> > > >
> > > > Like any long-running
On 2021-Jan-13, Alvaro Herrera wrote:
> I wondered about noting whether only processes in the current database
> are affected, but then I noticed that the current code since commit
> dc7420c2c927 uses a completely different algorithm than what we had with
> GetOldestXmin() and does not consider
On Wed, Jan 13, 2021 at 4:05 PM Alvaro Herrera wrote:
>
> On 2021-Jan-13, James Coleman wrote:
>
> > On Wed, Jan 13, 2021 at 12:33 PM Alvaro Herrera
> > wrote:
>
> > > This is true. So I propose
> > >
> > > Like any long-running transaction, REINDEX can
> > > affect which tuples can be
On 2021-Jan-13, James Coleman wrote:
> On Wed, Jan 13, 2021 at 12:33 PM Alvaro Herrera
> wrote:
> > This is true. So I propose
> >
> > Like any long-running transaction, REINDEX can
> > affect which tuples can be removed by concurrent
> > VACUUM
> > on any table.
>
> That sounds
On Wed, Jan 13, 2021 at 12:33 PM Alvaro Herrera wrote:
>
> On 2021-Jan-13, James Coleman wrote:
>
> > On Wed, Jan 13, 2021 at 12:58 AM Michael Paquier
> > wrote:
> > >
> > > On Tue, Jan 12, 2021 at 04:51:39PM -0300, Alvaro Herrera wrote:
> > > > I looked into this again, and I didn't like what
On 2021-Jan-13, James Coleman wrote:
> On Wed, Jan 13, 2021 at 12:58 AM Michael Paquier wrote:
> >
> > On Tue, Jan 12, 2021 at 04:51:39PM -0300, Alvaro Herrera wrote:
> > > I looked into this again, and I didn't like what I had added to
> > > maintenance.sgml at all. It seems out of place where
On Wed, Jan 13, 2021 at 12:58 AM Michael Paquier wrote:
>
> On Tue, Jan 12, 2021 at 04:51:39PM -0300, Alvaro Herrera wrote:
> > I looked into this again, and I didn't like what I had added to
> > maintenance.sgml at all. It seems out of place where I put it; and I
> > couldn't find any great
On Tue, Jan 12, 2021 at 04:51:39PM -0300, Alvaro Herrera wrote:
> I looked into this again, and I didn't like what I had added to
> maintenance.sgml at all. It seems out of place where I put it; and I
> couldn't find any great spots. Going back to your original proposal,
> what about something
On 2020-Dec-01, James Coleman wrote:
> On Tue, Dec 1, 2020 at 6:51 PM Alvaro Herrera wrote:
> > Makes sense. ISTM that if we want to have a cautionary blurb CIC docs,
> > it should go in REINDEX CONCURRENTLY as well.
>
> Agreed. Or, alternatively, a blurb something like "Please note how CIC
>
On Tue, Dec 1, 2020 at 8:05 PM James Coleman wrote:
>
> On Tue, Dec 1, 2020 at 6:51 PM Alvaro Herrera wrote:
> >
> > On 2020-Nov-30, James Coleman wrote:
> >
> > > On Mon, Nov 30, 2020 at 4:53 PM Alvaro Herrera
> > > wrote:
> > > >
> > > > On 2020-Sep-30, Michael Paquier wrote:
> >
> > > >
On Tue, Dec 1, 2020 at 6:51 PM Alvaro Herrera wrote:
>
> On 2020-Nov-30, James Coleman wrote:
>
> > On Mon, Nov 30, 2020 at 4:53 PM Alvaro Herrera
> > wrote:
> > >
> > > On 2020-Sep-30, Michael Paquier wrote:
>
> > > Yeah, I think it might be more sensible to document this in
> > >
On 2020-Nov-30, James Coleman wrote:
> On Mon, Nov 30, 2020 at 4:53 PM Alvaro Herrera
> wrote:
> >
> > On 2020-Sep-30, Michael Paquier wrote:
> > Yeah, I think it might be more sensible to document this in
> > maintenance.sgml, as part of the paragraph that discusses removing
> > tuples "to
On Mon, Nov 30, 2020 at 4:53 PM Alvaro Herrera wrote:
>
> On 2020-Sep-30, Michael Paquier wrote:
>
> > +
> > + CREATE INDEX (including the
> > CONCURRENTLY
> > + option) commands are included when VACUUM calculates
> > what
> > + dead tuples are safe to remove even on tables other than
On 2020-Sep-30, Michael Paquier wrote:
> +
> + CREATE INDEX (including the
> CONCURRENTLY
> + option) commands are included when VACUUM calculates
> what
> + dead tuples are safe to remove even on tables other than the one being
> indexed.
> +
> FWIW, this is true as well for REINDEX
On 2020-Nov-30, Anastasia Lubennikova wrote:
> The commitfest is nearing the end and I wonder what is this discussion
> waiting for.
> It looks like the proposed patch received its fair share of review, so
> I mark it as ReadyForCommitter and lay responsibility for the final
> decision on them.
Status update for a commitfest entry.
The commitfest is nearing the end and I wonder what is this discussion waiting
for.
It looks like the proposed patch received its fair share of review, so I mark
it as ReadyForCommitter and lay responsibility for the final decision on them.
The new status
On Wed, Oct 21, 2020 at 3:25 PM David G. Johnston <
david.g.johns...@gmail.com> wrote:
>
> v3-0002 needs a rebase over the create_index.sgml page due to the change
> of the nearby xref to link. Attached as v4-0002 along with the original
> v3-0001.
>
>
attached...
Reading the commit message on
On Wed, Sep 30, 2020 at 2:10 AM Michael Paquier wrote:
> On Tue, Sep 08, 2020 at 01:25:21PM -0400, James Coleman wrote:
> > Álvaro's patch confused the current state of this thread, so I'm
> > reattaching (rebased) v2 as v3.
>
> +
> + CREATE INDEX (including the
> CONCURRENTLY
> + option)
On Tue, Sep 08, 2020 at 01:25:21PM -0400, James Coleman wrote:
> Álvaro's patch confused the current state of this thread, so I'm
> reattaching (rebased) v2 as v3.
+
+ CREATE INDEX (including the
CONCURRENTLY
+ option) commands are included when VACUUM calculates what
+ dead tuples are
On Fri, Jul 31, 2020 at 2:51 PM James Coleman wrote:
>
> On Thu, Jul 16, 2020 at 7:34 PM David Johnston
> wrote:
> >
> > The following review has been posted through the commitfest application:
> > make installcheck-world: not tested
> > Implements feature: not tested
> > Spec compliant:
On 2020-Aug-04, Alvaro Herrera wrote:
> diff --git a/src/include/storage/proc.h b/src/include/storage/proc.h
> index b20e2ad4f6..43c8ea3e31 100644
> --- a/src/include/storage/proc.h
> +++ b/src/include/storage/proc.h
> @@ -53,6 +53,8 @@ struct XidCache
> #define PROC_IS_AUTOVACUUM
On 2020-Mar-25, Andres Freund wrote:
> What I was thinking of was a new flag, with a distinct value from
> PROC_IN_VACUUM. It'd currently just be specified in the
> GetCurrentVirtualXIDs() calls in WaitForOlderSnapshots(). That'd avoid
> needing to wait for other CICs on different relations.
On Thu, Jul 16, 2020 at 7:34 PM David Johnston
wrote:
>
> The following review has been posted through the commitfest application:
> make installcheck-world: not tested
> Implements feature: not tested
> Spec compliant: not tested
> Documentation:tested, passed
>
>
The following review has been posted through the commitfest application:
make installcheck-world: not tested
Implements feature: not tested
Spec compliant: not tested
Documentation:tested, passed
James,
I'm on board with the point of pointing out explicitly the
On Thu, Apr 16, 2020 at 6:12 PM Andres Freund wrote:
>
> Hi,
>
> On 2020-04-15 21:44:48 -0400, James Coleman wrote:
> > On Wed, Apr 15, 2020 at 6:31 PM Andres Freund wrote:
> > > If it's about the xmin horizon for vacuum: I think we could probably
> > > avoid that using the same flag. As vacuum
Hi,
On 2020-04-15 21:44:48 -0400, James Coleman wrote:
> On Wed, Apr 15, 2020 at 6:31 PM Andres Freund wrote:
> > If it's about the xmin horizon for vacuum: I think we could probably
> > avoid that using the same flag. As vacuum cannot be run against a table
> > that has a CIC running (although
On Wed, Apr 15, 2020 at 6:31 PM Andres Freund wrote:
>
> Hi,
>
> On 2020-04-15 09:31:58 -0400, James Coleman wrote:
> > On Wed, Mar 25, 2020 at 3:58 PM Andres Freund wrote:
> > > On 2020-03-25 16:30:10 -0300, Alvaro Herrera wrote:
> > > > I posted this in November
> > > >
Hi,
On 2020-04-15 09:31:58 -0400, James Coleman wrote:
> On Wed, Mar 25, 2020 at 3:58 PM Andres Freund wrote:
> > On 2020-03-25 16:30:10 -0300, Alvaro Herrera wrote:
> > > I posted this in November
> > > https://postgr.es/m/20191101203310.GA12239@alvherre.pgsql but I didn't
> > > put time to go
On Wed, Mar 25, 2020 at 3:58 PM Andres Freund wrote:
>
> Hi,
>
> On 2020-03-25 16:30:10 -0300, Alvaro Herrera wrote:
> > I posted this in November
> > https://postgr.es/m/20191101203310.GA12239@alvherre.pgsql but I didn't
> > put time to go through the issues there.
>
> Oh, missed that.
>
>
> > I
On Wed, Mar 25, 2020 at 05:12:48PM -0300, Alvaro Herrera wrote:
> Hmm, that sounds more promising.
Haven't looked at that myself in details. But as I doubt that this
would be backpatched, wouldn't it be better to document the issue for
now?
--
Michael
signature.asc
Description: PGP signature
On 2020-Mar-25, Andres Freund wrote:
> > I don't know if my approach is exactly what Andres has in mind
>
> Not quite. I don't think it's generally correct for CIC to set
> PROC_IN_VACUUM. I'm doubtful it's the case even just for plain indexes -
> we don't want rows to be pruned away from under
Hi,
On 2020-03-25 16:30:10 -0300, Alvaro Herrera wrote:
> I posted this in November
> https://postgr.es/m/20191101203310.GA12239@alvherre.pgsql but I didn't
> put time to go through the issues there.
Oh, missed that.
> I don't know if my approach is exactly what Andres has in mind
Not quite.
Hi,
On 2020-03-25 15:24:44 -0400, James Coleman wrote:
> Andres: If we got this fixed in current PG would you be opposed to
> documenting the caveat in previous versions?
Not really. I'm just not confident it's going to be useful, given the
amount of details needed to be provided to really make
On 2020-Mar-25, James Coleman wrote:
> Alvaro: I think you had some ideas on this too; any chance you've know
> of a patch that anyone's got cooking?
I posted this in November
https://postgr.es/m/20191101203310.GA12239@alvherre.pgsql but I didn't
put time to go through the issues there. I don't
On Wed, Mar 25, 2020 at 3:19 PM Andres Freund wrote:
>
> Hi,
>
> On 2019-09-18 13:51:00 -0400, James Coleman wrote:
> > In my experience it's not immediately obvious (even after reading the
> > documentation) the implications of how concurrent index builds manage
> > transactions with respect to
Hi,
On 2019-09-18 13:51:00 -0400, James Coleman wrote:
> In my experience it's not immediately obvious (even after reading the
> documentation) the implications of how concurrent index builds manage
> transactions with respect to multiple concurrent index builds in
> flight at the same time.
>
>
On Sun, Sep 29, 2019 at 9:24 PM Michael Paquier wrote:
>
> On Sat, Sep 28, 2019 at 10:22:28PM -0300, Alvaro Herrera wrote:
> > I always thought that create index concurrently was prevented from
> > running concurrently in a table by the ShareUpdateExclusive lock that's
> > held during the
I went ahead and registered this in the current only CF as
https://commitfest.postgresql.org/27/2454/
Alvaro: Would you like to be added as a reviewer?
James
On Sat, Sep 28, 2019 at 10:22:28PM -0300, Alvaro Herrera wrote:
> I always thought that create index concurrently was prevented from
> running concurrently in a table by the ShareUpdateExclusive lock that's
> held during the operation.
REINDEX CONCURRENTLY and CIC can deadlock while waiting for
On 2019-Sep-28, James Coleman wrote:
> I believe caveats like this are worth calling out rather than
> expecting users to have to understand the implementation details an
> work out the implications on their own.
I agree.
> I read Alvaro as referring to the fact that the docs already call out
>
On Sat, Sep 28, 2019 at 9:56 PM Bruce Momjian wrote:
>
> On Sat, Sep 28, 2019 at 09:54:48PM -0400, James Coleman wrote:
> > On Sat, Sep 28, 2019 at 9:22 PM Alvaro Herrera
> > wrote:
> > >
> > > On 2019-Sep-28, Bruce Momjian wrote:
> > >
> > > > The CREATE INDEX docs already say:
> > > >
> > > >
On Sat, Sep 28, 2019 at 09:54:48PM -0400, James Coleman wrote:
> On Sat, Sep 28, 2019 at 9:22 PM Alvaro Herrera
> wrote:
> >
> > On 2019-Sep-28, Bruce Momjian wrote:
> >
> > > The CREATE INDEX docs already say:
> > >
> > > In a concurrent index build, the index is actually entered into
> > >
On Sat, Sep 28, 2019 at 9:22 PM Alvaro Herrera wrote:
>
> On 2019-Sep-28, Bruce Momjian wrote:
>
> > The CREATE INDEX docs already say:
> >
> > In a concurrent index build, the index is actually entered into
> > the system catalogs in one transaction, then two table scans occur in
> >
On 2019-Sep-28, Bruce Momjian wrote:
> The CREATE INDEX docs already say:
>
> In a concurrent index build, the index is actually entered into
> the system catalogs in one transaction, then two table scans occur in
> two more transactions. Before each table scan, the index build must
On Wed, Sep 18, 2019 at 01:51:00PM -0400, James Coleman wrote:
> In my experience it's not immediately obvious (even after reading the
> documentation) the implications of how concurrent index builds manage
> transactions with respect to multiple concurrent index builds in
> flight at the same
In my experience it's not immediately obvious (even after reading the
documentation) the implications of how concurrent index builds manage
transactions with respect to multiple concurrent index builds in
flight at the same time.
Specifically, as I understand multiple concurrent index builds
51 matches
Mail list logo
