Hi,
On 2022-12-02 09:51:39 -0800, Andres Freund wrote:
> On 2022-12-02 12:15:37 -0500, Tom Lane wrote:
> > I wrote:
> > > I guess that means that the table-to-view removal has to go in
> > > first. I should be able to take care of that tomorrow, or if
> > > you're in a hurry I don't mind if you c
Hi,
On 2022-12-02 12:15:37 -0500, Tom Lane wrote:
> I wrote:
> > I guess that means that the table-to-view removal has to go in
> > first. I should be able to take care of that tomorrow, or if
> > you're in a hurry I don't mind if you commit it for me.
>
> Done now, feel free to deal with the pg
I wrote:
> I guess that means that the table-to-view removal has to go in
> first. I should be able to take care of that tomorrow, or if
> you're in a hurry I don't mind if you commit it for me.
Done now, feel free to deal with the pgstat problem.
regards, tom lane
Hi,
On 2022-12-02 01:03:35 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On December 1, 2022 9:48:48 PM PST, Tom Lane wrote:
> >> I'd suggest putting in an assertion that the relkind isn't changing,
> >> instead.
>
> > Sounds like a plan. Will you do that when you remove the table-to-view
Andres Freund writes:
> On December 1, 2022 9:48:48 PM PST, Tom Lane wrote:
>> I'd suggest putting in an assertion that the relkind isn't changing,
>> instead.
> Sounds like a plan. Will you do that when you remove the table-to-view hack?
I'd suggest committing it concurrently with the v15 fix
Hi,
On December 1, 2022 9:48:48 PM PST, Tom Lane wrote:
>Andres Freund writes:
>> On 2022-12-02 00:08:20 -0500, Tom Lane wrote:
>>> Just the table-to-view hack. I'm not aware that there are any other
>>> cases, and it seems hard to credit that there ever will be any.
>
>> I can see some halfwa
Andres Freund writes:
> On 2022-12-02 00:08:20 -0500, Tom Lane wrote:
>> Just the table-to-view hack. I'm not aware that there are any other
>> cases, and it seems hard to credit that there ever will be any.
> I can see some halfway credible scenarios. E.g. converting a view to a
> matview, or a
Hi,
On 2022-12-02 00:08:20 -0500, Tom Lane wrote:
> Andres Freund writes:
> > Do we have any cases of relcache entries changing their relkind?
>
> Just the table-to-view hack. I'm not aware that there are any other
> cases, and it seems hard to credit that there ever will be any.
I can see some
Andres Freund writes:
> Do we have any cases of relcache entries changing their relkind?
Just the table-to-view hack. I'm not aware that there are any other
cases, and it seems hard to credit that there ever will be any.
I think we could get rid of table-to-view in HEAD, and use your patch
only
Hi,
On 2022-11-28 16:33:20 -0500, Tom Lane wrote:
> Andres Freund writes:
> > Something like the attached. Still needs a bit of polish, e.g. adding the
> > test
> > case from above.
>
> > I'm a bit uncomfortable adding a function call below
> > * Perform swapping of the relcache ent
Andres Freund writes:
> Something like the attached. Still needs a bit of polish, e.g. adding the test
> case from above.
> I'm a bit uncomfortable adding a function call below
>* Perform swapping of the relcache entry contents. Within this
>* process the old entr
Hi,
On 2022-11-28 10:50:13 -0800, Andres Freund wrote:
> On 2022-11-28 13:37:16 -0500, Tom Lane wrote:
> > Uh-huh. I've not bothered to trace this in detail, but presumably
> > what is happening is that the first CREATE RULE converts the table
> > to a view, and then the ROLLBACK undoes that so f
Andres Freund writes:
> On 2022-11-28 13:37:16 -0500, Tom Lane wrote:
>> As far as HEAD is concerned, maybe it's time to nuke the whole
>> convert-table-to-view kluge entirely? Only pg_dump older than
>> 9.4 will emit such code, so we're really about out of reasons
>> to keep on maintaining it.
Hi,
On 2022-11-28 13:37:16 -0500, Tom Lane wrote:
> vignesh C writes:
> > I could reproduce this issue with the following steps:
> > create table t1(c int);
> > BEGIN;
> > CREATE TABLE t (c int);
> > SAVEPOINT q;
> > CREATE RULE "_RETURN" AS ON SELECT TO t DO INSTEAD SELECT * FROM t1;
> > select
vignesh C writes:
> I could reproduce this issue with the following steps:
> create table t1(c int);
> BEGIN;
> CREATE TABLE t (c int);
> SAVEPOINT q;
> CREATE RULE "_RETURN" AS ON SELECT TO t DO INSTEAD SELECT * FROM t1;
> select * from t;
> ROLLBACK TO q;
> CREATE RULE "_RETURN" AS ON SELECT TO
On Mon, Nov 28, 2022 at 8:10 PM vignesh C wrote:
>
> Hi,
>
> While reviewing/testing one of the patches I found the following Assert:
> #0 __pthread_kill_implementation (no_tid=0, signo=6,
> threadid=139624429171648) at ./nptl/pthread_kill.c:44
> #1 __pthread_kill_internal (signo=6, threadid=139
Hi,
While reviewing/testing one of the patches I found the following Assert:
#0 __pthread_kill_implementation (no_tid=0, signo=6,
threadid=139624429171648) at ./nptl/pthread_kill.c:44
#1 __pthread_kill_internal (signo=6, threadid=139624429171648) at
./nptl/pthread_kill.c:78
#2 __GI___pthread_ki
17 matches
Mail list logo
