| From: | "Guillaume Smet" <guillaume(dot)smet(at)gmail(dot)com> |
|---|---|
| To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | "Gregory Stark" <stark(at)enterprisedb(dot)com>, "pgsql-hackers list" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: CLUSTER and synchronized scans and pg_dump et al |
| Date: | 2008-01-27 18:09:32 |
| Message-ID: | 1d4e0c10801271009k79924bbbi18afb8583b71d421@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Jan 27, 2008 6:45 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Yeah, Rae Steining was complaining to me about that off-list a few weeks
> ago. The whole syncscan behavior risks breaking many apps that "always
> worked before", even if they were disregarding the letter of the SQL spec.
>
> Maybe a GUC variable to enable/disable syncscan?
I'm not sure it's really a good reason for that because it's just a
matter of time for them to be broken anyway.
But it seems at least a good idea to have a way to build reproducible
test cases on production boxes without being perturbed by the other
scans running. Would it need a restart and be a global GUC variable or
could it be set temporarily per session?
--
Guillaume
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2008-01-27 18:14:33 | Re: CLUSTER and synchronized scans and pg_dump et al |
| Previous Message | Tom Lane | 2008-01-27 17:45:16 | Re: CLUSTER and synchronized scans and pg_dump et al |