On Fri, 2007-03-09 at 18:00 -0500, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
On Fri, 2007-03-09 at 16:40 -0500, Tom Lane wrote:
I wonder whether this has any implications for HOT ...
My general feeling, expressed in a number of recent posts was that the
VACUUM FULL code
Edward Stanley wrote:
Was wondering if people would mind having a read over what I plan to do for my
undergraduate honours project - you can get the proposal here:
http://www.mcs.vuw.ac.nz/~eddie/489_Proposal.pdf
ISTM that what you're calling dynamically attached properties are
generally
Simon Riggs [EMAIL PROTECTED] writes:
COPY command now also uses this hint, to allow test results and
discussion. Others could also, perhaps needing different values.
Hm. It occurs to me that different commands may want different size buffer
rings.
As I understand it the reason your buffer
So to implement recursive queries I think what we need is a memoizing node
like Materialize which allows multiple simultaneous readers.
Looking into how to implement this I find that the read position of a
Materialize node is actually implemented directly in tuplestore.c.
That means that
On 3/10/07, Tom Lane [EMAIL PROTECTED] wrote:
I've been banging away on this since yesterday, and I think I've
achieved a full understanding of what's going on. There are three or
four different-looking pathologies but they all seem to arise from
the same problem: the update-chain-moving code
On 3/10/07, Tom Lane [EMAIL PROTECTED] wrote:
Also, we know this case works because it already is working: in the
situation where VACUUM happens to visit and remove the DEAD tuple(s)
before reaching the RECENTLY_DEAD tuples that link forward to them,
it treats the RECENTLY_DEAD tuples as a
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Magnus Hagander wrote:
I wonder if this is a line-end issue? Assuming you are working from CVS,
does your client turn \n into \r\n ?
I have just run into this today while trying to get buildfarm working
for MSVC. After some
On Sat, 2007-03-10 at 09:42 +, Gregory Stark wrote:
Simon Riggs [EMAIL PROTECTED] writes:
COPY command now also uses this hint, to allow test results and
discussion. Others could also, perhaps needing different values.
Hm. It occurs to me that different commands may want different
I'm occasionally seeing calls to pg_database_size() fail with
ERROR: could not stat file /var/lib/pgsql/data/base/16404/1738343: No such
file or directory
So far I haven't noticed any other problems that might be related
to this error. This database frequently uses temporary tables so
I'm
Hello
I am working on backport plpgpsm to 8.1. This interpret is based on plpgsql
8.2. There is some strange. Where I do rollback transaction, then on 8.1
postgresql go down on segfault. 8.2 and 8.3 works well.
I don't see any important difference, why 8.1. have to down.
#0 0x081564f1 in
Pavan Deolasee [EMAIL PROTECTED] writes:
In general, I believe that the most likely cause for earlier reported
errors is that we are failing to clean up one or more index entries
in VACUUM FULL, thus causing all sorts of errors. I had a hard
time fixing this case for HOT.
Yeah, the case I
Michael Fuhr [EMAIL PROTECTED] writes:
I'm wondering if the code should check for ENOENT if stat() fails
and either skip this entry silently under the assumption that the
file had been deleted since the call to ReadDir(),
Probably. Want to look through the rest of that module for similar
Pavel Stehule [EMAIL PROTECTED] writes:
I don't see any important difference, why 8.1. have to down.
I dunno, but gdb is doing you no favors with such a silly backtrace.
It sorta looks like you have some files built with -g and some without
... or perhaps you are trying to gdb the core file
On 3/10/07, Tom Lane [EMAIL PROTECTED] wrote:
Although this shouldn't happen anymore after fixing the chaining
conditions, I'm inclined to introduce an additional test to verify that
the starting tuple is actually MOVED_OFF after we finish the chain move.
If not, give up on repair_frag the
On 3/10/07, Pavan Deolasee [EMAIL PROTECTED] wrote:
scan_heap() would usually have collected the DEAD tuple in offsets_free
list. How do you plan to check if the tuple is in middle on a chain which
has
RECENTLY_DEAD tuple before the tuple under check ? Don't we need
to collect the TID of the
Tom Lane [EMAIL PROTECTED] writes:
[ raised eyebrow... ] You sure about that? If you replace an XID
before OldestXmin with one after, or vice versa, ISTM you *could*
be creating a problem. Committed is not good enough. So it looks
to me like you can't remove a DEAD tuple whose predecessor
Pavel Stehule [EMAIL PROTECTED] writes:
I don't see any important difference, why 8.1. have to down.
I dunno, but gdb is doing you no favors with such a silly backtrace.
It sorta looks like you have some files built with -g and some without
... or perhaps you are trying to gdb the core file
Pavel Stehule wrote:
propably I had to do some errors. Next cycle produce different output:
#0 FreeExecutorState (estate=0x966eb2c) at execUtils.c:260
260 FreeExprContext((ExprContext *)
linitial(estate-es_exprcontexts));
(gdb) bt
#0 FreeExecutorState
Alvaro Herrera [EMAIL PROTECTED] writes:
Pavel Stehule wrote:
#1 0x00528c9c in plpgpsm_xact_cb () from /usr/local/pgsql81/lib/plpgpsm.so
#2 0x080b0d81 in CallXactCallbacks (event=XACT_EVENT_COMMIT) at xact.c:2618
Hmm, ISTR there were some changes to what plpgsql_xact_cb did in 8.1 ...
did
Specifically I think you need to study this patch:
http://archives.postgresql.org/pgsql-committers/2007-01/msg00370.php
But isn't back-porting plpgpsm to old releases a waste of development
and maintenance effort anyway?
I unlike it and last weak I play with it. But I don't expect so Debian
On Sat, Mar 10, 2007 at 12:32:04PM -0500, Tom Lane wrote:
Michael Fuhr [EMAIL PROTECTED] writes:
I'm wondering if the code should check for ENOENT if stat() fails
and either skip this entry silently under the assumption that the
file had been deleted since the call to ReadDir(),
Michael Fuhr [EMAIL PROTECTED] writes:
I'll submit a patch -- any preferences for silent continuation vs.
continuation with a notice or warning?
I think silent is fine for ENOENT cases. We know the file had been
there at ReadDir time, so the only possible conclusion is that it was
just
20070310:
Shared Buffers Elapsed vmstat IO rate
-- --- --
400MB 101 s122 MB/s
128KB79 s155 MB/s [1]
Now apply cycle scan v2:
Shared Buffers Scan_recycle_buffers Elapsed vmstat IO rate
Why don't we have some kind of error check for people entering things
like INTERVAL '1' DAY in their query, since we don't handle it.
select now() =now() + interval '1' day;
?column?
--
T
This seems scary... We allow something through and then ignore it?
Interval '1 day'
Chuck McDevitt [EMAIL PROTECTED] writes:
Why don't we have some kind of error check for people entering things
like INTERVAL '1' DAY in their query, since we don't handle it.
Because it's not an error. It just doesn't mean what you think it means.
You've requested an interval measured in
Gregory Stark [EMAIL PROTECTED] writes:
Chuck McDevitt [EMAIL PROTECTED] writes:
Why don't we have some kind of error check for people entering things
like INTERVAL '1' DAY in their query, since we don't handle it.
Because it's not an error. It just doesn't mean what you think it means.
Gregory Stark [EMAIL PROTECTED] writes:
Chuck McDevitt [EMAIL PROTECTED] writes:
Why don't we have some kind of error check for people entering things
like INTERVAL '1' DAY in their query, since we don't handle it.
Because it's not an error. It just doesn't mean what you think it means.
Ok...
Just to be clear, the ISO SQL spec says that INTERVAL '1' DAY is the
correct way to specify a one-day interval.
That's why it is surprising that PostgreSQL treats it differently, with
no error or warning.
The PostgreSQL syntax INTERVAL '1 DAY' is non-standard.
Is fixing this on the TODO
Chuck McDevitt [EMAIL PROTECTED] writes:
Is fixing this on the TODO list?
See the 'Add ISO INTERVAL handling' entry.
regards, tom lane
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
On Sat, 10 Mar 2007, Chuck McDevitt wrote:
Ok...
Just to be clear, the ISO SQL spec says that INTERVAL '1' DAY is the
correct way to specify a one-day interval.
That's why it is surprising that PostgreSQL treats it differently, with
no error or warning.
The PostgreSQL syntax INTERVAL '1
On Sat, Mar 10, 2007 at 05:39:37PM -0500, Tom Lane wrote:
Michael Fuhr [EMAIL PROTECTED] writes:
I'll submit a patch -- any preferences for silent continuation vs.
continuation with a notice or warning?
I think silent is fine for ENOENT cases. We know the file had been
there at ReadDir
Michael Fuhr wrote:
On Sat, Mar 10, 2007 at 05:39:37PM -0500, Tom Lane wrote:
Michael Fuhr [EMAIL PROTECTED] writes:
I'll submit a patch -- any preferences for silent continuation vs.
continuation with a notice or warning?
I think silent is fine for ENOENT cases. We know the file
I wrote:
=?ISO-8859-1?Q?R=E9mi_Zara?= [EMAIL PROTECTED] writes:
(gdb) info locals
block = 0x4395000
chunk = 0x4395010
priorfree = 0x5395020
chunk_size = 16777216
blksize = 70864912
(gdb) p *block
$5 = {aset = 0x306d10, next = 0x0, freeptr = 0x5395020 Address 0x5395020
out of bounds,
33 matches
Mail list logo
