From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Something is broken about connection startup |
Date: | 2016-11-15 20:57:39 |
Message-ID: | 2757.1479243459@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Mon, Nov 14, 2016 at 4:42 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> ... I'm inclined to hold my nose and stick a call into step (1) of the
>> main loop instead.
> Seems like a good idea.
>> Also, wherever we end up putting those calls, is it worth providing a
>> variant invalidation function that only kills the catalog snapshot when
>> it's the only one outstanding? (If it isn't, the transaction snapshot
>> should be older, so there's no chance of advancing our xmin by killing
>> it.) In principle this would save some catalog snapshot rebuilds for
>> inside-a-transaction-block cases, but I'm not sure it's worth sweating
>> that when we're doing client message exchange anyway.
> I think that would be a fairly worthwhile thing to do.
>> Lastly, I find myself disliking the separate CatalogSnapshotStale flag
>> variable. The other special snapshots in snapmgr.c are managed by setting
>> the pointer to NULL when it's not valid, so I wonder why CatalogSnapshot
>> wasn't done that way. Since this patch is touching almost every use of
>> that flag already, it wouldn't take much to switch it over.
> I think I had some reason why I did it that way, but I don't think it
> was anything important, so I don't object to you revising it.
I've pushed a patch incorporating those changes. I can no longer
reproduce piculet's failure on branches back to 9.4. Still need to
look at the secondary issues I mentioned upthread.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Karl O. Pinc | 2016-11-15 21:15:52 | Re: Patch to implement pg_current_logfile() function |
Previous Message | Tobias Bussmann | 2016-11-15 20:57:09 | Re: Parallel execution and prepared statements |