Simon Riggs wrote:
There is no creation of corruption events. This scheme detects
corruption events that *have* occurred. Now I understand that we
previously would have recovered seamlessly from such events, but they
were corruption events nonetheless and I think they need to be reported.
On 12/1/09, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Mon, Nov 30, 2009 at 4:54 PM, Dimitri Fontaine
dfonta...@hi-media.com wrote:
Le 30 nov. 2009 à 22:38, Robert Haas a écrit :
I still don't really understand why we wouldn't want RESET ALL to
On Tue, 2009-12-01 at 10:04 +0200, Heikki Linnakangas wrote:
Simon Riggs wrote:
There is no creation of corruption events. This scheme detects
corruption events that *have* occurred. Now I understand that we
previously would have recovered seamlessly from such events, but they
were
On Tue, Dec 1, 2009 at 12:26 AM, Andres Freund and...@anarazel.de wrote:
Actually I think the poolers make a good case for a SET variant which emulates
connection set variables...
RESET ALL in a connection pooler does different things than RESET ALL outside
of one.
Eh? Not sure I follow
On Tuesday 01 December 2009 09:59:17 Dave Page wrote:
On Tue, Dec 1, 2009 at 12:26 AM, Andres Freund and...@anarazel.de wrote:
Actually I think the poolers make a good case for a SET variant which
emulates connection set variables...
RESET ALL in a connection pooler does different things
Dave Page wrote:
Upthread, Tom suggested a new 'SET DEFAULT ...' variant of SET which
could be used to set the default GUC value that RESET would revert to.
This seems to me to be the ideal solution, and I'd somewhat hesitantly
volunteer to work on it (hesitantly as it means touching the
On Tue, Dec 1, 2009 at 9:16 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Dave Page wrote:
Upthread, Tom suggested a new 'SET DEFAULT ...' variant of SET which
could be used to set the default GUC value that RESET would revert to.
This seems to me to be the ideal solution,
On Tuesday 01 December 2009 10:16:45 Heikki Linnakangas wrote:
Dave Page wrote:
Upthread, Tom suggested a new 'SET DEFAULT ...' variant of SET which
could be used to set the default GUC value that RESET would revert to.
This seems to me to be the ideal solution, and I'd somewhat hesitantly
The point is that every other thing you can set in a libpq connection
string is persistent throughout the connection. For the ones that you
can change at all, such as client_encoding, *RESET ALL actually resets
it to what was specified in the connection string*. It does not satisfy
the POLA
On Mon, 2009-11-30 at 14:38 +0900, Itagaki Takahiro wrote:
* VACUUM (FULL REPLACE) pg_class should be rejected, not silently
turned into VACUUM (FULL INPLACE) pg_class.
Hmmm, it requires to remember whether REPLACE is specified or not
for the non-INPLACE vacuum, but I don't want to add
On 12/1/09, Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote:
Dave Page wrote:
Upthread, Tom suggested a new 'SET DEFAULT ...' variant of SET which
could be used to set the default GUC value that RESET would revert to.
This seems to me to be the ideal solution, and I'd
Peter Eisentraut wrote:
On m?n, 2009-11-30 at 12:21 -0500, Bruce Momjian wrote:
! for thread safety; use --disable-thread-safety to disable
threading.])
--disable-thread-safety does not disable threading, it disables thread
safety.
Good point! Patch updated and attached.
What are we
Simon Riggs wrote:
The way we handle torn page corruptions *hides* actual corruptions from
us. The frequency of true positives and false positives is important
here. If the false positive ratio is very small, then reporting them is
not a problem because of the benefit we get from having
On Mon, Nov 30, 2009 at 10:16 PM, Greg Smith g...@2ndquadrant.com wrote:
Considering that one of those was a holiday week with a lot of schedule
disruption proceeding it, I don't know how much faster things could have
moved. There were large chunks of the reviewer volunteers who wanted only
On Tue, 1 Dec 2009 09:59:17 +0100, Dave Page dp...@pgadmin.org wrote:
I do see the argument that RESET ALL should revert user changes to
application_name though, but I maintain they should reset to the value
set at connection time, not to null. As has been pointed out already,
other values set
Hello.
The following patches support Windows x64.
1) use intptr_t for Datum and pointer macros. (to support Windows LLP64)
almost the same as that post before.
http://archives.postgresql.org/pgsql-hackers/2009-06/threads.php#01364
2) use appropriate macro and datatypes for Windows API.
Tom Lane escreveu:
Bruce Momjian br...@momjian.us writes:
So, if someone writes a patch, and it is reviewed, and the patch author
updates the patch and replies, it still should be reviewed again before
being committed?
Well, that's for the reviewer to say --- if the update satisfies his
On Tue, 2009-12-01 at 06:35 -0500, Bruce Momjian wrote:
Simon Riggs wrote:
The way we handle torn page corruptions *hides* actual corruptions from
us. The frequency of true positives and false positives is important
here. If the false positive ratio is very small, then reporting them is
On Mon, Nov 30, 2009 at 11:08 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Andrew Dunstan and...@dunslane.net writes:
As I have observed before, I think we need some infrastructure to help
committers claim items, so we don't duplicate work.
Robert acknowledged the need for a claimed by committer
Simon Riggs wrote:
I think
the problem is that the existing proposal can't distinguish between
these two cases so the user has no idea how to respond to the report.
If 99.5% of cases are real corruption then there is little need to
distinguish between the cases, nor much value in doing
On Mon, Nov 30, 2009 at 3:27 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Simon Riggs wrote:
Proposal
* We reserve enough space on a disk block for a CRC check. When a dirty
block is written to disk we calculate and annotate the CRC value, though
this is *not* WAL
Robert Haas wrote:
On Mon, Nov 30, 2009 at 11:08 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Andrew Dunstan and...@dunslane.net writes:
As I have observed before, I think we need some infrastructure to help
committers claim items, so we don't duplicate work.
Robert acknowledged the need for
Robert Haas wrote:
On Mon, Nov 30, 2009 at 3:27 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Simon Riggs wrote:
Proposal
* We reserve enough space on a disk block for a CRC check. When a dirty
block is written to disk we calculate and annotate the CRC value, though
On Tue, 2009-12-01 at 07:05 -0500, Bruce Momjian wrote:
I assume torn pages are 99% of the reported problem, which are
expected and are fixed, and bad hardware 1%, quite the opposite of your
numbers above.
On what basis do you make that assumption?
--
Simon Riggs
Simon Riggs wrote:
On Tue, 2009-12-01 at 07:05 -0500, Bruce Momjian wrote:
I assume torn pages are 99% of the reported problem, which are
expected and are fixed, and bad hardware 1%, quite the opposite of your
numbers above.
On what basis do you make that assumption?
Because we added
bruce wrote:
What might be interesting is to report CRC mismatches if the database
was shut down cleanly previously; I think in those cases we shouldn't
have torn pages.
Sorry, stupid idea on my part. We don't WAL log hit bit changes so
there is no guarantee the page is in WAL on recovery.
On Tue, 2009-12-01 at 07:58 -0500, Bruce Momjian wrote:
bruce wrote:
What might be interesting is to report CRC mismatches if the database
was shut down cleanly previously; I think in those cases we shouldn't
have torn pages.
Sorry, stupid idea on my part. We don't WAL log hit bit
On Tue, 2009-12-01 at 07:42 -0500, Bruce Momjian wrote:
Simon Riggs wrote:
On Tue, 2009-12-01 at 07:05 -0500, Bruce Momjian wrote:
I assume torn pages are 99% of the reported problem, which are
expected and are fixed, and bad hardware 1%, quite the opposite of your
numbers above.
Bruce Momjian wrote:
It would also like to clarify the use case for this a little bit more.
Is this just to track patches which committers are in the process of
committing (or have committed)? Or would a committer potentially set
this on some patch that was still being reviewed, and if so
Bruce Momjian wrote:
What might be interesting is to report CRC mismatches if the database
was shut down cleanly previously; I think in those cases we shouldn't
have torn pages.
Unfortunately that's not true. You can crash, leading to a torn page,
and then start up the database and shut it
On Mon, Nov 30, 2009 at 9:27 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Simon Riggs wrote:
Proposal
* We reserve enough space on a disk block for a CRC check. When a dirty
block is written to disk we calculate and annotate the CRC value, though
this is *not* WAL
On Tuesday 01 December 2009 14:38:26 marcin mank wrote:
On Mon, Nov 30, 2009 at 9:27 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Simon Riggs wrote:
Proposal
* We reserve enough space on a disk block for a CRC check. When a dirty
block is written to disk we
Thom Brown escreveu:
As far as I am aware, there is no way to tell when a user/role was
granted permissions or had permissions revoked, or who made these
changes. I'm wondering if it would be useful for security auditing to
maintain a history of permissions changes only accessible to
* Andres Freund and...@anarazel.de [091201 08:42]:
On Tuesday 01 December 2009 14:38:26 marcin mank wrote:
On Mon, Nov 30, 2009 at 9:27 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Simon Riggs wrote:
Proposal
* We reserve enough space on a disk block for a
On Tue, Dec 1, 2009 at 8:30 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Bruce Momjian wrote:
What might be interesting is to report CRC mismatches if the database
was shut down cleanly previously; I think in those cases we shouldn't
have torn pages.
Unfortunately
On Tue, Dec 1, 2009 at 8:27 AM, Andrew Dunstan and...@dunslane.net wrote:
Bruce Momjian wrote:
It would also like to clarify the use case for this a little bit more.
Is this just to track patches which committers are in the process of
committing (or have committed)? Or would a committer
Robert Haas robertmh...@gmail.com writes:
On Mon, Nov 30, 2009 at 11:08 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert acknowledged the need for a claimed by committer field in the
fest application, but he hasn't got round to it yet.
Sorry I haven't gotten around to this. Beyond being a
On Tuesday 01 December 2009 15:26:21 Aidan Van Dyk wrote:
* Andres Freund and...@anarazel.de [091201 08:42]:
On Tuesday 01 December 2009 14:38:26 marcin mank wrote:
On Mon, Nov 30, 2009 at 9:27 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Simon Riggs wrote:
Robert Haas wrote:
On Tue, Dec 1, 2009 at 8:30 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Bruce Momjian wrote:
What might be interesting is to report CRC mismatches if the database
was shut down cleanly previously; I think in those cases we shouldn't
have torn pages.
Robert Haas robertmh...@gmail.com writes:
If we went with Bruce's interpretation, we could have a committer
field that only appears when the status is Claimed by Committer or
Committed and the contents of that field could be displayed in
parentheses in the status column, like this: Claimed by
On Tue, Dec 1, 2009 at 9:42 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
If we went with Bruce's interpretation, we could have a committer
field that only appears when the status is Claimed by Committer or
Committed and the contents of that field could be
On Tue, 2009-12-01 at 15:30 +0200, Heikki Linnakangas wrote:
Bruce Momjian wrote:
What might be interesting is to report CRC mismatches if the database
was shut down cleanly previously; I think in those cases we shouldn't
have torn pages.
Unfortunately that's not true. You can crash,
On Tue, Dec 1, 2009 at 9:40 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Even if rescanning every page in the cluster was feasible from a
performance point-of-view, it would make the CRC checking a lot less
useful. It's not hard to imagine that when a hardware glitch
BTW, if you have time for any purely cosmetic details ... the way the
CommitFest field on a patch detail page works has always struck me as
weird. It's a data field, and so if it has any behavior at all that
behavior ought to involve modifying its value. But what it actually is
is a navigation
* Simon Riggs:
* Put all hint bits in the block header to allow them to be excluded
more easily from CRC checking. If we used 3 more bits from
ItemIdData.lp_len (limiting tuple length to 4096) then we could store
some hints in the item pointer. HEAP_XMIN_INVALID can be stored as
LP_DEAD,
Tom Lane t...@sss.pgh.pa.us wrote:
How old were the sessions you were looking at?
Days to months old.
If we think this is worth doing something about
(I'm not convinced yet)
Once one knows about the issue, it's only a minor annoyance, and
that infrequently, so it's not worth anything
Robert Haas wrote:
OK, I'll add a separate text field for the committer's name, but for
now it won't display on the summary page, just the detail page.
Perhaps it could go underneath the reviewer names, maybe in a different
color. (And yes, like many of us I suck at GUI design, so
On Tue, Dec 1, 2009 at 6:25 AM, Tsutomu Yamada tsut...@sraoss.co.jp wrote:
Hello.
The following patches support Windows x64.
1) use intptr_t for Datum and pointer macros. (to support Windows LLP64)
almost the same as that post before.
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Is there a reasonably cheap way to check whether the backend has a
WAL file open and whether that one is the current append target?
Detecting whether we have a WAL file open is trivial (just look at
the static variable holding the file
Florian Weimer fwei...@bfk.de writes:
What about putting the whole visibility information out-of-line, into
its own B-tree, indexed by page number?
Hint bits need to be *cheap* to examine. Otherwise there's little
point in having them at all.
regards, tom lane
--
2009/11/30 rahimeh khodadadi rahimeh.khodad...@gmail.com:
-- Forwarded message --
From: rahimeh khodadadi rahimeh.khodad...@gmail.com
Date: 2009/11/29
Subject: Re: psql+krb5
To: Denis Feklushkin denis.feklush...@gmail.com
Please review the guidelines for reporting a
On Tue, 2009-12-01 at 16:40 +0200, Heikki Linnakangas wrote:
It's not hard to imagine that when a hardware glitch happens
causing corruption, it also causes the system to crash. Recalculating
the CRCs after crash would mask the corruption.
They are already masked from us, so continuing to
Simon Riggs si...@2ndquadrant.com writes:
On Tue, 2009-12-01 at 16:40 +0200, Heikki Linnakangas wrote:
It's not hard to imagine that when a hardware glitch happens
causing corruption, it also causes the system to crash. Recalculating
the CRCs after crash would mask the corruption.
They are
On Tue, Dec 1, 2009 at 10:35 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Tue, 2009-12-01 at 16:40 +0200, Heikki Linnakangas wrote:
It's not hard to imagine that when a hardware glitch happens
causing corruption, it also causes the system to crash. Recalculating
the CRCs after crash would
Dave Page dp...@pgadmin.org writes:
On Tue, Dec 1, 2009 at 9:16 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
If an application can do SET DEFAULT, how does the connection pooler
*really* reset the value back to what it was?
There has to be some level of trust here :-).
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
I wrote:
No, it should be longer. June is practically around the corner
as far as business planning is concerned. Make it a year. Since it's
mid November, why not just say 2011?
This thread never got resolved. I think we can all agree that
On Tue, Dec 1, 2009 at 4:19 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I don't think that we need to bump the protocol version. The real
alternative here would be that libpq sends a startup packet that
includes application_name, and if it gets an error back from that,
it starts over without the
Except that he posted a month ago and got no answers...
On Tue, Dec 1, 2009 at 8:22 AM, Robert Haas robertmh...@gmail.com wrote:
2009/11/30 rahimeh khodadadi rahimeh.khodad...@gmail.com:
-- Forwarded message --
From: rahimeh khodadadi rahimeh.khodad...@gmail.com
Date:
Dave Page dp...@pgadmin.org writes:
On Tue, Dec 1, 2009 at 4:19 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I don't think that we need to bump the protocol version. The real
alternative here would be that libpq sends a startup packet that
includes application_name, and if it gets an error back
On Tue, Dec 1, 2009 at 4:28 PM, Tom Lane t...@sss.pgh.pa.us wrote:
If people are agreed that double connect is a better alternative
I still kinda like 'SET DEFAULT', but I'm far from wed to it. A double
connect certainly seems like it would be better than the
inconsistency.
I'm willing to go
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Playing around with this a bit, I was easily able to get 2-second
planing times on 15 table join, 6-second planning times on a 16 table
join and 30-second planning times on a 17 table join. This makes it
Greg Sabino Mullane g...@turnstep.com writes:
This thread never got resolved. I think we can all agree that EOL
for 7.4 is a when, not an if? Can we get -core to take a stance
here and pick a date? I like the clean smooth lines of January 2011,
and thus saying that 2010 is the last year in
On Tue, Dec 1, 2009 at 4:41 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Greg Sabino Mullane g...@turnstep.com writes:
This thread never got resolved. I think we can all agree that EOL
for 7.4 is a when, not an if? Can we get -core to take a stance
here and pick a date? I like the clean smooth lines
On 12/1/09, Tom Lane t...@sss.pgh.pa.us wrote:
Dave Page dp...@pgadmin.org writes:
On Tue, Dec 1, 2009 at 4:19 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I don't think that we need to bump the protocol version. The real
alternative here would be that libpq sends a startup packet that
Found this a couple of weeks back and just re-tested against head:
CREATE TEXT SEARCH DICTIONARY with an empty thesaurus file will crasch
the backend.
To reproduce:
$ echo $(pg_config --sharedir)/tsearch_data/thesaurus_empty.ths
Then use this thesaurus to create a text search dictionary:
Thank you very much!
-邮件原件-
发件人: Robert Haas [mailto:robertmh...@gmail.com]
发送时间: 2009年12月1日 1:37
收件人: 张中
抄送: pgsql-hackers@postgresql.org
主题: Re: [HACKERS] is isolation level 'Serializable' in pg not same as
'serializable' in SQL-92?
2009/11/30 张茂森 maosen.zh...@alibaba-inc.com:
On Tue, 1 Dec 2009, Tom Lane wrote:
Greg Sabino Mullane g...@turnstep.com writes:
This thread never got resolved. I think we can all agree that EOL
for 7.4 is a when, not an if? Can we get -core to take a stance
here and pick a date? I like the clean smooth lines of January 2011,
and thus
On Tue, Dec 1, 2009 at 11:26 AM, Scott Marlowe scott.marl...@gmail.com wrote:
Except that he posted a month ago and got no answers...
Gee, I wonder why.
...Robert
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On Tue, 2009-12-01 at 07:05 -0500, Bruce Momjian wrote:
All useful detection mechanisms have non-zero false positives because we
would rather sometimes ring the bell for no reason than to let bad
things through silently, as we do now.
OK, but what happens if someone gets the failure
On Tue, 2009-12-01 at 10:55 -0500, Tom Lane wrote:
Simon Riggs si...@2ndquadrant.com writes:
On Tue, 2009-12-01 at 16:40 +0200, Heikki Linnakangas wrote:
It's not hard to imagine that when a hardware glitch happens
causing corruption, it also causes the system to crash. Recalculating
the
This is a duplicate report and has been fixed by Tom already.
---
Robert Gravsj? wrote:
Found this a couple of weeks back and just re-tested against head:
CREATE TEXT SEARCH DICTIONARY with an empty thesaurus file will
On Tue, 2009-12-01 at 10:55 -0500, Tom Lane wrote:
Simon Riggs si...@2ndquadrant.com writes:
On Tue, 2009-12-01 at 16:40 +0200, Heikki Linnakangas wrote:
It's not hard to imagine that when a hardware glitch happens
causing corruption, it also causes the system to crash. Recalculating
the
Simon Riggs wrote:
Also, we might
* Put all hint bits in the block header to allow them to be excluded
more easily from CRC checking. If we used 3 more bits from
ItemIdData.lp_len (limiting tuple length to 4096) then we could store
some hints in the item pointer. HEAP_XMIN_INVALID can be
Tom Lane t...@sss.pgh.pa.us wrote:
Determining whether it's still the current append target is not so
cheap though; it would require examining shared-memory status
which means taking a lock on that status (and it's a high-traffic
lock already).
I haven't reviewed the internal locking
On Tue, Dec 1, 2009 at 11:39 AM, Greg Sabino Mullane g...@turnstep.com wrote:
Playing around with this a bit, I was easily able to get 2-second
planing times on 15 table join, 6-second planning times on a 16 table
join and 30-second planning times on a 17 table join. This makes it
hard to
On Tue, Dec 1, 2009 at 1:02 PM, Joshua D. Drake j...@commandprompt.com wrote:
The hard core reality is this. *IF* it is one of the goals of this
project to insure that the software can be safely, effectively, and
responsibly operated in a manner that is acceptable to C* level people
in a
On Tue, 2009-12-01 at 13:05 -0500, Bruce Momjian wrote:
Simon Riggs wrote:
Also, we might
* Put all hint bits in the block header to allow them to be excluded
more easily from CRC checking. If we used 3 more bits from
ItemIdData.lp_len (limiting tuple length to 4096) then we could
Marko Kreen mark...@gmail.com writes:
If the pooler gets new connection with same username:database
as some existing connection, but with different appname,
what it is supposed to do?
Whatever it wants to. People seem to be imagining that the appname
isn't under the control of the pooler.
Simon Riggs wrote:
commit 02c3eadb766201db084b668daa271db4a900adc9
Author: Simon Riggs sri...@ebony.(none)
Date: Sat Nov 28 06:23:33 2009 +
Added wal_standby_info GUC to turn RM_STANDBY_ID messages on/off.
Various comments added also.
This patch makes it unsafe to start hot
On Tue, 2009-12-01 at 13:20 -0500, Robert Haas wrote:
On Tue, Dec 1, 2009 at 1:02 PM, Joshua D. Drake j...@commandprompt.com
wrote:
The hard core reality is this. *IF* it is one of the goals of this
project to insure that the software can be safely, effectively, and
responsibly operated
Marc G. Fournier scra...@hub.org writes:
What are RedHats EOL dates for the various releases?
Dave already mentioned a public page for that:
http://www.redhat.com/security/updates/errata/
Based on track record so far, Red Hat isn't going to care about anything
but high-priority security issues
Bruce Momjian br...@momjian.us writes:
OK, here is another idea, maybe crazy:
When we read in a page that has an invalid CRC, we check the page to see
which hint bits are _not_ set, and we try setting them to see if can get
a matching CRC. If there no missing hint bits and the CRC doesn't
Simon Riggs si...@2ndquadrant.com writes:
On Tue, 2009-12-01 at 13:05 -0500, Bruce Momjian wrote:
When we read in a page that has an invalid CRC, we check the page to see
which hint bits are _not_ set, and we try setting them to see if can get
a matching CRC.
Perhaps we could store a
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Tom Lane t...@sss.pgh.pa.us wrote:
Determining whether it's still the current append target is not so
cheap though; it would require examining shared-memory status
which means taking a lock on that status (and it's a high-traffic
lock
* Tom Lane t...@sss.pgh.pa.us [091201 13:58]:
Actually, the killer problem with *any* scheme involving guessing
is that each bit you guess translates directly to removing one bit
of confidence from the CRC value. If you try to guess at as many
as 32 bits, it is practically guaranteed that
Robert Haas robertmh...@gmail.com writes:
On Tue, Dec 1, 2009 at 11:39 AM, Greg Sabino Mullane g...@turnstep.com
wrote:
What about 14? Could we at least raise it to 14? 1/2 :)
I doubt we can raise it at all without lying to ourselves about the
likely results of so doing. The GEQO planning
On Tue, Dec 1, 2009 at 6:41 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Bruce Momjian br...@momjian.us writes:
OK, here is another idea, maybe crazy:
When we read in a page that has an invalid CRC, we check the page to see
which hint bits are _not_ set, and we try setting them to see if can get
a
Tom Lane t...@sss.pgh.pa.us wrote:
Perhaps, if you didn't mind sometimes getting a wrong answer.
Well, it would be a heuristic which would close the deleted file
*almost* all the time. When it didn't, the next check would
probably catch it. Assuming that you would never get an indication
Greg Stark gsst...@mit.edu writes:
Another thought is that would could use the MSSQL-style torn page
detection of including a counter (or even a bit?) in every 512-byte
chunk which gets incremented every time the page is written.
I think we can dismiss that idea, or any idea involving a
is there a reason why we can't follow a similar 4+3 life cycle?
packagers r produced for the first 4y after .0 release and only source
updates for year 5 thru 7?
if we could advertise such on the web, there would be no question as
to when bug reports are accepted (n+4y) and when only
All,
I feel strongly that we should be verifying pages on write, or at least
providing the option to do so, because hardware is simply not reliable.
And a lot of our biggest users are having issues; it seems pretty much
guarenteed that if you have more than 20 postgres servers, at least one
of
2009/12/1 Bruce Momjian br...@momjian.us:
Peter Eisentraut wrote:
On m?n, 2009-11-30 at 12:21 -0500, Bruce Momjian wrote:
! for thread safety; use --disable-thread-safety to disable
threading.])
--disable-thread-safety does not disable threading, it disables thread
safety.
Good point!
This is totally separate from the really important question of whether
SE-Linux has a future, and another about whether, if SE-Linux has a
future, PostgreSQL needs to go there.
If the hooks are generic enough that the could potentially be adapted to
other security frameworks, yes. The need
Scrappy wrote:
is there a reason why we can't follow a similar 4+3 life cycle?
packagers r produced for the first 4y after .0 release and only source
updates for year 5 thru 7?
if we could advertise such on the web, there would be no question as
to when bug reports are accepted (n+4y)
On Mon, 2009-11-30 at 20:28 -0800, David Fetter wrote:
This is totally separate from the really important question of whether
SE-Linux has a future, and another about whether, if SE-Linux has a
future, PostgreSQL needs to go there.
Why would we think that it doesn't? Maybe I haven't been
Magnus Hagander mag...@hagander.net writes:
2009/12/1 Bruce Momjian br...@momjian.us:
What are we going to do for build farm members who don't support
threading? Is someone going to manually update their configure flags?
Yeah, I think so.
Unless there's a whole lot of them, in which case
Andrew Dunstan and...@dunslane.net writes:
The time between these periodic debates seems to be getting shorter and
shorter.
No, this is just a continuation of the unresolved thread from a month or
so ago.
regards, tom lane
--
Sent via pgsql-hackers mailing list
Josh Berkus j...@agliodbs.com wrote:
And a lot of our biggest users are having issues; it seems pretty
much guarenteed that if you have more than 20 postgres servers, at
least one of them will have bad memory, bad RAID and/or a bad
driver.
Huh?!? We have about 200 clusters running on
On Tue, Dec 1, 2009 at 7:19 PM, Josh Berkus j...@agliodbs.com wrote:
However, that solution would not detect subtle corruption, like
single-bit-flipping issues caused by quantum errors.
Well there is a solution for this, ECC RAM. There's *no* software
solution for it. The corruption can just as
Joshua D. Drake j...@commandprompt.com writes:
On Mon, 2009-11-30 at 20:28 -0800, David Fetter wrote:
This is totally separate from the really important question of whether
SE-Linux has a future, and another about whether, if SE-Linux has a
future, PostgreSQL needs to go there.
Why would we
1 - 100 of 173 matches
Mail list logo
