On 2018-Aug-16, Michael Paquier wrote:
> On Mon, Aug 13, 2018 at 01:39:06PM -0400, Robert Haas wrote:
> > The original patches would, I think, have been pretty scary to
> > back-patch, since the infrastructure didn't exist in older branches
> > and we were churning a fairly large amount of code.
On Mon, Aug 13, 2018 at 01:39:06PM -0400, Robert Haas wrote:
> The original patches would, I think, have been pretty scary to
> back-patch, since the infrastructure didn't exist in older branches
> and we were churning a fairly large amount of code. Now that most
> places are fixed and things have
On Fri, Aug 10, 2018 at 5:05 PM, Alvaro Herrera
wrote:
> I was actually thinking in applying to all back-branches, not just pg11,
> considering it a fix for a pretty serious bug. But checking the
> history, it seems that Robert patched this is 9.2 as new development
> (2ad36c4e4, 1489e2f26, cbe24
On 2018-Aug-10, Michael Paquier wrote:
> On Fri, Aug 10, 2018 at 02:03:28PM -0400, Alvaro Herrera wrote:
> > On 2018-Aug-06, Michael Paquier wrote:
> >> Like cbe24a6, perhaps we would not want to back-patch it? Based on the
> >> past history (and the consensus being reached for the REINDEX case w
On Fri, Aug 10, 2018 at 02:03:28PM -0400, Alvaro Herrera wrote:
> On 2018-Aug-06, Michael Paquier wrote:
>> Like cbe24a6, perhaps we would not want to back-patch it? Based on the
>> past history (and the consensus being reached for the REINDEX case would
>> be to patch only HEAD), I would be actua
On 2018-Aug-06, Michael Paquier wrote:
> Attached is a patch I have been working on which refactors the code of
> TRUNCATE in such a way that we check for privileges before trying to
> acquire a lock, without any user-facing impact (I have reworked a couple
> of comments compared to the last versi
On Thu, Aug 09, 2018 at 05:55:54PM +, Bossart, Nathan wrote:
> On 8/9/18, 11:31 AM, "Michael Paquier" wrote:
>> Thanks, I have updated the patch as you suggested. Any more
>> improvements to it that you can foresee?
>
> Looks good to me.
Okay, pushed to HEAD. Now remains the cases for VACU
On 8/9/18, 11:31 AM, "Michael Paquier" wrote:
> Thanks, I have updated the patch as you suggested. Any more
> improvements to it that you can foresee?
Looks good to me.
Nathan
On Thu, Aug 09, 2018 at 03:27:04PM +, Bossart, Nathan wrote:
> Thanks! This patch builds cleanly, the new tests pass, and my manual
> testing hasn't uncovered any issues. Notably, I cannot reproduce the
> originally reported authentication issue by using TRUNCATE after this
> change. Beyond
On 8/9/18, 5:29 AM, "Michael Paquier" wrote:
>> -truncate_check_rel(Relation rel)
>> +truncate_check_rel(Oid relid, Form_pg_class reltuple)
>>
>> Could we use HeapTupleGetOid(reltuple) instead of passing the OID
>> separately?
>
> If that was a HeapTuple. And it seems to me that we had better ma
On Wed, Aug 08, 2018 at 03:38:57PM +, Bossart, Nathan wrote:
> Here are some comments for the latest version of the patch.
Thanks for the review, Nathan!
> -truncate_check_rel(Relation rel)
> +truncate_check_rel(Oid relid, Form_pg_class reltuple)
>
> Could we use HeapTupleGetOid(reltuple) in
Hi,
On 8/6/18, 11:59 AM, "Michael Paquier" wrote:
> Attached is a patch I have been working on which refactors the code of
> TRUNCATE in such a way that we check for privileges before trying to
> acquire a lock, without any user-facing impact (I have reworked a couple
> of comments compared to th
Hi all,
This is a second thread I am spawning for the previous thread "Canceling
authentication due to timeout aka Denial of Service Attack":
https://www.postgresql.org/message-id/152512087100.19803.12733865831237526317%40wrigleys.postgresql.org
And this time the discussion is about TRUNCATE, as
13 matches
Mail list logo
