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 > out of bounds>, en
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 kn
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
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 INTER
"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?
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 l
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
"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 th
"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
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'
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 unli
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(),
>
not scan resistant"
> thread:
>
> Firstly vanilla 8.3 from 20070310:
>
> Shared Buffers Elapsed vmstat IO rate
> -- --- --
> 400MB 101 s122 MB/s
> 128KB79 s155 MB/s [1]
>
> Now apply cy
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 a
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 ..
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 (estate
"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 fi
"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 pr
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
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 sa
"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
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
"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 ca
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 Al
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 wo
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 d
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 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 di
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 cod
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 tuples
"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 buf
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 c
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
33 matches
Mail list logo
