| From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Peter Geoghegan <pg(at)heroku(dot)com>, Jeff Davis <pgsql(at)j-davis(dot)com>, Satoshi Nagayasu <snaga(at)uptime(dot)jp>, Josh Kupershmidt <schmiddy(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: pg_filedump 9.3: checksums (and a few other fixes) |
| Date: | 2013-07-17 17:43:43 |
| Message-ID: | 20130717174343.GF4165@eldon.alvh.no-ip.org |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Tom Lane escribió:
> My feeling about this code is that the reason we print the infomask in
> hex is so you can see exactly which bits are set if you care, and that
> the rest of the line ought to be designed to interpret the bits in as
> reader-friendly a way as possible. So I don't buy the notion that we
> should just print out a name for each bit that's set. I'd rather
> replace individual bit names with items like LOCKED_FOR_KEY_SHARE,
> LOCKED_FOR_SHARE, etc in cases where you have to combine multiple
> bits to understand the meaning.
Okay, that's what I've been saying all along so I cannot but agree. I
haven't reviewed Jeff's patch lately; Jeff, does Tom's suggestion need
some more new code, and if so are you open to doing this work, or shall
I?
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Gurjeet Singh | 2013-07-17 18:03:10 | Re: review: Non-recursive processing of AND/OR lists |
| Previous Message | Heikki Linnakangas | 2013-07-17 17:36:44 | Re: pgsql: Optimize pglz compressor for small inputs. |