On 9/12/07, Tom Lane <[EMAIL PROTECTED]> wrote:
>
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Current README.HOT version:
> > ftp://momjian.us/pub/postgresql/mypatches/README.HOT
>
> I've done some further editorializing and wordsmithing on this,
> and marked with XXX some areas that seem
Tom Lane wrote:
So it looks like you need to recheck if unescape_single_char sees a
high-bit-set char.
You should take a second look at the COPY code to see if there's a
similar case there --- I forget what it does with backslash followed
by non-digit.
It's covered. Revised patch attach
ITAGAKI Takahiro wrote:
>
> [EMAIL PROTECTED] (Bruce Momjian) wrote:
>
> > Update FAQs for 8.2.5.
>
> This release is 8.2.5, but the version number in FAQ_japanese is 8.2.4.
> The mismatch has already been at least in 8.2.4 release.
I don't normally modify the language-specific FAQ's because of
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Also, I'd kinda like to have the check-for-high-bit optimization in
>> scan.l too --- some people do throw big literals at the thing.
>>
> OK, will do. Am I correct in thinking I don't need to worry about the
> case, only the and
[EMAIL PROTECTED] (Bruce Momjian) wrote:
> Update FAQs for 8.2.5.
This release is 8.2.5, but the version number in FAQ_japanese is 8.2.4.
The mismatch has already been at least in 8.2.4 release.
> Modified Files:
> --
> pgsql/doc:
> FAQ (r1.402.2.7 -> r1.402.2.8)
>
Tom Lane wrote:
Also, I'd kinda like to have the check-for-high-bit optimization in
scan.l too --- some people do throw big literals at the thing.
OK, will do. Am I correct in thinking I don't need to worry about the
case, only the and cases?
cheers
andrew
-
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Current README.HOT version:
> ftp://momjian.us/pub/postgresql/mypatches/README.HOT
I've done some further editorializing and wordsmithing on this,
and marked with XXX some areas that seem like they're still red flags
(or at least inadequately descr
On Tue, 2007-09-11 at 16:10 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > On Tue, 2007-09-11 at 09:21 +0530, Pavan Deolasee wrote:
> >> IMHO we are making full circles here. We have already tried LP_DELETE
> >> techniques and moved away to simplify things.
>
> >> We can sav
Simon Riggs <[EMAIL PROTECTED]> writes:
> On Tue, 2007-09-11 at 09:21 +0530, Pavan Deolasee wrote:
>> IMHO we are making full circles here. We have already tried LP_DELETE
>> techniques and moved away to simplify things.
>> We can save rest of the techniques for beta testing period or 8.4.
> Agr
There is a problem in PL/TCL that can cause the postgres backend to
become multithreaded. Postgres is not designed to be multithreaded, so
this causes downstream errors in signal handling. We have seen this
cause a number of "unexpected state" errors associated with notification
handling; ho
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Attached is a patch to the scanner and the COPY code that checks for
> invalidly encoded data that can currently leak into our system via \
> escapes in quoted literals or text mode copy fields, as recently
> discussed. That would still leave holes vi
Attached is a patch to the scanner and the COPY code that checks for
invalidly encoded data that can currently leak into our system via \
escapes in quoted literals or text mode copy fields, as recently
discussed. That would still leave holes via chr(), convert() and
possibly other functions,
Tom Lane wrote:
> "Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
>> Tom Lane wrote:
>>> Then you don't remember far enough --- either the HeapTupleHeader change
>>> or the varvarlena change would be enough to prevent that. For that
>>> matter, the pd_flags header field that the patch is already
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Then you don't remember far enough --- either the HeapTupleHeader change
>> or the varvarlena change would be enough to prevent that. For that
>> matter, the pd_flags header field that the patch is already relying on
>> is new f
Tom Lane wrote:
> "Pavan Deolasee" <[EMAIL PROTECTED]> writes:
>> I would actually think twice before even doing this because this would
>> lead to complete change in heap page structure and stop people from
>> upgrading to 8.3 without a complete dump/restore. I don't remember 8.3
>> introduces any
On 9/11/07, Tom Lane <[EMAIL PROTECTED]> wrote:
>
> "Pavan Deolasee" <[EMAIL PROTECTED]> writes:
> > I would actually think twice before even doing this because this would
> > lead to complete change in heap page structure and stop people from
> > upgrading to 8.3 without a complete dump/restore. I
"Pavan Deolasee" <[EMAIL PROTECTED]> writes:
> I would actually think twice before even doing this because this would
> lead to complete change in heap page structure and stop people from
> upgrading to 8.3 without a complete dump/restore. I don't remember 8.3
> introduces any other significant cha
On Tue, 2007-09-11 at 10:42 +0100, Simon Riggs wrote:
> 2. CountActiveBackends() searches the whole of the proc array, even
> though it could stop when it gets to commit_siblings. Stopping once the
> heuristic has been determined seems like the best thing to do. A small
> patch to implement this i
On 9/11/07, Pavan Deolasee <[EMAIL PROTECTED]> wrote:
>
>
> - Track the minimum xmin in the page header to avoid repeated
> (wasted) attempts to prune a Prunable page in the presence of long running
> transactions.
>
>
I would actually think twice before even doing this because this would lead
to
c
On 9/11/07, Tom Lane <[EMAIL PROTECTED]> wrote:
>
> "Pavan Deolasee" <[EMAIL PROTECTED]> writes:
> > Pruning removes intermediate dead tuples by marking their line pointers
> > ~LP_USED and redirecting the root line pointer to the first
> > live/recently_dead tuple in the chain.
>
> It seems utterl
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Gregory Stark <[EMAIL PROTECTED]> writes:
>> "Tom Lane" <[EMAIL PROTECTED]> writes:
>>> This patch implements Florian's idea about how to manage snapshot xmax
>>> without the ugly and performance-losing tactic of taking XidGenLock and
>>> ProcArrayLock at
Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
>> On Tue, 2007-09-11 at 01:22 +0530, Pavan Deolasee wrote:
>>> I think the only difference is that the quick pruning does not mark
>>> intermediate tuples ~LP_USED and hence we may avoid WAL logging.
>
>> Sounds great.
>
> What it sounds
"Teodor Sigaev" <[EMAIL PROTECTED]> writes:
> Did you check it on 64-bit boxes with strict alignment? I remember that was a
> headache for me.
Is there a regression test which would fail if this kind of problem crops up?
Not every developer can test every type of hardware but (aside from believin
On 9/11/07, Heikki Linnakangas <[EMAIL PROTECTED]> wrote:
>
>
>
> We're only changing the offsetnumber part of it, which is 2 bytes. That
> shouldn't cross a hardware sector boundary on any reasonable hardware.
>
>
Not entirely true if we consider line pointer redirection, which involves
changing 4
"Tom Lane" <[EMAIL PROTECTED]> writes:
> What it sounds is utterly unsafe. You can get away with not WAL-logging
> individual bit flips (that is, hint-bit-setting) because either state of
> the page is valid. If I read this proposal correctly it is to change
> t_ctid without WAL-logging, which
25 matches
Mail list logo
