On Wed, Nov 7, 2018 at 2:33 PM Tomas Vondra
wrote:
> FWIW, it was mentioned that "your only concurring vote came from someone
> with whom you share an employer" which kind suggests opinions/votes from
> people working for the same company are somehow less honest/valuable. I
> find that annoying
On 11/7/18 7:41 PM, Robert Haas wrote:
> On Wed, Nov 7, 2018 at 1:22 PM Alvaro Herrera
> wrote:
>>> But maybe you've adopted that policy already. You back-patched a
>>> behavior change 2 days before a minor release when the vote was 2-3
>>> against the change.
>>
>> It was? This is my
On Wed, Nov 7, 2018 at 1:22 PM Alvaro Herrera wrote:
> > But maybe you've adopted that policy already. You back-patched a
> > behavior change 2 days before a minor release when the vote was 2-3
> > against the change.
>
> It was? This is my count:
> For: Alvaro, Andrew, Tom
> Against: Michael,
On 2018-Nov-07, Robert Haas wrote:
> On Wed, Nov 7, 2018 at 10:46 AM Alvaro Herrera
> wrote:
> > I think 11.0 is ready for testing that a migration from a production
> > running 10.x, but not for just blindly migrating. If you wanted to take
> > such a leap of faith, surely you'd wait for 11.1
On 2018-11-07 11:19:53 -0500, Robert Haas wrote:
> On Wed, Nov 7, 2018 at 10:46 AM Alvaro Herrera
> wrote:
> > I think 11.0 is ready for testing that a migration from a production
> > running 10.x, but not for just blindly migrating. If you wanted to take
> > such a leap of faith, surely you'd
On Wed, Nov 7, 2018 at 10:46 AM Alvaro Herrera wrote:
> I think 11.0 is ready for testing that a migration from a production
> running 10.x, but not for just blindly migrating. If you wanted to take
> such a leap of faith, surely you'd wait for 11.1 at the very least.
I think that's an
On 2018-Nov-04, Michael Paquier wrote:
> On Sat, Nov 03, 2018 at 12:30:15PM -0700, Andres Freund wrote:
> > On 2018-11-03 16:24:28 -0300, Alvaro Herrera wrote:
> >> On 2018-Nov-03, Robert Haas wrote:
> >>> Well, you've guaranteed that already. Now 11 will be different from
> >>> 11.1, and tables
On Sat, Nov 03, 2018 at 12:30:15PM -0700, Andres Freund wrote:
> On 2018-11-03 16:24:28 -0300, Alvaro Herrera wrote:
>> On 2018-Nov-03, Robert Haas wrote:
>>> Well, you've guaranteed that already. Now 11 will be different from
>>> 11.1, and tables will be different from indexes until somebody
On 2018-Nov-03, Tom Lane wrote:
> Hmm ... in the April thread, one of the main concerns that prevented hasty
> action was fear of breaking dump/restore behavior. Have you checked that
> with this change, a dump/restore will restore the same state (same
> actual tablespace assignments) that
Alvaro Herrera writes:
> On 2018-Nov-03, Andrew Dunstan wrote:
>> +1. This is unquestionably a POLA violation that should be fixed, IMNSHO.
> Yeah, that's my view on it too.
> Pushed.
Hmm ... in the April thread, one of the main concerns that prevented hasty
action was fear of breaking
On 2018-11-03 16:24:28 -0300, Alvaro Herrera wrote:
> On 2018-Nov-03, Robert Haas wrote:
> > Well, you've guaranteed that already. Now 11 will be different from
> > 11.1, and tables will be different from indexes until somebody goes
> > and makes that consistent again.
>
> Nobody is running 11.0
On 2018-Nov-03, Robert Haas wrote:
> Well, you've guaranteed that already. Now 11 will be different from
> 11.1, and tables will be different from indexes until somebody goes
> and makes that consistent again.
Nobody is running 11.0 in production. The people using 11.0 are just
testing, and
On Fri, Nov 2, 2018 at 7:12 PM Alvaro Herrera wrote:
> With all due respect, this argument makes no sense. All partitioned
> indexes that exist today have a null reltablespace (all pg_class rows
> already have a reltablespace column; I'm not changing that). If users
I hope not, because that
On 2018-Nov-03, Andrew Dunstan wrote:
> +1. This is unquestionably a POLA violation that should be fixed, IMNSHO.
Yeah, that's my view on it too.
Pushed.
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 11/02/2018 07:12 PM, Alvaro Herrera wrote:
On 2018-Nov-03, Michael Paquier wrote:
On Fri, Nov 02, 2018 at 03:53:51PM -0300, Alvaro Herrera wrote:
In this thread I'm not proposing to change the behavior for tables, only
for indexes. If people want to change behavior for tables (and I
On 2018-Nov-03, Michael Paquier wrote:
> On Fri, Nov 02, 2018 at 03:53:51PM -0300, Alvaro Herrera wrote:
> > In this thread I'm not proposing to change the behavior for tables, only
> > for indexes. If people want to change behavior for tables (and I agree
> > with doing so), they can start
On Fri, Nov 02, 2018 at 03:53:51PM -0300, Alvaro Herrera wrote:
> In this thread I'm not proposing to change the behavior for tables, only
> for indexes. If people want to change behavior for tables (and I agree
> with doing so), they can start their own threads.
Changing this behavior on
On 2018-Nov-02, Robert Haas wrote:
> On Fri, Nov 2, 2018 at 12:05 PM Alvaro Herrera
> wrote:
> > On 2018-Nov-02, Robert Haas wrote:
> > > I strongly object to inserting behavior changes into released branches
> > > on the grounds that the behavior wasn't considered carefully enough
> > > before
On Fri, Nov 2, 2018 at 12:05 PM Alvaro Herrera wrote:
> On 2018-Nov-02, Robert Haas wrote:
> > I strongly object to inserting behavior changes into released branches
> > on the grounds that the behavior wasn't considered carefully enough
> > before feature freeze.
>
> I'm not proposing to change
On 2018-Nov-02, Robert Haas wrote:
> On Fri, Nov 2, 2018 at 11:02 AM Alvaro Herrera
> wrote:
> > > By the way, if we decide to do something about this, I think we do the
> > > same for partitioned tables.
> >
> > I'm up for changing the behavior of partitioned tables in pg12 (please
> > send a
On 2018-Nov-02, Robert Haas wrote:
> I strongly object to inserting behavior changes into released branches
> on the grounds that the behavior wasn't considered carefully enough
> before feature freeze.
I'm not proposing to change any stable behavior. The thing I'm
proposing to change clearly
On Fri, Nov 2, 2018 at 11:02 AM Alvaro Herrera wrote:
> > By the way, if we decide to do something about this, I think we do the
> > same for partitioned tables.
>
> I'm up for changing the behavior of partitioned tables in pg12 (please
> send a patch), but I'm up for changing the behavior of
On 2018-Nov-02, Amit Langote wrote:
> On 2018/11/02 10:27, Michael Paquier wrote:
> > It seems to me that the current behavior is wanted in this case, because
> > partitioned tables and partitioned indexes have no physical storage.
>
> Keith Fiske complained about this behavior for partitioned
On 2018-Nov-02, Michael Paquier wrote:
> On Thu, Nov 01, 2018 at 09:31:38PM -0300, Alvaro Herrera wrote:
> > 1. When a CREATE INDEX specifies a tablespace, existing partitions get
> > the index in the correct tablespace; however, the parent index itself
> > does not record the tablespace. So
Hi,
On 2018/11/02 10:27, Michael Paquier wrote:
> On Thu, Nov 01, 2018 at 09:31:38PM -0300, Alvaro Herrera wrote:
>> A customer reported to us that partitioned indexes are not working
>> consistently with tablespaces:
>
> Let's see...
>
>> 1. When a CREATE INDEX specifies a tablespace, existing
On Thu, Nov 01, 2018 at 09:31:38PM -0300, Alvaro Herrera wrote:
> A customer reported to us that partitioned indexes are not working
> consistently with tablespaces:
Let's see...
> 1. When a CREATE INDEX specifies a tablespace, existing partitions get
> the index in the correct tablespace;
Hello
A customer reported to us that partitioned indexes are not working
consistently with tablespaces:
1. When a CREATE INDEX specifies a tablespace, existing partitions get
the index in the correct tablespace; however, the parent index itself
does not record the tablespace. So when new
27 matches
Mail list logo
