On Mon, 2007-09-10 at 22:24 -0400, 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
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.
Agreed, we're just fine tuning by reinventing old
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 means
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 bytes.
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 believing
the
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 is utterly
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 the same time. I had
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 utterly unsafe to do
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
complete
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 is
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 change
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 don't
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 other
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
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;
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 save rest of the
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
xeescape case, only the xeoctesc and xehexesc
[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)
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 the
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
20 matches
Mail list logo
