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
> + VA
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 l
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".
[ ra
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 any",
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 t
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 da
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 I
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 spot
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 li
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:
> >
> > > > Yeah
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
> > > maintenance.s
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 sav
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 t
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 o
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 0
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) c
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 sa
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. Since
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
>
> Jam
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 "concu
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 c
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 i
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
> > > > https://postgr.es/m/2019
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 t
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 u
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. I
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 s
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 m
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 operatio
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 ea
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 time
50 matches
Mail list logo
