On 2019/04/27 3:57, Tom Lane wrote:
> Alvaro Herrera writes:
>> Um, this one doesn't apply because of yesterday's 87259588d0ab.
>
> Before we spend too much time on minutiae, we should ask ourselves whether
> this patch is even going in the right direction. I'm not sure.
>
> One point is that
I went ahead and pushed the stopgap patches, along with regression tests
based on yours. The tests show the current (i.e. wrong) behavior for
index comment and relfilenode reuse. I think that whenever we fix that,
we can just adjust the expected output instead of adding more tests.
Alvaro Herrera writes:
> Um, this one doesn't apply because of yesterday's 87259588d0ab.
Before we spend too much time on minutiae, we should ask ourselves whether
this patch is even going in the right direction. I'm not sure.
One point is that if we simply adopt the old index as-is, we won't
Hi,
Please trim the quoted text in your reply.
On 2019-Apr-26, Amit Langote wrote:
> Per Alvaro's report, regression tests added weren't portable. Fixed that
> in the attached updated patch.
Um, this one doesn't apply because of yesterday's 87259588d0ab.
--
Álvaro Herrera
On 2019/04/25 19:02, Amit Langote wrote:
> On 2019/04/25 11:21, Amit Langote wrote:
>> On 2019/04/25 8:27, Tom Lane wrote:
>>> BTW, I hadn't ever looked closely at what the index reuse code
>>> does, and now that I have, my heart just sinks. I think that
>>> logic needs to be nuked from orbit.
On Thu, Apr 25, 2019 at 10:46 PM Alvaro Herrera
wrote:
> Haven't read the patch, but I tried applying it on top of my tablespace
> fixing patch ... and my first report is that this query in regress fails
> (three times):
>
> select conname, obj_description(oid, 'pg_constraint') from
Haven't read the patch, but I tried applying it on top of my tablespace
fixing patch ... and my first report is that this query in regress fails
(three times):
select conname, obj_description(oid, 'pg_constraint') from pg_constraint where
conname = 'c_chk' order by 1, 2;
conname |
On 2019/04/25 11:21, Amit Langote wrote:
> On 2019/04/25 8:27, Tom Lane wrote:
>> BTW, I hadn't ever looked closely at what the index reuse code
>> does, and now that I have, my heart just sinks. I think that
>> logic needs to be nuked from orbit. RelationPreserveStorage was
>> never meant to be
On 2019/04/25 8:27, Tom Lane wrote:
> Amit Langote writes:
>> On 2019/04/24 7:03, Tom Lane wrote:
>>> ISTM we could work around the problem with the attached, which I think
>>> is a good change independently of anything else.
>
>> Agreed.
>
> After thinking about it more, it seems like a bad
Amit Langote writes:
> On 2019/04/24 7:03, Tom Lane wrote:
>> ISTM we could work around the problem with the attached, which I think
>> is a good change independently of anything else.
> Agreed.
After thinking about it more, it seems like a bad idea to put the check
in CheckIndexCompatible;
Thanks for looking at this.
On 2019/04/24 7:03, Tom Lane wrote:
> ISTM we could work around the problem with the attached, which I think
> is a good change independently of anything else.
Agreed.
> There is still an issue, which manifests in both 11 and HEAD, namely
> that the code also
ISTM we could work around the problem with the attached, which I think
is a good change independently of anything else.
There is still an issue, which manifests in both 11 and HEAD, namely
that the code also propagates the parent index's comment to any child
indexes. You can see that with this
On 2019/04/11 15:57, Michael Paquier wrote:
> On Wed, Mar 27, 2019 at 11:56:20AM +0900, Michael Paquier wrote:
>> Adding it to the section for older bugs sounds fine to me. Thanks for
>> doing so.
>
> I have begun looking at this issue. Hopefully I'll be able to provide
> an update soon.
On Wed, Mar 27, 2019 at 11:40:12AM +0900, Amit Langote wrote:
> I'm thinking of adding this to open items under Older Bugs. Attached the
> patch that I had posted on -bugs, but it's only a rough sketch as
> described above, not a full fix.
Adding it to the section for older bugs sounds fine to
On 2019/03/08 19:22, Amit Langote wrote:
> On 2019/03/07 20:36, Amit Langote wrote:
>> On Thu, Mar 7, 2019 at 11:17 AM Amit Langote
>> wrote:
>>> The problem start when ALTER TABLE users ALTER COLUMN is executed.
>>> create table users(user_id int, name varchar(64), unique (user_id, name))
>>>
15 matches
Mail list logo
