On Mon, Aug 9, 2021 at 9:50 PM Mark Dilger wrote:
>
> > On Aug 6, 2021, at 1:32 AM, vignesh C wrote:
> >
> > the attached v19 patch
>
> With v19 applied, a schema owner can publish the contents of a table
> regardless of ownership or permissions on that table:
>
...
...
>
> It is a bit
On Fri, Jul 30, 2021 at 10:21 AM Amit Kapila wrote:
>
> This problem seems to be from the time Logical
> Replication has been introduced, so adding others (who are generally
> involved in this area) to see what they think about this bug? I think
> people might not be using toasted columns for
On Wednesday, August 4, 2021 8:46 PM Masahiko Sawada
wrote:
> I'll incorporate those comments in the next version patch.
Hi, when are you going to make and share the updated v6 ?
Best Regards,
Takamichi Osumi
On Tue, Aug 10, 2021 at 12:24:13PM +0900, Michael Paquier wrote:
> So, on a closer look, it happens that this breaks the regression tests
> of sepgsql, as the two following commands in ddl.sql cause a rewrite:
> ALTER TABLE regtest_table_4 ALTER COLUMN y TYPE float;
> ALTER TABLE regtest_ptable_4
Hi,
On 2021-08-09 22:57:18 +, Bossart, Nathan wrote:
> @@ -1026,6 +1031,18 @@ PostmasterMain(int argc, char *argv[])
>*/
> InitializeMaxBackends();
>
> + if (output_shmem)
> + {
> + char output[64];
> + Size size;
> +
> + size =
Hi,
On 2021-08-09 18:58:53 -0500, Justin Pryzby wrote:
> Define shared_buffers as the exact size to be allocated/requested from the OS
> (regardless of whether they're huge pages or not), and have postgres compute
> everything else based on that. So shared_buffers=2GB would end up being
>
On Mon, Aug 9, 2021 at 3:37 PM Drouvot, Bertrand wrote:
>
> > BTW, I see this as an Open Item for PG-14 [1] which seems wrong to me
> > as this is a bug from previous versions. I am not sure who added it
>
> Me neither.
>
> > but do you see any reason for this to consider as an open item for
> >
On Tue, Aug 10, 2021 at 6:31 AM Masahiko Sawada wrote:
>
> On Mon, Aug 9, 2021 at 1:01 PM Peter Smith wrote:
> >
> > On Mon, Aug 9, 2021 at 12:46 PM Amit Kapila wrote:
>
> But "REFRESH PUBLICATION refresh_option" seems wrong in terms of SQL
> syntax, not?
>
> Given there could be multiple
On Sat, Aug 07, 2021 at 07:18:19PM +0900, Michael Paquier wrote:
> As a matter of curiosity, I have checked how it would look to handle
> the no-op case for the sub-commands other than SET TABLESPACE, and one
> would need something like the attached, with a new flag for
> AlteredTableInfo. That
On Tue, Aug 10, 2021 at 8:05 AM Masahiko Sawada wrote:
>
> On Sat, Aug 7, 2021 at 2:36 PM Amit Kapila wrote:
> >
> > On Fri, Aug 6, 2021 at 9:57 PM Japin Li wrote:
> > >
> > > >
> > > > Hmm yes, it cannot cover all cases. I had somehow misunderstood that
> > > > the subscriber knows which
Hi,
On 2021-08-09 16:02:33 -0400, Alvaro Herrera wrote:
> On 2021-Jul-27, Andres Freund wrote:
>
> > Isn't this going to create a *lot* of redundant sampling? Especially if you
> > have any sort of nested partition tree. In the most absurd case a partition
> > with n parents will get sampled n
On Sat, Aug 7, 2021 at 2:36 PM Amit Kapila wrote:
>
> On Fri, Aug 6, 2021 at 9:57 PM Japin Li wrote:
> >
> > >
> > > Hmm yes, it cannot cover all cases. I had somehow misunderstood that
> > > the subscriber knows which relations are associated with which
> > > publications. Given that the
Mark Dilger writes:
> I ran a lot of tests with the patch, and the asserts have all cleared up, but
> I don't know how to think about the user facing differences. If we had a
> good reason for raising an error for these back-references, maybe that'd be
> fine, but it seems to just be an
On Tue, Aug 10, 2021 at 11:01 AM Masahiko Sawada wrote:
>
> On Mon, Aug 9, 2021 at 1:01 PM Peter Smith wrote:
> >
> > On Mon, Aug 9, 2021 at 12:46 PM Amit Kapila wrote:
> > >
> > > On Sun, Aug 8, 2021 at 10:21 AM Peter Smith wrote:
> > > >
> > > > On Sat, Aug 7, 2021 at 4:33 PM Amit Kapila
>
> On Aug 9, 2021, at 4:31 PM, Tom Lane wrote:
>
> This patch should work OK in HEAD and v14, but it will need
> a bit of fooling-about for older branches I think, given that
> they fill v->subs[] a little differently.
Note that I tested your patch *before* master, so the changes look
> On Aug 9, 2021, at 6:17 PM, Mark Dilger wrote:
>
> Well, this doesn't die either:
Meaning it doesn't die in the part of the pattern qualified by {0} either. It
does die in the other part. Sorry again for the confusion.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The
On Mon, Aug 09, 2021 at 01:08:42PM -0400, Robert Haas wrote:
> To reproduce, initialize a cluster with wal_level=minimal and
> max_wal_senders=0. Then from psql:
>
> \! mkdir /tmp/goose
>
> CHECKPOINT;
> CREATE TABLESPACE goose LOCATION '/tmp/goose';
> SET wal_skip_threshold=0;
> BEGIN;
> CREATE
> On Aug 9, 2021, at 6:11 PM, Tom Lane wrote:
>
> Hm. I'm not sure that this example proves anything about Perl's handling
> of the situation, since you didn't use a backref.
Well, this doesn't die either:
if ('foo' =~ m/((??{ die; })(.)(??{ die $1; })){0}((??{ die "got here"; })|\2)/)
{
Mark Dilger writes:
>> On Aug 9, 2021, at 4:31 PM, Tom Lane wrote:
>> There is a potentially interesting definitional question:
>> what exactly ought this regexp do?
>> ((.)){0}\2
>> Because the capturing paren sets are zero-quantified, they will
>> never be matched to any characters, so
On Mon, Aug 9, 2021 at 1:01 PM Peter Smith wrote:
>
> On Mon, Aug 9, 2021 at 12:46 PM Amit Kapila wrote:
> >
> > On Sun, Aug 8, 2021 at 10:21 AM Peter Smith wrote:
> > >
> > > On Sat, Aug 7, 2021 at 4:33 PM Amit Kapila
> > > wrote:
> > > >
> > > > On Thu, Jul 8, 2021 at 6:31 PM Masahiko
Mark Dilger writes:
>> On Aug 9, 2021, at 12:14 PM, Tom Lane wrote:
>> Pushed, but while re-reading it before commit I noticed that there's
>> some more fairly low-hanging fruit in regexp_replace().
> I've been reviewing and testing this (let-regexp_replace-use-NOSUB.patch)
> since you sent it
> On Aug 9, 2021, at 5:14 PM, Mark Dilger wrote:
>
>our $match;
>if ('foo' =~ m/((.)(??{ die; })){0}(..)/)
I left in a stray variable. A prior version of this script was assigning to
$match where it now has die. Sorry for any confusion.
—
Mark Dilger
EnterpriseDB:
> On Aug 9, 2021, at 4:31 PM, Tom Lane wrote:
>
> There is a potentially interesting definitional question:
> what exactly ought this regexp do?
>
> ((.)){0}\2
>
> Because the capturing paren sets are zero-quantified, they will
> never be matched to any characters, so the
Hello,
On 2021-Jul-22, Andres Freund wrote:
> 1) Somehow it seems like a violation to do stuff like
>get_partition_ancestors() in pgstat.c. It's nothing I can't live with, but
>it feels a bit off. Would likely not be too hard to address, e.g. by just
>putting some of
On Thu, Jun 10, 2021 at 07:23:33PM -0500, Justin Pryzby wrote:
> On Wed, Jun 09, 2021 at 10:55:08PM -0500, Don Seiler wrote:
> > On Wed, Jun 9, 2021, 21:03 P C wrote:
> >
> > > I agree, its confusing for many and that confusion arises from the fact
> > > that you usually talk of shared_buffers
On 8/9/21, 4:05 PM, "Zhihong Yu" wrote:
> -extern void CreateSharedMemoryAndSemaphores(void);
> +extern Size CreateSharedMemoryAndSemaphores(bool size_only);
>
> Should the parameter be enum / bitmask so that future addition would not
> change the method signature ?
I don't have a strong
> On Aug 9, 2021, at 12:14 PM, Tom Lane wrote:
>
> Pushed, but while re-reading it before commit I noticed that there's
> some more fairly low-hanging fruit in regexp_replace(). As I had it
> in that patch, it never used REG_NOSUB because of the possibility
> that the replacement string uses
Mark Dilger writes:
> +select regexp_split_to_array('', '(?:((?:q+))){0}(\1){0,0}?*[^]');
> +server closed the connection unexpectedly
Here's a quick draft patch for this. Basically it moves the
responsibility for clearing v->subs[] pointers into the freesubre()
recursion, so that it will
On Mon, Aug 9, 2021 at 3:51 PM Bruce Momjian wrote:
> > I think that there was a snowballing effect here. We both made
> > mistakes that compounded. I apologize for my role in this whole mess.
>
> I do think all committers need to understand the role of the RMT so they
> can respond
On Mon, Aug 9, 2021 at 3:57 PM Bossart, Nathan wrote:
> On 6/9/21, 8:09 PM, "Bossart, Nathan" wrote:
> > On 6/9/21, 3:51 PM, "Mark Dilger" wrote:
> >>> On Jun 9, 2021, at 1:52 PM, Bossart, Nathan
> wrote:
> >>>
> >>> I'd be happy to clean it up and submit it for
> >>> discussion in
On Mon, Aug 9, 2021 at 03:42:45PM -0700, Peter Geoghegan wrote:
> > I'd like to apologize for not answering your email the way I should
> > have. Honestly it never occurred to me. Maybe that's because I'm used
> > to other procedures, or because I never had to converse with the RMT,
> > or maybe,
Michael,
On Mon, Aug 9, 2021 at 3:03 PM Michael Meskes wrote:
> This explains why it felt so difficult to make myself clear. I was
> feeling exactly the same, just the other way round.
My own special brand of miscommunication was also involved. I happen
to be sensitive to the perception that I
On 8/9/21 6:15 PM, Bruce Momjian wrote:
> On Tue, Aug 10, 2021 at 12:03:24AM +0200, Michael Meskes wrote:
>> I'd like to apologize for not answering your email the way I should
>> have. Honestly it never occurred to me. Maybe that's because I'm used
>> to other procedures, or because I never had
I wrote:
> Hmmm ... yeah, I see it too. This points up something I'd wondered
> about before, which is whether the code that "cancels everything"
> after detecting {0} is really OK. It throws away the outer subre
> *and children* without worrying about what might be inside, and
> here we see
> > Again agreed, please keep in mind, though, that I didn't notice I
> > was
> > being chased until Peter's first email.
>
> I was asked by the RMT to contact one of your employees, and I did,
> to
> tell you that the RMT was looking for feedback from you on an ecpg
> issue. Not sure if that
On Tue, Aug 10, 2021 at 12:03:24AM +0200, Michael Meskes wrote:
> I'd like to apologize for not answering your email the way I should
> have. Honestly it never occurred to me. Maybe that's because I'm used
> to other procedures, or because I never had to converse with the RMT,
> or maybe, quite
On Mon, Aug 9, 2021 at 06:00:00PM -0400, Bruce Momjian wrote:
> > Again agreed, please keep in mind, though, that I didn't notice I was
> > being chased until Peter's first email.
>
> I was asked by the RMT to contact one of your employees, and I did, to
> tell you that the RMT was looking for
Peter,
> I think that this must be a cultural thing. I can see how somebody
> would see the third person style as overly formal or stilted. An
> interpretation like that does make sense to me. But I knew of no
> reason why you might find that style made the message offensive. It
> was never
On Mon, Aug 9, 2021 at 11:48:07PM +0200, Michael Meskes wrote:
> No, of course not. And sorry for not being precise enough, I only
> objected to the prediction part, but I agree, I take the objection
> back. I guess it's as difficult for Peter to understand why this is
> offensive as it is for me
> > > I don't want to upset anybody for any reason. I regret that my
> > > words
> > > have upset you, but I think that they were misinterpreted in a
> > > way
> > > that I couldn't possibly have predicted. The particular aspect of
> >
> > I strongly object to that. It's pretty obvious to me that
Hello, Andres.
Thanks for the feedback again.
> The problem is that we don't want to add a lot of work
> KnownAssignedXidsAdd/Remove, because very often nobody will build a snapshot
> for that moment and building a sorted, gap-free, linear array of xids isn't
> cheap. In my experience it's more
On Wed, Jul 28, 2021 at 1:37 PM Melanie Plageman
wrote:
>
> On Tue, Feb 23, 2021 at 5:04 AM Andres Freund wrote:
> >
> > ## AIO API overview
> >
> > The main steps to use AIO (without higher level helpers) are:
> >
> > 1) acquire an "unused" AIO: pgaio_io_get()
> >
> > 2) start some IO, this is
Mark Dilger writes:
> I can still trigger the old bug for which we thought we'd pushed a fix. The
> test case below crashes on master (e12694523e7e4482a052236f12d3d8b58be9a22c),
> and also on the fixed version "Make regexp engine's backref-related
> compilation state more bulletproof."
>
On Mon, Aug 9, 2021 at 1:38 PM Michael Meskes wrote:
> > I don't want to upset anybody for any reason. I regret that my words
> > have upset you, but I think that they were misinterpreted in a way
> > that I couldn't possibly have predicted. The particular aspect of
>
> I strongly object to that.
On Mon, Aug 9, 2021 at 10:38:07PM +0200, Michael Meskes wrote:
> > Clearly we disagree about this. I don't think that there is anything
> > to be gained from discussing this any further, though. I suggest that
> > we leave it at that.
>
> Agreed.
>
> > I don't want to upset anybody for any
Tom,
I can still trigger the old bug for which we thought we'd pushed a fix. The
test case below crashes on master (e12694523e7e4482a052236f12d3d8b58be9a22c),
and also on the fixed version "Make regexp engine's backref-related compilation
state more bulletproof."
On Mon, Aug 9, 2021 at 1:38 PM Michael Meskes wrote:
> > I don't want to upset anybody for any reason. I regret that my words
> > have upset you, but I think that they were misinterpreted in a way
> > that I couldn't possibly have predicted. The particular aspect of
>
> I strongly object to
Hi,
> FWIW, I don't think that the phrasing of Peter's email is
> disrespectful. As I read it, it simply states that the RMT has made a
As I said before, it might be a cultural difference. What I don't
understand is, that a simple "Hi Michael, this is what the RMT
decided:" would have been
> question with a question mark. Despite the fact that it is generally
> understood that "committers own their own items", and that the RMT
> exists as a final check on that.
This does not contradict my opinion, but anyway.
> Clearly we disagree about this. I don't think that there is anything
On Sat, Aug 7, 2021 at 4:13 AM Michael Meskes wrote:
> I get it that the goal is to release PostgreSQL 14 and I also get it
> that nobody is interested in the reasons for my slow reaction. I even,
> at least to an extend, understand why nobody tried reaching out to me
> directly. However, what I
On Sat, Aug 7, 2021 at 2:01 PM Bossart, Nathan wrote:
> Here is a rebased version of the patch.
>
Giving this a review.
Patch applies cleanly and `make check` works as of
e12694523e7e4482a052236f12d3d8b58be9a22c
Overall looks very nice and tucks MaxBackends safely away.
I have a few
Hi
On 2021-Jul-27, Andres Freund wrote:
> Isn't this going to create a *lot* of redundant sampling? Especially if you
> have any sort of nested partition tree. In the most absurd case a partition
> with n parents will get sampled n times, solely due to changes to itself.
It seems to me that
On Mon, Aug 9, 2021 at 11:20 AM Nitin Jadhav
wrote:
> Modified the reset_startup_progress_timeout() to take the second
> parameter which indicates whether it is called for initialization or
> for resetting. Without this parameter there is a problem if we call
> init_startup_progress() more than
On Mon, Aug 9, 2021 at 11:45 AM Michael Meskes wrote:
> If you want me to answer, how about asking a question? Or telling me
> that you'd like some feedback? I don't see how I should know that you
> expect a reply to a simple statement of facts.
I expressed concern in fairly strong terms, and
> On Jul 20, 2021, at 11:28 AM, Tomas Vondra
> wrote:
>
> Tomas Vondra
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
> <0001-Handling-Expr-op-Expr-clauses-in-extended-stats-20210720.patch>
Hi Tomas,
I tested this patch against master looking for types of
Mark Dilger writes:
> The patch looks ready to commit. I don't expect to test it any further
> unless you have something in particular you'd like me to focus on.
Pushed, but while re-reading it before commit I noticed that there's
some more fairly low-hanging fruit in regexp_replace(). As I
On Thu, Jul 29, 2021 at 11:49 AM Robert Haas wrote:
> On Wed, Jul 28, 2021 at 3:28 PM Andres Freund wrote:
> > > Imagine if instead of
> > > all the hairy logic we have now we just replaced this whole if
> > > (IsInRecovery) stanza with this:
> > >
> > > if (InRecovery)
> > >
> My email of July 30 was itself pretty strongly worded, but went
> unanswered for a full week. Not even a token response. If that
> doesn't
> count as "ignoring the RMT", then what does? How much time has to
> pass
> before radio silence begins to count as "ignoring the RMT", in your
> view of
On Mon, Aug 9, 2021 at 12:10 AM Michael Meskes wrote:
> How do you know I didn't spend 15 minutes looking at the patch and the
> whole email thread? I surely did and it was more than 15 minutes, but
> not enough to give a meaningful comment. If you can do it in 15
> minutes, great for you, I
Dear Kuroda-san,
> I perfectly missed mails and 8/9 was a national holiday.
> I must apologize about anything. Very sorry for inconvenience.
No need to, non of it is your fault.
> I summarize the thread.
Thank you so much, this is very, very helpful.
> As you might know DECLARE STATEMENT
Hi,
On 2021-08-09 13:54:25 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2021-08-09 13:43:03 -0400, Robert Haas wrote:
> >> On Mon, Aug 9, 2021 at 1:30 PM Alvaro Herrera
> >> wrote:
> > How common is to get a failure? I know I've run tests under
> > EXEC_BACKEND and not seen any
Hi Suraj,
Suraj Khamkar writes:
> Hello Dagfinn,
>
> I had a look at your patch and below are my review comments.
> Please correct me if I am missing something.
>
>1. For me the patch does not apply cleanly. I have been facing the error
>of trailing whitespaces.
I do not get these
Andres Freund writes:
> On 2021-08-09 13:43:03 -0400, Robert Haas wrote:
>> On Mon, Aug 9, 2021 at 1:30 PM Alvaro Herrera
>> wrote:
> How common is to get a failure? I know I've run tests under
> EXEC_BACKEND and not seen any failures. Not many runs though.
> I get check-world failures in
Hi,
On 2021-08-09 13:43:03 -0400, Robert Haas wrote:
> On Mon, Aug 9, 2021 at 1:30 PM Alvaro Herrera wrote:
> > How common is to get a failure? I know I've run tests under
> > EXEC_BACKEND and not seen any failures. Not many runs though.
I get check-world failures in about 1/2-1/3 of the
On Mon, Aug 9, 2021 at 1:30 PM Alvaro Herrera wrote:
> How common is to get a failure? I know I've run tests under
> EXEC_BACKEND and not seen any failures. Not many runs though.
On macOS, failures are extremely common. Sometimes I have to run
simple tests many times to get even one success.
On 2021-Aug-06, Andrew Dunstan wrote:
> On 8/5/21 11:29 PM, Andres Freund wrote:
> > I was wondering if we should have postmaster do
> > personality(ADDR_NO_RANDOMIZE)
> > for EXEC_BACKEND builds? It seems nicer to make it automatically work than
> > have people remember that they need to call
To reproduce, initialize a cluster with wal_level=minimal and
max_wal_senders=0. Then from psql:
\! mkdir /tmp/goose
CHECKPOINT;
CREATE TABLESPACE goose LOCATION '/tmp/goose';
SET wal_skip_threshold=0;
BEGIN;
CREATE TABLE wild (a int, b text) TABLESPACE goose;
INSERT INTO wild VALUES (1,
Dear Horiguchi-san,
> How Pro*C behaves in that case? If the second command ends with an
> error, I think we are free to error out the second command before
> execution. If it works... do you know what is happening at the time?
You asked that how Oracle works when the followings precompiled and
Dear Wang,
Good reporting!
> I'm not sure, but how about modify the ecpg.trailer:
> > statement: ecpgstart at toplevel_stmt ';' { connection = NULL; }
> > | ecpgstart toplevel_stmt ';'
> I think there are lots of 'connection = NULL;' in source, and we should find a
good location to reset the
Dear Hackers,
I perfectly missed mails and 8/9 was a national holiday.
I must apologize about anything. Very sorry for inconvenience.
> The RMT's first responsibility is to ensure that PostgreSQL 14 is
> released on schedule. We would prefer to avoid a revert, but we cannot
> allow this to drag
> On Aug 6, 2021, at 1:32 AM, vignesh C wrote:
>
> the attached v19 patch
With v19 applied, a schema owner can publish the contents of a table regardless
of ownership or permissions on that table:
+CREATE ROLE user1;
+GRANT CREATE ON DATABASE regression TO user1;
+CREATE ROLE user2;
+GRANT
> On 6 Aug 2021, at 12:16, Itamar Gafni wrote:
> Previous to OpenSSL version 1.1.0, the BIO methods object would be copied
> directly from the existing socket type and then its read\write functions
> would be replaced.
> With 1.1.0 and up, the object is created from scratch and then all its
>
Modified the reset_startup_progress_timeout() to take the second
parameter which indicates whether it is called for initialization or
for resetting. Without this parameter there is a problem if we call
init_startup_progress() more than one time if there is no call to
ereport_startup_progress() in
On Thu, Aug 5, 2021 at 8:02 PM Tom Lane wrote:
> I think doing nothing is fine. Given the lack of complaints, we're
> more likely to break something than fix anything useful.
+1.
--
Robert Haas
EDB: http://www.enterprisedb.com
On Wed, Aug 4, 2021 at 10:03 PM Greg Nancarrow wrote:
> In setting up the snapshot for the execution state used in command
> execution, GetTransactionSnapshot() is called and (possibly a copy of)
> the returned snapshot is pushed as the ActiveSnapshot.
I mean, there are LOTS of
Our minor releases coming out this week will create a script when
pg_upgrade finishes that contains ALTER EXTENSION ... UPDATE commands
for extension that show updates in pg_available_extensions. However, I
am unclear if all extensions that have updates are reported in
pg_available_extensions or
On Tue, Aug 3, 2021 at 4:25 PM Amit Kapila wrote:
>
> On Tue, Jul 27, 2021 at 9:56 AM Dilip Kumar wrote:
>
> > Yeah, that's a big problem, seems like the expression evaluation
> > machinery directly going and detoasting the externally stored data
> > using some random snapshot. Ideally, in
On 8/9/21 1:33 AM, David Rowley wrote:
> On Mon, 9 Aug 2021 at 17:14, A Z wrote:
>>
>> 2) How may I get PostgreSQL to output the create table statement(s) for one
>> or more tables inside one database, without issuing instructions via the
>> command line, but only inside a database login, as
On Mon, Aug 9, 2021 at 3:37 PM Drouvot, Bertrand wrote:
>
> Hi Amit,
>
> On 8/9/21 10:37 AM, Amit Kapila wrote:
> > On Fri, Jul 9, 2021 at 12:22 PM Drouvot, Bertrand
> > wrote:
> >> Please find enclosed a patch proposal to:
> >>
> >> * Avoid the failed assertion on current master and generate
On Mon, Aug 9, 2021 at 3:59 PM Amit Kapila wrote:
>
> On Mon, Aug 9, 2021 at 1:36 AM Rahila Syed wrote:
> >
> >> Having said that, I'm not sure I agree with this design decision; what I
> >> think this is doing is hiding from the user the fact that they are
> >> publishing columns that they
On Monday, August 9, 2021 11:10 AM Amit Kapila wrote:
>
> On Sat, Aug 7, 2021 at 6:53 PM houzj.f...@fujitsu.com
> wrote:
> >
> > On Sat, Aug 7, 2021 1:36 PM Amit Kapila wrote:
> > > On Fri, Aug 6, 2021 at 9:57 PM Japin Li wrote:
> > >
> > > Do you mean to say that do it for both Add and Drop
On Mon, Aug 9, 2021 at 1:36 AM Rahila Syed wrote:
>
>> Having said that, I'm not sure I agree with this design decision; what I
>> think this is doing is hiding from the user the fact that they are
>> publishing columns that they don't want to publish. I think as a user I
>> would rather get an
On Mon, Aug 9, 2021 at 2:07 PM Amit Kapila wrote:
>
> On Fri, Jul 9, 2021 at 12:22 PM Drouvot, Bertrand wrote:
> >
> > Please find enclosed a patch proposal to:
> >
> > * Avoid the failed assertion on current master and generate the error
> > message instead (should the code reach that stage).
Hello Dagfinn,
I had a look at your patch and below are my review comments.
Please correct me if I am missing something.
1. For me the patch does not apply cleanly. I have been facing the error
of trailing whitespaces.
surajkhamkar@localhost:postgres$ git apply
On Fri, Jul 9, 2021 at 12:22 PM Drouvot, Bertrand wrote:
>
> Please find enclosed a patch proposal to:
>
> * Avoid the failed assertion on current master and generate the error message
> instead (should the code reach that stage).
> * Reset the toast_hash in case of relation rewrite with toast
On Fri, 30 Jul 2021 at 15:05, David Rowley wrote:
> Does anyone have any thoughts on where we should draw the line on
> parsing Makefiles? I'm a little worried that I'm adding pasing just
> for exactly how the Makefiles are today and that it could easily be
> broken if something is adjusted
> I think that it's crystal clear what I meant in the email of July 30.
> I meant: it's not okay that you're simply ignoring the RMT. You
> hadn't
> even made a token effort at that point. For example you didn't give
> the proposed fix a cursory 15 minute review, just so we had some very
> rough
On Sat, Aug 7, 2021 at 12:01 AM Ajin Cherian wrote:
>
> On Mon, Aug 2, 2021 at 7:20 PM Amit Kapila wrote:
> >
> > On Fri, Jul 23, 2021 at 3:39 PM Ajin Cherian wrote:
> > >
> >
> > Let's first split the patch for prepared and non-prepared cases as
> > that will help to focus on each of them
On Fri, Aug 6, 2021 at 2:00 PM Masahiko Sawada wrote:
>
> On Wed, Aug 4, 2021 at 12:08 AM vignesh C wrote:
> >
> > On Tue, Aug 3, 2021 at 12:00 PM tanghy.f...@fujitsu.com
> > wrote:
> > >
> > > On Monday, August 2, 2021 11:40 PM vignesh C wrote:
> > > >
> > > > Thanks for the comments, attached
89 matches
Mail list logo
