On 10/19/21, 3:13 PM, "Alvaro Herrera" wrote:
> On 2021-Oct-19, Bossart, Nathan wrote:
>
>> I did consider this, but I figured it might be better to keep the lock
>> level consistent for a given object type no matter what the statement
>> type is. I don't have a strong opinion about this, though.
On 2021-Oct-19, Bossart, Nathan wrote:
> I did consider this, but I figured it might be better to keep the lock
> level consistent for a given object type no matter what the statement
> type is. I don't have a strong opinion about this, though.
Yeah, the problem is that if there is a concurrent
On 10/19/21, 1:36 PM, "Alvaro Herrera" wrote:
> I was about to push this when it occurred to me that it seems a bit
> pointless to release AEL in order to retry with the lighter lock; once
> we have AEL, let's just keep it and proceed. So how about the attached?
I did consider this, but I figure
I was about to push this when it occurred to me that it seems a bit
pointless to release AEL in order to retry with the lighter lock; once
we have AEL, let's just keep it and proceed. So how about the attached?
I'm now thinking that this is to back-patch all the way to 12.
--
Álvaro Herrera
On 10/18/21, 4:56 PM, "Alvaro Herrera" wrote:
> Now, what is the worst that can happen if we rename a table under SUE
> and somebody else is using the table concurrently? Is there any way to
> cause a backend crash or something like that? As far as I can see,
> because we grab a fresh catalog sn
On 2021-Oct-07, Bossart, Nathan wrote:
> Good idea. Patch attached.
Yeah, that sounds exactly what I was thinking.
Now, what is the worst that can happen if we rename a table under SUE
and somebody else is using the table concurrently? Is there any way to
cause a backend crash or something lik
On Wed, Oct 06, 2021 at 06:43:25PM -0400, Tom Lane wrote:
> ... as, no doubt, are a lot of applications that this will gratuitously
> break. We've long had a policy that ALTER TABLE will work on relations
> that aren't tables, so long as the requested operation is sensible.
Yeah, that was my firs
On 2021-Oct-06, Bossart, Nathan wrote:
> On 10/6/21, 3:44 PM, "Tom Lane" wrote:
> > The situation for "ALTER some-other-relation-kind" is a bit more
> > confused, because some cases throw errors and some don't; but I really
> > doubt that tightening things up here will earn you anything but
> >
On 10/6/21, 3:44 PM, "Tom Lane" wrote:
> "Bossart, Nathan" writes:
>> Here's a patch that ERRORs if the object type and statement type do
>> not match. Interestingly, some of the regression tests were relying
>> on this behavior.
>
> ... as, no doubt, are a lot of applications that this will gra
"Bossart, Nathan" writes:
> On 10/6/21, 1:52 PM, "Bruce Momjian" wrote:
>> I can confirm this bug in git head, and I think it should be fixed.
> Here's a patch that ERRORs if the object type and statement type do
> not match. Interestingly, some of the regression tests were relying
> on this be
I can confirm this bug in git head, and I think it should be fixed.
---
On Mon, Oct 4, 2021 at 10:23:23AM +, Onder Kalaci wrote:
> Hi hackers,
>
> I realized a subtle behavior with ALTER INDEX .. RENAME. It seems like
Hi hackers,
I realized a subtle behavior with ALTER INDEX .. RENAME. It seems like a bug to
me, please see the steps below.
Test 1: Rename table via RENAME .. INDEX
CREATE TABLE test_table (a int);
SELECT 'test_table'::regclass::oid;
oid
---
34470
(1 row)
-- rename table using ALTER INDEX
12 matches
Mail list logo
