Robert Haas writes:
> On Fri, Sep 29, 2017 at 12:43 PM, Tom Lane wrote:
>> Robert Haas writes:
>>> If I understand correctly, problem #1 is that get_rel_oids() can emit
>>> a user-visible cache lookup failure message. There is a proposed patch
>>> by Michael Paquier which appears to implement th
On Fri, Sep 29, 2017 at 12:43 PM, Tom Lane wrote:
> Robert Haas writes:
>> If I understand correctly, problem #1 is that get_rel_oids() can emit
>> a user-visible cache lookup failure message. There is a proposed patch
>> by Michael Paquier which appears to implement the design suggested by
>> To
Robert Haas writes:
> If I understand correctly, problem #1 is that get_rel_oids() can emit
> a user-visible cache lookup failure message. There is a proposed patch
> by Michael Paquier which appears to implement the design suggested by
> Tom. I think that the normal procedure would be for Tom to
On 9/29/17, 11:18 AM, "Robert Haas" wrote:
> I don't think I understand problem #2. I think the concern is about
> reporting the proper relation name when VACUUM cascades from a
> partitioned table to its children and then some kind of concurrent DDL
> happens, but I don't see a clear explanation
On Thu, Sep 28, 2017 at 1:31 AM, Noah Misch wrote:
> This thread now has two open items, both of them pertaining to VACUUM error
> messages involving partitioning. The pair is probably best treated as a
> single open item.
If I understand correctly, problem #1 is that get_rel_oids() can emit
a u
On Fri, Sep 22, 2017 at 03:13:10PM -0400, Tom Lane wrote:
> Somebody inserted this into vacuum.c's get_rel_oids():
>
> tuple = SearchSysCache1(RELOID, ObjectIdGetDatum(relid));
> if (!HeapTupleIsValid(tuple))
> elog(ERROR, "cache lookup failed for relation %u", relid);
On 2017/09/26 11:12, Michael Paquier wrote:
> On Tue, Sep 26, 2017 at 10:54 AM, Amit Langote
> wrote:
>> I think that's right, although, I don't see any new RangeVar created under
>> vacuum() at the moment. Maybe, you're referring to the Nathan's patch
>> that perhaps does that.
>
> Yes, you can
On 2017/09/26 11:14, Michael Paquier wrote:
> On Tue, Sep 26, 2017 at 10:55 AM, Amit Langote wrote:
>> On 2017/09/26 9:51, Michael Paquier wrote:
>>> On Tue, Sep 26, 2017 at 8:48 AM, Michael Paquier wrote:
Something like that looks like a good compromise for v10. I would
rather see a more
On Tue, Sep 26, 2017 at 10:55 AM, Amit Langote
wrote:
> On 2017/09/26 9:51, Michael Paquier wrote:
>> On Tue, Sep 26, 2017 at 8:48 AM, Michael Paquier
>> wrote:
>>> On Mon, Sep 25, 2017 at 11:32 PM, Tom Lane wrote:
Yeah, I'd noticed that while reviewing the vacuum-multiple-tables patch.
>>>
On Tue, Sep 26, 2017 at 10:54 AM, Amit Langote
wrote:
> I think that's right, although, I don't see any new RangeVar created under
> vacuum() at the moment. Maybe, you're referring to the Nathan's patch
> that perhaps does that.
Yes, you can check what it does here (last version):
766556dd-aa3c-
On 2017/09/26 9:51, Michael Paquier wrote:
> On Tue, Sep 26, 2017 at 8:48 AM, Michael Paquier
> wrote:
>> On Mon, Sep 25, 2017 at 11:32 PM, Tom Lane wrote:
>>> Yeah, I'd noticed that while reviewing the vacuum-multiple-tables patch.
>>> My thought about fixing it was to pass a null RangeVar when
On 2017/09/25 18:37, Michael Paquier wrote:
> On Mon, Sep 25, 2017 at 4:42 PM, Amit Langote
> wrote:
>> On 2017/09/25 12:10, Michael Paquier wrote:
>> Hmm, I'm not sure if we need to lock the partitions, too. Locks taken by
>> find_all_inheritors() will be gone once the already-running transactio
On Tue, Sep 26, 2017 at 8:48 AM, Michael Paquier
wrote:
> On Mon, Sep 25, 2017 at 11:32 PM, Tom Lane wrote:
>> Yeah, I'd noticed that while reviewing the vacuum-multiple-tables patch.
>> My thought about fixing it was to pass a null RangeVar when handling a
>> table we'd identified through inheri
On 9/25/17, 6:51 PM, "Michael Paquier" wrote:
>> +* Take a lock here for the relation lookup. If ANALYZE or
>> VACUUM spawn
>> +* multiple transactions, the lock taken here will be gone
>> once the
>> +* current transaction running commits, which c
On Tue, Sep 26, 2017 at 1:47 AM, Bossart, Nathan wrote:
> On 9/24/17, 10:12 PM, "Michael Paquier" wrote:
>> Attached is a proposal of patch.
>
> The patch seems reasonable to me, and I haven't encountered any issues in
> my tests, even after applying the vacuum-multiple-relations patch on top
> o
On Mon, Sep 25, 2017 at 11:32 PM, Tom Lane wrote:
> Yeah, I'd noticed that while reviewing the vacuum-multiple-tables patch.
> My thought about fixing it was to pass a null RangeVar when handling a
> table we'd identified through inheritance or pg_class-scanning, to
> indicate that this wasn't a t
On 9/24/17, 10:12 PM, "Michael Paquier" wrote:
> Attached is a proposal of patch.
The patch seems reasonable to me, and I haven't encountered any issues in
my tests, even after applying the vacuum-multiple-relations patch on top
of it.
+* Take a lock here for the relation lookup.
Amit Langote writes:
> On 2017/09/25 12:10, Michael Paquier wrote:
>> As long as I don't forget... Another thing currently on HEAD and
>> REL_10_STABLE is that OIDs of partitioned tables are used, but the
>> RangeVar of the parent is used for error reports. This leads to
>> incorrect reports if a
On Mon, Sep 25, 2017 at 8:22 PM, Michael Paquier
wrote:
> On Mon, Sep 25, 2017 at 7:57 PM, Masahiko Sawada
> wrote:
>> FWIW, the same thing can happen when specifying an invalid replication
>> origin name to pg_replication_origin_advance() and
>> pg_replication_origin_progress(). These probably
On Mon, Sep 25, 2017 at 7:57 PM, Masahiko Sawada wrote:
> FWIW, the same thing can happen when specifying an invalid replication
> origin name to pg_replication_origin_advance() and
> pg_replication_origin_progress(). These probably should fixed as well.
I have spawned a thread about that stuff t
On Mon, Sep 25, 2017 at 12:10 PM, Michael Paquier
wrote:
> On Sat, Sep 23, 2017 at 4:13 AM, Tom Lane wrote:
>> Somebody inserted this into vacuum.c's get_rel_oids():
>>
>> tuple = SearchSysCache1(RELOID, ObjectIdGetDatum(relid));
>> if (!HeapTupleIsValid(tuple))
>> elo
On Mon, Sep 25, 2017 at 4:42 PM, Amit Langote
wrote:
> On 2017/09/25 12:10, Michael Paquier wrote:
> Hmm, I'm not sure if we need to lock the partitions, too. Locks taken by
> find_all_inheritors() will be gone once the already-running transaction is
> ended by the caller (vacuum()). get_rel_oid
On 2017/09/25 12:10, Michael Paquier wrote:
> On Sat, Sep 23, 2017 at 4:13 AM, Tom Lane wrote:
>> Somebody inserted this into vacuum.c's get_rel_oids():
>>
>> tuple = SearchSysCache1(RELOID, ObjectIdGetDatum(relid));
>> if (!HeapTupleIsValid(tuple))
>> elog(ERROR, "cach
On Sat, Sep 23, 2017 at 4:13 AM, Tom Lane wrote:
> Somebody inserted this into vacuum.c's get_rel_oids():
>
> tuple = SearchSysCache1(RELOID, ObjectIdGetDatum(relid));
> if (!HeapTupleIsValid(tuple))
> elog(ERROR, "cache lookup failed for relation %u", relid);
>
> appar
Somebody inserted this into vacuum.c's get_rel_oids():
tuple = SearchSysCache1(RELOID, ObjectIdGetDatum(relid));
if (!HeapTupleIsValid(tuple))
elog(ERROR, "cache lookup failed for relation %u", relid);
apparently without having read the very verbose comment two lines a
25 matches
Mail list logo
