Hello
> Hearing no comments, I've pushed that patch, and marked the v12
> open item closed.
Thank you!
regards, Sergei
Alvaro Herrera from 2ndQuadrant writes:
> I've marked https://commitfest.postgresql.org/24/2076/ committed also.
Yeah, I just remembered about doing that, and saw you'd beat me to it.
regards, tom lane
On 2019-Sep-07, Tom Lane wrote:
> I wrote:
> > Or, of course, we could forget the whole thing and switch the output
> > level for these messages to NOTICE instead. I'm not for that, but
> > now that we see what it'll cost us to have them better hidden, we can
> > at least have an informed
I wrote:
> Or, of course, we could forget the whole thing and switch the output
> level for these messages to NOTICE instead. I'm not for that, but
> now that we see what it'll cost us to have them better hidden, we can
> at least have an informed debate.
> Thoughts?
Hearing no comments, I've
Sergei Kornilov writes:
> Thank you! It seems the most appropriate option for this test is to change
> @contrib_excludes
> Done in attached patch, will check appveyor reaction.
Appveyor seems happy, so I took a look through this. There's little
to say about 0001: if we're going to drop the
Hello
Thank you! It seems the most appropriate option for this test is to change
@contrib_excludes
Done in attached patch, will check appveyor reaction.
regards, Sergeidiff --git a/src/test/modules/Makefile b/src/test/modules/Makefile
index 60d6d7be1b..ab3fc91fae 100644
---
Sergei Kornilov writes:
> I noticed appveyor build on windows is not happy:
>> perl buildsetup.pl
>> Could not determine contrib module type for alter_table
>> at buildsetup.pl line 38.
> But I have no idea why. I can't check on windows. Possible I miss some change
> while adding new module to
Hello
I noticed appveyor build on windows is not happy:
> perl buildsetup.pl
> Could not determine contrib module type for alter_table
> at buildsetup.pl line 38.
But I have no idea why. I can't check on windows. Possible I miss some change
while adding new module to tree. Will check. Please
Hello
> Sergei, can we enlist you to submit a patch for this? Namely reduce the
> log level to DEBUG1 and add a TAP test in src/test/modules/alter_table/
> that verifies that the message is or isn't emitted, as appropriate.
I created this patch.
I test message existence. Also I check message
Hi
> Sergei, can we enlist you to submit a patch for this? Namely reduce the
> log level to DEBUG1 and add a TAP test in src/test/modules/alter_table/
> that verifies that the message is or isn't emitted, as appropriate.
Yes, will do. Probably in few days.
regards, Sergei
On 2019-Jul-23, David Rowley wrote:
> I don't know my way around the tap tests that well, but I started to
> look at this and ended up a bit stuck on where the test should be
> located. I see src/test/modules/brin has some brin related tests, so
> I thought that src/test/modules/alter_table
On 2019-Jul-23, David Rowley wrote:
> Also, if I'm not wrong, the votes so far appear to be:
>
> NOTICE: Robert, Amit
> DEBUG1: Tom, Alvaro (I'm entirely basing this on the fact that they
> mentioned possible ways to test with DEBUG1)
>
> I'll be happy with DEBUG1 if we can get tests to test
On Thu, 18 Jul 2019 at 07:01, Tom Lane wrote:
> Seems like maybe what we need is to transpose the tests at issue into
> a TAP test? That could grep for the messages we care about and disregard
> other ones.
That seems like a good idea. I guess that's a vote in favour of
having DEBUG1 for
Sergei Kornilov writes:
>> It's not awful. I tried inserting "set client_min_messages = debug1"
>> into alter_table.sql
> We already did this in March. And this change was reverted in
> 5655565c077c53b6e9b4b9bfcdf96439cf3af065 because this will not work on
> buildfarm animals with
Hi
> It's not awful. I tried inserting "set client_min_messages = debug1"
> into alter_table.sql
We already did this in March. And this change was reverted in
5655565c077c53b6e9b4b9bfcdf96439cf3af065 because this will not work on
buildfarm animals with log_statement = 'all'
regards, Sergei
Alvaro Herrera writes:
> On 2019-Jul-15, David Rowley wrote:
>> I think the only argument against it was around lack of ability to
>> test if the constraint was used to verify no row breaks the partition
>> bound during the ATTACH PARTITION.
> Would it work to set client_min_messages to DEBUG1
On 2019-Jul-15, David Rowley wrote:
> I think the only argument against it was around lack of ability to
> test if the constraint was used to verify no row breaks the partition
> bound during the ATTACH PARTITION.
Would it work to set client_min_messages to DEBUG1 for the duration of
the test,
On 2019-Jul-15, David Rowley wrote:
> I think the only argument against it was around lack of ability to
> test if the constraint was used to verify no row breaks the partition
> bound during the ATTACH PARTITION.
Would it work to set client_min_messages to DEBUG1 for the duration of
the test,
Hello
Here is two patches with NOTICE ereport: one for partitions operations and one
for "set not null" (for consistency)
regards, Sergeidiff --git a/src/backend/commands/tablecmds.c b/src/backend/commands/tablecmds.c
index 2a2c161695..4ec61d4833 100644
--- a/src/backend/commands/tablecmds.c
On Tue, Jul 16, 2019 at 10:15 AM David Rowley
wrote:
> On Tue, 16 Jul 2019 at 03:13, Robert Haas wrote:
> > I vote for changing it to NOTICE instead of DEBUG1.
>
> Well, there are certainly other DDL commands that spit out NOTICES.
>
> postgres=# create table z (a int);
> CREATE TABLE
>
David Rowley writes:
> Would anyone complain if we made them all INFO?
That would be remarkably horrid, because that makes them unsuppressable.
I'm generally for having these be less in-your-face, not more so.
regards, tom lane
On Tue, 16 Jul 2019 at 03:13, Robert Haas wrote:
> I vote for changing it to NOTICE instead of DEBUG1.
Well, there are certainly other DDL commands that spit out NOTICES.
postgres=# create table z (a int);
CREATE TABLE
postgres=# create table x (a int) inherits(z);
NOTICE: merging column "a"
On Sun, Jul 14, 2019 at 7:46 PM Thomas Munro wrote:
> ... and retreating to a safe distance.
Is that measure in, like, light-years?
I vote for changing it to NOTICE instead of DEBUG1.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On Mon, 15 Jul 2019 at 11:46, Thomas Munro wrote:
>
> On Tue, Jul 2, 2019 at 12:17 AM Sergei Kornilov wrote:
> > This change is discussed as open item for pg12. Seems we have nor
> > objections nor agreement. I attached updated version due merge conflict.
> >
> > > Per discussion started here:
On Tue, Jul 2, 2019 at 12:17 AM Sergei Kornilov wrote:
> This change is discussed as open item for pg12. Seems we have nor objections
> nor agreement. I attached updated version due merge conflict.
>
> > Per discussion started here:
> >
Hello
This change is discussed as open item for pg12. Seems we have nor objections
nor agreement. I attached updated version due merge conflict.
> Per discussion started here:
> https://www.postgresql.org/message-id/CA%2BTgmoZWSLUjVcc9KBSVvbn%3DU5QRgW1O-MgUX0y5CnLZOA2qyQ%40mail.gmail.com
On Fri, Mar 15, 2019 at 12:55:36PM +0300, Sergei Kornilov wrote:
> We have INFO ereport messages in alter table attach partition like this:
> > partition constraint for table \"%s\" is implied by existing constraints
>
> So now I am +1 to idea of change error level for this messages. I attach
>
Hello
Per discussion started here:
https://www.postgresql.org/message-id/CA%2BTgmoZWSLUjVcc9KBSVvbn%3DU5QRgW1O-MgUX0y5CnLZOA2qyQ%40mail.gmail.com
We have INFO ereport messages in alter table attach partition like this:
> partition constraint for table \"%s\" is implied by existing constraints
28 matches
Mail list logo
