Re: [HACKERS] read() returns ERANGE in Mac OS X
On May18, 2012, at 23:18 , Alvaro Herrera wrote: > Excerpts from Florian Pflug's message of jue may 17 09:08:26 -0400 2012: >> On May16, 2012, at 15:51 , Tom Lane wrote: > >>> It is by design, in that the only contemplated case was truncated-away >>> pages. I'm pretty hesitant to consider allowing arbitrary kernel errors >>> to be ignored here … >> >> Maybe we should have zero_missing_pages which would only zero on short reads, >> and zero_damaged_pages which would zero on all IO errors? >> >> Or we could have zero_damaged_pages zero only if reports EIO, and then add >> any platform-specific additional error codes as we learn about them. ERANGE >> on darwin would be the first such addition. > > Seems to me that we could make zero_damaged_pages an enum. The default > value of "on" would only catch truncated-away pages; another value would > also capture kernel-level error conditions. Yeah, an enum would be nicer than an additional GUC. I kinda keep forgetting that we have those. Though to bikeshed, the GUC should probably be just called 'zero_pages' and take the values 'never', 'missing', 'unreadable' ;-) > The thing is, once you start getting kernel-level errors you're pretty > much screwed and there's no way to just recover whatever data is > recoverable. I thought your initial gripe was precisely that you got a kernel-level error, yet the filesystem was still in pretty good shape? Which actually seemed quite likely to me - the cause could be, for example, simply a single bad block. Or a filesystem-level checksum error if you're using a filesystem with built-in integrity checks. best regards, Florian Pflug -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] External Open Standards
On Sat, May 12, 2012 at 5:37 AM, Simon Riggs wrote: > Do we have a full list of externally defined open standards that we follow? > > Are there any known incompatibilities from externally defined open standards? > (I know about the SQL standard stuff). The documentation is misleading to the point of our support for ISO 8601-strict parsing. http://archives.postgresql.org/pgsql-hackers/2012-02/msg01237.php A very fine point, but I discovered it not out of curiosity, but a fairly angry user on Twitter. We can define the problem away since the space-inclusive format is so common...so much so, that it is codified in RFC 3339 (http://www.ietf.org/rfc/rfc3339.txt). The only problem, then, is the DATESTYLE "ISO" labeling: changing that would be really painful, so perhaps another solution is to parse the "T" demanded by 8601, presuming no other details come to light. -- fdr -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Foreign keys in pgbench
On Sun, May 13, 2012 at 3:03 PM, Peter Geoghegan wrote: > On 13 May 2012 18:07, Jeff Janes wrote: >> I think that pgbench should it make it easy to assess the impact of >> foreign key constraints. > > I agree in principle. I favour being more inclusive about pgbench > options, even if the need for such options is only marginal, which > this isn't - I personally would have found it very useful recently. > pgbench is an expert-level tool, and I find arguments against adding > more options along the lines of "that will distract beginner users" > completely unconvincing. If it is a common position that people should probably be making better (to say, more) use of foreign key constraints -- something I agree with, although my colleagues have identified non-performance usability gaps that have to do with unit testing, resetting tables, deferred constraints, and cascading deletes -- it's probably a good idea to do our best to ensure that using them does not regress performance badly, at least. I might give a different answer if FK constraints had better penetration in applications and they were viewed as "just the cost of doing business", but that is not the case. All in all, though, I think the usability problems trump performance, and what's interesting is those usability problems are only seen in development, and not production. I mention this information because it may help you qualify my level of support for this idea. The goal would be for foreign keys to become usable enough that a framework like ActiveRecord might just use them by default. The recent inclusion of much more powerful query compilers, default(!) use of named prepared statements (perhaps even prematurely, given the problem with generic selectivity estimates), and hstore suggests that this time might yet come. Caveat being that I haven't researched any specific objections from ActiveRecord people yet. -- fdr -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] weird error message in sepgsql
I found this in contrib/sepgsql/expected/label.out: SECURITY LABEL ON COLUMN t2 IS 'system_u:object_r:sepgsql_ro_table_t:s0'; -- be failed ERROR: improper relation name (too many dotted names): Contrast with: SECURITY LABEL ON COLUMN t2.b IS 'system_u:object_r:sepgsql_ro_table_t:s0'; -- ok I guess what's happening is that it's calling makeRangeVarFromNameList() with a list of length zero. We should either fix the SECURITY LABEL command to catch that case beforehand, or fix makeRangeVarFromNameList() to give a proper error message, or both. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Remove readline notice from psql --version?
Currently, psql --version prints something like psql (PostgreSQL) 9.2beta1 contains support for command-line editing I think the notice about readline is a leftover from the old days when psql was often built without any readline support. Nowadays, this looks like an anomaly, and it doesn't actually contain any information that would be useful nowadays, such as which particular library is used or what kind of history support is active. I suggest we remove this second line, or alternatively, we could add more useful detail, but what? -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
