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 wrote:
> Robert Haas writes:
> > On Mon, Nov 30, 2009 at 4:54 PM, Dimitri Fontaine
> > 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
> >>> reset the application name. In what circumsta
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
> > w
On Tue, Dec 1, 2009 at 12:26 AM, Andres Freund 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 that, but then I h
On Tuesday 01 December 2009 09:59:17 Dave Page wrote:
> On Tue, Dec 1, 2009 at 12:26 AM, Andres Freund 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
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 pa
On Tue, Dec 1, 2009 at 9:16 AM, 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
>
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 hesit
> 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
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
On 12/1/09, 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
> > volunteer
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 a
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 spo
On Mon, Nov 30, 2009 at 10:16 PM, Greg Smith 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
> jobs they could fi
On Tue, 1 Dec 2009 09:59:17 +0100, Dave Page 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 at connection time
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 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
> concerns,
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
On Mon, Nov 30, 2009 at 11:08 PM, Tom Lane wrote:
> Andrew Dunstan 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" field in the
> fest application
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
On Mon, Nov 30, 2009 at 3:27 PM, Heikki Linnakangas
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 logged.
>
> Imagine this:
> 1.
Robert Haas wrote:
> On Mon, Nov 30, 2009 at 11:08 PM, Tom Lane wrote:
> > Andrew Dunstan 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"
Robert Haas wrote:
> On Mon, Nov 30, 2009 at 3:27 PM, Heikki Linnakangas
> 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*
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 www.2ndQuadran
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
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
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
> > > numb
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 wou
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
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 logged.
>
> Imagine this:
> 1.
On Tuesday 01 December 2009 14:38:26 marcin mank wrote:
> On Mon, Nov 30, 2009 at 9:27 PM, Heikki Linnakangas
>
> 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 t
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 super
* Andres Freund [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
> >
> > wrote:
> > > Simon Riggs wrote:
> > >> Proposal
> > >>
> > >> * We reserve enough space on a disk block for a CRC check. When a dirty
> > >> b
On Tue, Dec 1, 2009 at 8:30 AM, 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 8:27 AM, Andrew Dunstan 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 potentiall
Robert Haas writes:
> On Mon, Nov 30, 2009 at 11:08 PM, Tom Lane 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 little burned
> out a little bit, I h
On Tuesday 01 December 2009 15:26:21 Aidan Van Dyk wrote:
> * Andres Freund [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
> > >
> > > wrote:
> > > > Simon Riggs wrote:
> > > >> Proposal
> > > >>
> > > >> * We
Robert Haas wrote:
> On Tue, Dec 1, 2009 at 8:30 AM, 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
Robert Haas 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 Committer (T
On Tue, Dec 1, 2009 at 9:42 AM, Tom Lane wrote:
> Robert Haas 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 i
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 c
On Tue, Dec 1, 2009 at 9:40 AM, Heikki Linnakangas
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 happens
> causing corruption, it also c
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 li
* 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 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 that would take
si
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 feel
On Tue, Dec 1, 2009 at 6:25 AM, Tsutomu Yamada 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.
> http://archives.postgresql.org/pgsql-hackers/2009-06/threads.php#0
"Kevin Grittner" 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 descriptor). Determining whethe
Florian Weimer 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
--
Sent via pgsql-h
2009/11/30 rahimeh khodadadi :
>
>
> -- Forwarded message --
> From: rahimeh khodadadi
> Date: 2009/11/29
> Subject: Re: psql+krb5
> To: Denis Feklushkin
Please review the guidelines for reporting a problem, which you can find here:
http://wiki.postgresql.org/wiki/Guide_to_repor
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 m
Simon Riggs 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 already masked
On Tue, Dec 1, 2009 at 10:35 AM, Simon Riggs 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 mask the corru
Dave Page writes:
> On Tue, Dec 1, 2009 at 9:16 AM, Heikki Linnakangas
> 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 :-). As the alternative would
> involve bumping the
-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 th
On Tue, Dec 1, 2009 at 4:19 PM, Tom Lane 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 app name. The
Except that he posted a month ago and got no answers...
On Tue, Dec 1, 2009 at 8:22 AM, Robert Haas wrote:
> 2009/11/30 rahimeh khodadadi :
>>
>>
>> -- Forwarded message --
>> From: rahimeh khodadadi
>> Date: 2009/11/29
>> Subject: Re: psql+krb5
>> To: Denis Feklushkin
>
> Pleas
Dave Page writes:
> On Tue, Dec 1, 2009 at 4:19 PM, Tom Lane 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 wit
On Tue, Dec 1, 2009 at 4:28 PM, Tom Lane 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 look at how to ma
-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" 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 which we'll
On Tue, Dec 1, 2009 at 4:41 PM, Tom Lane wrote:
> "Greg Sabino Mullane" 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,
>> an
On 12/1/09, Tom Lane wrote:
> Dave Page writes:
> > On Tue, Dec 1, 2009 at 4:19 PM, Tom Lane 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 e
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 张茂森 :
>
pgsql-hackers is not the right pl
On Tue, 1 Dec 2009, Tom Lane wrote:
"Greg Sabino Mullane" 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
On Tue, Dec 1, 2009 at 11:26 AM, Scott Marlowe 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:
http://www.postgresql.org/mailpref/pgsql-hack
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 fa
On Tue, 2009-12-01 at 10:55 -0500, Tom Lane wrote:
> Simon Riggs 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
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 wil
On Tue, 2009-12-01 at 10:55 -0500, Tom Lane wrote:
> Simon Riggs 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
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
Tom Lane 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 techniques, so this
On Tue, Dec 1, 2009 at 11:39 AM, Greg Sabino Mullane 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 support raisi
On Tue, Dec 1, 2009 at 1:02 PM, Joshua D. Drake 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 Fortune level company th
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
Marko Kreen 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. It's a connection
Simon Riggs wrote:
> commit 02c3eadb766201db084b668daa271db4a900adc9
> Author: Simon Riggs
> 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 standby mode
On Tue, 2009-12-01 at 13:20 -0500, Robert Haas wrote:
> On Tue, Dec 1, 2009 at 1:02 PM, Joshua D. Drake
> 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
"Marc G. Fournier" 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 towards the
Bruce Momjian 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
> match, we kno
Simon Riggs 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 sector-based parity b
"Kevin Grittner" writes:
> Tom Lane 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 inter
* Tom Lane [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 you will find a
Robert Haas writes:
> On Tue, Dec 1, 2009 at 11:39 AM, Greg Sabino Mullane
> 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 times are in the low
> double dig
On Tue, Dec 1, 2009 at 6:41 PM, Tom Lane wrote:
> Bruce Momjian 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.
Unfortuna
Tom Lane 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
that it was differen
Greg Stark 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 per-page
status val
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 secu
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 th
2009/12/1 Bruce Momjian :
> 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) and
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 fo
Magnus Hagander writes:
> 2009/12/1 Bruce Momjian :
>> 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 we revert the patch.
It would
Andrew Dunstan 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 (pgsql-hackers@postgres
Josh Berkus 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 about 100 boxes, a
On Tue, Dec 1, 2009 at 7:19 PM, Josh Berkus 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 easily happen t
"Joshua D. Drake" 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 think that it
1 - 100 of 173 matches
Mail list logo
