t. For instance, in the patch
as I posted it last night, both heap_hot_search and index_getnext
probably fail to detect all-dead HOT chains, because some of the
chain members are likely to be HEAPTUPLE_DEAD_CHAIN rather than plain
DEAD, and they're not coping.
regards,
Forgot to include this in the patch ...
I'm still unhappy about too much complexity for the VACUUM FULL case,
but some other issues have gone away.
regards, tom lane
$PostgreSQL$
Heap Only Tuples (HOT)
Introduction
The
tes
Is that repeatable? What sort of filesystem are you testing on?
(soft-mounted NFS by any chance?)
regards, tom lane
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
and see if it fixes it?
regards, tom lane
---(end of broadcast)---
TIP 6: explain analyze is your friend
gt; this causes downstream errors in signal handling.
> Um, this is a bug fix. Unless you had some problem with it?
I haven't reviewed that patch yet, but I concur we should consider it
for 8.3.
regards, tom lane
---(end of broadcast)--
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
> Oh, I see what you mean. Yeah, the absolute paths need to be fixed :).
Easier to just remove the regression test altogether. Not every patch
requires permanent memorialization in a regression test.
'm fairly unclear on what the design intention is for recovering from
the case where the last item(s) on a HOT chain are aborted. Please
clarify.
regards, tom lane
---(end of broadcast)---
TIP 3: Have you
"Pavan Deolasee" <[EMAIL PROTECTED]> writes:
> On 9/13/07, Tom Lane <[EMAIL PROTECTED]> wrote:
>> You have apparently
>> decided to redefine the WAL record format as using one-based rather than
>> zero-based item offsets, which would be fine if any of
ormat as using one-based rather than
zero-based item offsets, which would be fine if any of the rest of the
code had been changed to agree ...
regards, tom lane
---(end of broadcast)---
TIP 4: Have you searched our list archiv
"Pavan Deolasee" <[EMAIL PROTECTED]> writes:
> On 9/12/07, Tom Lane <[EMAIL PROTECTED]> wrote:
>> XXX doesn't the above completely break the anti-wraparound guarantees?
>> And why couldn't we avoid the problem by pruning the previous tuple,
>>
"Pavan Deolasee" <[EMAIL PROTECTED]> writes:
> On 9/12/07, Tom Lane <[EMAIL PROTECTED]> wrote:
>> XXX the above being the case, why should we bother with all this extra
>> mechanism? Seems we could dispense with "not ready for inserts".
> Witho
t = true;
Isn't that array subscript off-by-one? Probably better to put the test
inside unescape_single_char(), anyway.
Otherwise it looks sane, though maybe shy a comment or so.
regards, tom lane
---(end of broadcast)
"Florian G. Pflug" <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> This is wrong --- it will break early detection of aborted
>> subtransactions.
> I don't see how - TransactionIdIsInProgress doesn't even touch
> latestCompletedXid
regards, tom lane
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
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
at least inadequately described).
regards, tom lane
$PostgreSQL$
Heap Only Tuples (HOT)
Introduction
The Heap Only Tuple (HOT) feature eliminates redundant index entries and
allows the re-use of space taken by DELETEd or obsoleted
T
after beta starts, or that the attentions of beta testers will allow us
to collect data on variant implementations. Neither is the case.
regards, tom lane
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
ar-quoted strings nor in quoted identifiers.
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.
regards, tom lane
---(end of broadcast)---
TIP
"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
.
Adding an xmin field might or might not be a good solution, but to
complain about it on compatibility grounds is silly.
regards, tom lane
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
ve the page undetectably corrupted --- t_ctid
is 6 bytes and could easily cross a hardware sector boundary.
regards, tom lane
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
um-grade lock on the
page. Someone might be examining the root tuple (eg, in a SnapshotAny
scan) and I think they are entitled to assume that the line pointer
stays valid while they are looking at the tuple.
regards, tom lane
---
; sorted, we can get ride of the exclusive lock during subxact abort.
No, we can't, because subxact abort still has to advance latestCompletedXid.
regards, tom lane
---(end of broadcast)---
TIP 9: In versions below 8.0, th
when a READ COMMITTED
update realizes it's trying to update a non-latest version of a row.
regards, tom lane
---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at
http://www.postgresql.org/about/donate
e except the main "hole".
regards, tom lane
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
ely that that code
costs enough to be worth optimizing. When you think about the total
number of cycles that have been expended on each subtransaction
(especially one that has an xid), another comparison or two is lost in
the noise. As long as the code isn't O(N^2) ... which it isn't AF
that the chains would normally get very
long in the first place, if we could prune when updating.
The we-already-pinned-the-page problem is a bit nasty but may not be
insurmountable.
regards, tom lane
---(end of broadcast)---
TIP
ersal to the heap page), this is already an
enormous performance improvement. Insisting that we add complexity and
pay performance penalties elsewhere to reduce this cost still more does
not strike me as a sane tradeoff --- certainly not if it's being made
without conclusive p
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
>> ProcArra
le it seems at least as clean as the code we have now. Comments?
regards, tom lane
binVWXtBdczHT.bin
Description: latestCompletedXid.patch.gz
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
Simon Riggs <[EMAIL PROTECTED]> writes:
> On Thu, 2007-09-06 at 15:55 -0400, Tom Lane wrote:
>> This would have been painful to fix in 8.2 but it seems relatively
>> trivial in HEAD --- we just need another filter option in
>> GetCurrentVirtualXIDs.
> Patch enc
pruning involves only a single heap page I see no need for it to take
more than the buffer-level locks on that page.
regards, tom lane
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
se two things work. There
may be some other showstopper but I'm not sure what it would be.
regards, tom lane
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an ind
ould run...
or maybe this should be a third independent task within bgwriter?)
regards, tom lane
---(end of broadcast)---
TIP 6: explain analyze is your friend
intending to review/apply Heikki's tsearch fixes,
or do you want someone else to do it?
regards, tom lane
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I don't follow. HOT chains can only get longer by updates.
> Yes. We don't seem to be on the same wavelength...
> Imagine a page with just one tuple on it:
> 1
> After a bunc
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>>> Another real problem with doing pruning only in UPDATE path is that
>>> we may end up with long HOT chains if the page does not receive a
>>> UPDATE, after many consecutive HOT upda
Have you tested the impact of the patch on read-mostly workloads?
>> Another real problem with doing pruning only in UPDATE path is that
>> we may end up with long HOT chains if the page does not receive a
>> UPDATE, after many consecutive HOT updates.
How is th
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Uh, why would any of this code at all execute during a pure lookup?
> No idea. It seems an index lookup tries to prune a heap chain, and he
> was asking if it should look at other chains on the page; I said not.
mns that are usually useless.
Also, I still agree with Florian's earlier argument that we should
deliberately break any code that's depending on the transaction column.
Any such code is unlikely to be prepared for the column containing nulls.
regards, tom lane
--
h? What do you mean by "XID for relations that have been updated"?
Relations don't have XIDs.
regards, tom lane
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
probably other table modifications, but for an index lookup there isn't
> any knowledge of whether the table is being modified so looking at more
> than we need seems like overkill.
Uh, why would any of this code at all execute during a pure lookup?
regards, tom lane
it's doing.
Also, I didn't add the proposed regression test, as it seems much too
fragile --- concurrent autovacuum activity would make it fail, for
instance.
There are a couple of loose ends, which I'll post about separately
on -hackers.
reg
ualtransaction for the VXID. That will ensure that clients who
> *do* rely on pg_locks and the "transaction" column (which will be few,
> I guess) at least fail early and visibly, instead of producing bogus
> results...
Barring other objections, I'll d
it was wrong in that way?
regards, tom lane
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
breaking client code that thinks
that the transaction column is a unique key and isn't too wedded to the
assumption that the contents look like an integer. If it is so wedded,
it's most likely busted anyway by the possibility that the column is
null...
Comme
can't get attachments through to this list)
>>
> I haven't been able to follow the discussions here, but do I need to worry
> about its interaction with HOT ?
There will likely be some minor patch-merging problems, but AFAICT there
are no semantic con
es of looking through the ProcArray at
backend startup to ensure the sessionID we've chosen is unique, and
choosing another one if not. But this would expend cycles with the
ProcArray locked, for something that seems exceedingly unlikely to
happen,
regards, tom
"Florian G. Pflug" <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> "Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
>>> Should there be new a log_line_prefix percent code for virtual
>>> transaction ids? Or should we change the meaning
M before xid wrap-around?
Yeah. I think xid_age is really just a historical curiosity anyway as
of 8.2 --- there's hardly any real use-case for it.
regards, tom lane
---(end of broadcast)---
TIP 6: explain analyze is your friend
Rather than moving all that up to tuplesort_performsort, it seems better
to leave it where it is, and instead remove the premature optimization
of trying to skip sort_bounded_heap. The number of cycles saved that
way is tiny anyway...
regards, tom lane
---
ady is, which is why it works at all.)
Setting it at conclusion is correct, I think, since if we ever changed
the code to abandon TSS_BOUNDED state in the face of unexpected memory
growth, it would be wrong to have set it in make_bounded_sort.
regards, tom lane
#x27;t work, period. I'm not in favor of treating the
catalogs differently.
regards, tom lane
---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at
http://www.postgresql.org/about/donate
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Here's a patch (minus catalog bump) which I think does that.
Looks sane in a very quick once-over, but I didn't test it.
regards, tom lane
---(end of broadcast)---
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Tom Lane escribió:
>> Not if someone else releases lock before committing.
> FWIW, a red flag raised for me here, though maybe it is irrelevant or
> unimportant. Currently, VACUUM acquires an exclusive lock for
> truncating
r a regular CREATE INDEX, and in that case there's no cumulative
waiting effect because no new conflicting transactions are coming in.
C.I.C. should be able to fix things up in its second pass instead of
waiting during the first one.
regards, tom lane
---
"Pavan Deolasee" <[EMAIL PROTECTED]> writes:
> On 8/30/07, Tom Lane <[EMAIL PROTECTED]> wrote:
>> I don't think that works --- what if the last tuple in the chain isn't
>> committed good yet? If its inserter ultimately rolls back, you've
>&g
> requires exclusive lock whereas repairing fragmentation requires
> cleanup lock.
This is nonsense. Those are the same lock. If you have the former and
not the latter, it just means that you *know* there is contention for
the page. It seems to me that performing optional maintenance work in
su
terested in using the page. Eliminating the separation between that
and cleanup would also allow eliminating the separate "PD_FRAGMENTED"
page state.
PlanSetValidForThisTransaction is completely bogus --- it's not
re-entrant, and it needs to be. I think you need so
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
> Ok, here's an updated version of the patch.
Applied, with a few trivial additional cleanups I noticed while reading
the patch. I included your HeadlineText de-duplication too.
us to rename the standard Snowball
dictionaries to "english_stem" etc, so I'll make that happen too.
regards, tom lane
---(end of broadcast)---
TIP 6: explain analyze is your friend
"Marko Kreen" <[EMAIL PROTECTED]> writes:
> The fix should be in combo_decrypt() because other code
> should not need to guess whether zero-length input is
> allowed or not.
> Patch attached.
Thanks -- applied in all branches back to 7.3.
which
seemed to me like a saner division of labor. That is, UTF8 is a policy
that we want to enforce globally, but lowercasing maybe not, and this
still leaves the door open for more processing besides lowercasing.
Oleg, Teodor, what do you think about this?
Julius Stroffek <[EMAIL PROTECTED]> writes:
> pgbench contrib module is doing segmentation fault on Solaris
> when -d option is specified without -p option specified.
Applied in HEAD and 8.2. Thanks for the report!
regards, tom lane
--
patch as an attachment next time. Fortunately
it's a small enough patch to apply by hand, and I've done that.
Thanks for the report and fix!
regards, tom lane
---(end of broadcast)---
TIP 5: don't forget to i
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> I see that you have a separate bitmapset to keep track of indexes on
> system attributes. But having an index on a system attribute doesn't
> make any sense, does it?
Counterexample: OID.
Gregory Stark <[EMAIL PROTECTED]> writes:
> "Tom Lane" <[EMAIL PROTECTED]> writes:
>> BTW, I would like to shorten some of the path names in this fileset.
>> Is there a reason not to combine src/backend/utils/adt/tsearch,
>> src/backend/utils/tsearch
haps src/backend/tsearch?
regards, tom lane
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
utor's
range table when it's told to fire triggers for tables that aren't
already listed there. That's getting a bit hairy for a back-patchable
fix though. I'm thinking of trying that in HEAD but applying this
pat
Pavel Ajtkulov <[EMAIL PROTECTED]> writes:
> Tom Lane writes:
>> Moreover, you'd lose the guarantee of not-worse-than-linear time,
>> because hash lookup can be pathologically bad if you get a lot of hash
>> collisions.
> compute max_wchar, min_wchar. If (
about every
use of Size in freespace.h. I'm unconvinced that we need to change it,
but if we do, the patch needs to be a lot bigger.
regards, tom lane
---(end of broadcast)---
TIP 7: You can help support the PostgreSQL
"Brendan Jurd" <[EMAIL PROTECTED]> writes:
> New (context) diff attached. The actual change is in
> config/docbook.m4, not configure.in.
Much better. Committed in HEAD and REL8_2 (I suppose Gentoo weenies
won't be interested in anything older ;-))
Pavel Ajtkulov <[EMAIL PROTECTED]> writes:
> Tom Lane writes:
>> The difficulty with B-M is the need for a table indexed by character
>> code, which at first glance looks impractical for wchars. But it seems
>> to me that we could use "wchar % 256" as the tab
256" as the table index, meaning that
wchars with the same trailing byte share the same table entry. That
would lose some efficiency compared to an exact implementation, but the
limited table size would outweigh that except in the most pathological
cases.
regards, tom la
"4 * level" spaces, where "level" is the depth of
> the node within the subtree printed by MemoryContextStats().
Seems reasonable except I'd vote for less indentation --- the lines are
too long already. How do you feel about 1 or 2 spaces per lev
t noticed any major leaks from other places
that might have the same problem.
regards, tom lane
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
resetting the parent (since we'd not bother explicitly releasing
the child headers). But that would be a pain to undo if it turned out
wrong.
Anyone want to investigate what happens if we make MemoryContextReset
the same as MemoryContextResetAndDeleteChildren?
ination that forbids
setting the CSV bit unless Redirect_stderr is set, but the trouble with
that is that it's making unsupportable assumptions about the order in
which the GUC variables will be set.
regards, tom lane
---(end of broadcast)-
"Chad Wagner" <[EMAIL PROTECTED]> writes:
> On 8/5/07, Tom Lane <[EMAIL PROTECTED]> wrote:
>> If we're trying to defend against premature EOF, this hardly seems like
>> a sufficient patch.
> I agree, but it is better than nothing. If you have some s
seems like
a sufficient patch.
regards, tom lane
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
), I tend to agree that having the
compressor reject input a-priori might be a bad idea. Needs testing.
regards, tom lane
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-
the 256 byte minimum.
To be blunt, the solution to problems like that is sending the DBA to a
re-education camp. I don't think we should invest huge amounts of
effort on something that's trivially fixed by using the correct datatype
instead of the wrong datatype.
ftime formats for Windows,
as we did in several places already.
Comments?
regards, tom lane
binQH88Ti2QXM.bin
Description: log_timezone_1.patch.gz
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
ine log_timezone too, if they don't override it in
postgresql.conf.
regards, tom lane
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Tom's idea of a log_timezone seems to make sense.
I'll code that up and see if there are any unexpected gotchas.
regards, tom lane
---(end of broadcast)
local-time logging.
regards, tom lane
---(end of broadcast)---
TIP 6: explain analyze is your friend
Gregory Stark <[EMAIL PROTECTED]> writes:
> "Tom Lane" <[EMAIL PROTECTED]> writes:
>> I don't think it's an acceptable change in either place. People who
>> want to see UTC in their logs can start the postmaster in UTC. Those
>> who are acc
hink it's an acceptable change in either place. People who
want to see UTC in their logs can start the postmaster in UTC. Those
who are accustomed to seeing local time will squawk.
regards, tom lane
---(end of broadcast)
bout the speed of those functions (at least not since
we changed the original O(N^2) method :-().
regards, tom lane
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
uld be neater. Notable was that the patch
would have significantly increased the contention for CLogControlLock by
requiring two lock cycles to fetch a transaction's commit status and
LSN. I changed it so that TransactionIdGetStatus returns both pieces
of information.
ie, don't use %Z at all under Windows.
regards, tom lane
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
Ferruccio Zamuner <[EMAIL PROTECTED]> writes:
> [ patch with no documentation ]
I can hardly believe that it's a good idea to include search_path in
every log entry --- it'd be unreasonably bulky, not to mention impossible
to parse by automatic tools.
Gregory Stark <[EMAIL PROTECTED]> writes:
> "Tom Lane" <[EMAIL PROTECTED]> writes:
>> You're presuming there exists a linear scalar space to reference the
>> results to.
> I was planning to use the first and last histogram values for the frame of
&
Gregory Stark <[EMAIL PROTECTED]> writes:
> "Tom Lane" <[EMAIL PROTECTED]> writes:
>> How so? The entries in the histogram are equidistant by definition.
> Huh? They have equal number of values between them, they're not equidistant in
> the scalar sp
Gregory Stark <[EMAIL PROTECTED]> writes:
> "Tom Lane" <[EMAIL PROTECTED]> writes:
>> When complaining I hadn't read the pghackers thread in which you
>> suggested this, and now that I'm caught up on email I remain
>> unconvinced. What do you
Gregory Stark <[EMAIL PROTECTED]> writes:
> "Tom Lane" <[EMAIL PROTECTED]> writes:
>> Gregory Stark <[EMAIL PROTECTED]> writes:
>>> Attached is a patch which implements, as discussed briefly on -hackers, a
>.> user-visible function to get
he
statement it describes. How readable will this code be to the next
person? Far better to expend an additional #ifdef/#endif pair, if
needed, to put the call either by itself or with some code that it's
sensibly related to. Being "WIN32" is not sufficient connecti
ons to use it
The way to not encourage it is to not provide it.
regards, tom lane
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
Stephen Frost <[EMAIL PROTECTED]> writes:
> Please find attached a minor patch to remove the constraints that a
> user can't include the delimiter or quote characters in a 'NULL AS'
> string when importing CSV files.
This can't really be sane can it?
here aren't that many of the commonly used DDL commands that
> could be performed and still have it be an async commit.
Huh? I see neither a reason for these restrictions nor any way that you
could enforce them without horrid kluges.
regards, tom lane
701 - 800 of 4175 matches
Mail list logo
