Skip to content

P
Postgres FD Implementation
Switch branch/tag
  1. 17 Jul, 2008 2 commits
  3. 16 Jul, 2008 7 commits
  5. 15 Jul, 2008 8 commits
  7. 14 Jul, 2008 9 commits
  9. 13 Jul, 2008 2 commits
    • Tom Lane's avatar
      Change the PageGetContents() macro to guarantee its result is maxalign'd, · 6816577a
      Tom Lane authored 
      thereby forestalling any problems with alignment of the data structure placed
there.  Since SizeOfPageHeaderData is maxalign'd anyway in 8.3 and HEAD, this
does not actually change anything right now, but it is foreseeable that the
header size will change again someday.  I had to fix a couple of places that
were assuming that the content offset is just SizeOfPageHeaderData rather than
MAXALIGN(SizeOfPageHeaderData).  Per discussion of Zdenek's page-macros patch.
      6816577a
    • Tom Lane's avatar
      Clean up the use of some page-header-access macros: principally, use · 9d035f42
      Tom Lane authored 
      SizeOfPageHeaderData instead of sizeof(PageHeaderData) in places where that
makes the code clearer, and avoid casting between Page and PageHeader where
possible.  Zdenek Kotala, with some additional cleanup by Heikki Linnakangas.

I did not apply the parts of the proposed patch that would have resulted in
slightly changing the on-disk format of hash indexes; it seems to me that's
not a win as long as there's any chance of having in-place upgrade for 8.4.
      9d035f42
  11. 12 Jul, 2008 4 commits
  13. 11 Jul, 2008 5 commits
  15. 10 Jul, 2008 3 commits
    • Tom Lane's avatar
      Add unchangeable GUC "variables" segment_size, wal_block_size, and · 7a97abe8
      Tom Lane authored 
      wal_segment_size to make those configuration parameters available to clients,
in the same way that block_size was previously exposed.  Bernd Helmle, with
comments from Abhijit Menon-Sen and some further tweaking by me.
      7a97abe8
    • Tom Lane's avatar
      Tighten up SS_finalize_plan's computation of valid_params to exclude Params of · eaf1b5d3
      Tom Lane authored 
      the current query level that aren't in fact output parameters of the current
initPlans.  (This means, for example, output parameters of regular subplans.)
To make this work correctly for output parameters coming from sibling
initplans requires rejiggering the API of SS_finalize_plan just a bit:
we need the siblings to be visible to it, rather than hidden as
SS_make_initplan_from_plan had been doing.  This is really part of my response
to bug #4290, but I concluded this part probably shouldn't be back-patched,
since all that it's doing is to make a debugging cross-check tighter.
      eaf1b5d3
    • Tom Lane's avatar
      Fix mis-calculation of extParam/allParam sets for plan nodes, as seen in · 772a6d45
      Tom Lane authored 
      bug #4290.  The fundamental bug is that masking extParam by outer_params,
as finalize_plan had been doing, caused us to lose the information that
an initPlan depended on the output of a sibling initPlan.  On reflection
the best thing to do seemed to be not to try to adjust outer_params for
this case but get rid of it entirely.  The only thing it was really doing
for us was to filter out param IDs associated with SubPlan nodes, and that
can be done (with greater accuracy) while processing individual SubPlan
nodes in finalize_primnode.  This approach was vindicated by the discovery
that the masking method was hiding a second bug: SS_finalize_plan failed to
remove extParam bits for initPlan output params that were referenced in the
main plan tree (it only got rid of those referenced by other initPlans).
It's not clear that this caused any real problems, given the limited use
of extParam by the executor, but it's certainly not what was intended.

I originally thought that there was also a problem with needing to include
indirect dependencies on external params in initPlans' param sets, but it
turns out that the executor handles this correctly so long as the depended-on
initPlan is earlier in the initPlans list than the one using its output.
That seems a bit of a fragile assumption, but it is true at the moment,
so I just documented it in some code comments rather than making what would
be rather invasive changes to remove the assumption.

Back-patch to 8.1.  Previous versions don't have the case of initPlans
referring to other initPlans' outputs, so while the existing logic is still
questionable for them, there are not any known bugs to be fixed.  So I'll
refrain from changing them for now.
      772a6d45