On Sun, Jun 29, 2014 at 12:32 PM, Kevin Grittner <kgri...@ymail.com> wrote: >>> Moreover, there would be no way to implement a timeout like that without >>> adding a gettimeofday() call after every packet receipt, which is overhead >>> we do not need and cannot afford. I don't think this feature should add >>> *any* gettimeofday's beyond the ones that are already there. >> >> That's an especially good point if we think that this feature will be >> enabled commonly or by default - but as Fujii Masao says, it might be >> tricky to avoid. :-( > > I think that this patch, as it stands, is a clear win if the > postgres_fdw part is excluded. Remaining points of disagreement > seem to be the postgres_fdw, whether a default value measured in > days might be better than a default of off, and whether it's worth > the extra work of covering more. The preponderance of opinion > seems to be in favor of excluding the postgres_fdw changes, with > Tom being violently opposed to including it. I consider the idea > of the FDW ignoring the server setting dead. Expanding the > protected area of code seems like it would be sane to ask whoever > wants to extend the protection in that direction to propose a > patch. My sense is that there is more support for a default of a > small number of days than a default of never, but that seems far > from settled. > > I propose to push this as it stands except for the postgres_fdw > part. The default is easy enough to change if we reach consensus, > and expanding the scope can be a new patch in a new CF. > Objections?
Yeah, I think someone should do some analysis of whether this is adding gettimeofday() calls, and how many, and what the performance implications are. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
