Re: sinval.c / sinvaladt.c restructuring - Mailing list pgsql-patches

From Bruce Momjian
Subject Re: sinval.c / sinvaladt.c restructuring
Date
Msg-id 200803031713.m23HDJn20479@momjian.us
Whole thread Raw
In response to sinval.c / sinvaladt.c restructuring  (Alvaro Herrera <alvherre@commandprompt.com>)
List pgsql-patches
Your patch has been added to the PostgreSQL unapplied patches list at:

    http://momjian.postgresql.org/cgi-bin/pgpatches

It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.

---------------------------------------------------------------------------


Alvaro Herrera wrote:
> I just modified the interactions in sinval.c and sinvaladt.c per
> http://thread.gmane.org/gmane.comp.db.postgresql.devel.patches/18820/focus=18822
>
> It looks a lot saner this way: the code that actually deals with the
> queue, including locking etc, is all in sinvaladt.c.  This means that
> the struct definition of the queue, and the queue pointer, are now
> internal "implementation details" inside sinvaladt.c.
>
> One side effect of this change is that the call to SendPostmasterSignal
> now occurs after the lock has been released.  ISTM this is a good idea
> on general principles (no syscalls in lwlocked code), but I'm wondering
> if I created a thundering hoard problem that did not exist before.
>
> All tests pass.
>
> As a test of Review Board, I uploaded the patch to it:
> http://reviewdemo.postgresql.org/r/19/
>
> --
> Alvaro Herrera                                http://www.CommandPrompt.com/
> The PostgreSQL Company - Command Prompt, Inc.

[ Attachment, skipping... ]

>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: In versions below 8.0, the planner will ignore your desire to
>        choose an index scan if your joining column's datatypes do not
>        match

--
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://postgres.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

pgsql-patches by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Remove FATAL from pg_lzdecompress
Next
From: Andrew Dunstan
Date:
Subject: Re: [BUGS] BUG #4007: chr(0) doesn't work anymore