On 31/01/2024 10:54, Thomas Munro wrote:
On Wed, Nov 29, 2023 at 1:42 PM Heikki Linnakangas wrote:
I spent some more time digging into this, experimenting with different
approaches. Came up with pretty significant changes; see below:
Hi Heikki,
I think this approach is good. As I wrote in t
On Wed, Nov 29, 2023 at 1:42 PM Heikki Linnakangas wrote:
> I spent some more time digging into this, experimenting with different
> approaches. Came up with pretty significant changes; see below:
Hi Heikki,
I think this approach is good. As I wrote in the first email, I had
briefly considered
On 29/11/2023 14:41, Heikki Linnakangas wrote:
2. A funny case with foreign tables: ANALYZE on a foreign table calls
visibilitymap_count(). A foreign table has no visibility map so it
returns 0, but before doing so it calls RelationGetSmgr on the foreign
table, which has 0/0/0 rellocator. That cr
I spent some more time digging into this, experimenting with different
approaches. Came up with pretty significant changes; see below:
On 18/09/2023 18:19, Robert Haas wrote:
I think that if you believe 0001 to be correct you should go ahead and
commit it sooner rather than later. If you're wro
I think that if you believe 0001 to be correct you should go ahead and
commit it sooner rather than later. If you're wrong and something
weird starts happening we'll then have a chance to notice that before
too much other stuff gets changed on top of this and confuses the
matter.
On Wed, Aug 23, 2
On Fri, Aug 18, 2023 at 2:30 AM Robert Haas wrote:
> I think this direction makes a lot of sense. The lack of a defined
> lifetime for SMgrRelation objects makes correct programming difficult,
> makes efficient programming difficult, and doesn't really have any
> advantages.
Thanks for looking!
On Thu, Aug 17, 2023 at 1:11 AM Thomas Munro wrote:
> Still WIP while I think about edge cases, but so far I think this is
> the better option.
I think this direction makes a lot of sense. The lack of a defined
lifetime for SMgrRelation objects makes correct programming difficult,
makes efficient
On Wed, Aug 16, 2023 at 4:11 AM Heikki Linnakangas wrote:
> Makes sense.
Thanks for looking!
> If you change smgrclose() to do what smgrrelease() does now, then it
> will apply automatically to extensions.
>
> If an extension is currently using smgropen()/smgrclose() correctly,
> this patch alon
On 14/08/2023 05:41, Thomas Munro wrote:
The new idea is to overload smgrrelease(it) so that it also clears the
owner, which means that AtEOXact_SMgr() will eventually smgrclose(it),
unless it is re-owned by a relation before then. That choice stems
from the complete lack of information availabl
Hi,
SMgrRelationData objects don't currently have a defined lifetime, so
it's hard to know when the result of smgropen() might become a
dangling pointer. This has caused a few bugs in the past, and the
usual fix is to just call smgropen() more often and not hold onto
pointers. If you're doing th
10 matches
Mail list logo
