Bruce Momjian wrote:
Have you looked at the 8.1.X buildin function pg_column_size()?
Thanks Bruce for the lead. I didn't know what to grep for; this helps.
The header comment for that function says
"Return the size of a datum, possibly compressed"
I take it the uncompressed length i
It looks like pg_column_size gives you the actual size on disk, ie after
compression.
What looks interesting for you would be byteaoctetlen or the function it
wraps, toast_raw_datum_size. See src/backend/access/heap/tuptoaster.c.
pg_column_size calls toast_datum_size, while byteaoctetlen/textocte
Have you looked at the 8.1.X buildin function pg_column_size()?
---
Mark Dilger wrote:
> Hello, could anyone tell me, for a user contributed variable length data
> type,
> how can you access the length of the data without
Hello, could anyone tell me, for a user contributed variable length data type,
how can you access the length of the data without pulling the entire thing from
disk? Is there a function or macro for this?
As a first cut, I tried using the PG_DETOAST_DATUM_SLICE macro, but to no avail.
grep'in
Ron wrote:
Subject line says it all. I'm going to be testing changes under both
Linux and WinXP, so I'm hoping those of you that do M$ hacking will pass
along your list of suggestions and/or favorite (and hated so I know what
to avoid) tools.
Testing only? So you really only need to build
On 2/10/06, Ron <[EMAIL PROTECTED]> wrote:
> Subject line says it all. I'm going to be testing changes under both
> Linux and WinXP, so I'm hoping those of you that do M$ hacking will
> pass along your list of suggestions and/or favorite (and hated so I
> know what to avoid) tools.
If you mean ha
Tom Lane wrote:
> Bruce Momjian writes:
> > Tom Lane wrote:
> >> It's much better to just copy the result file over the expected file
> >> once you've decided it's OK. The regression.diff file is inexact
> >> because of the diff switches that are used.
>
> > I am confused. patch dosen't make an
IMHO null values shouldn't verify foreign keys constraints...
Gustavo.
2006/2/10, ohp@pyrenet.fr :
> Many thanks for explaining.
> I learned something today...
>
> On Fri, 10 Feb 2006, Stephan Szabo wrote:
>
> > Date: Fri, 10 Feb 2006 08:59:51 -0800 (PST)
> > From: Stephan Szabo <[EMAIL PROTECTED
Bruce Momjian writes:
> Tom Lane wrote:
>> It's much better to just copy the result file over the expected file
>> once you've decided it's OK. The regression.diff file is inexact
>> because of the diff switches that are used.
> I am confused. patch dosen't make an indentical file? Example?
N
* Tom Lane ([EMAIL PROTECTED]) wrote:
> Enable pg_ctl to give up admin privileges when starting the server under
> Windows (if newer than NT4, else works same as before).
I don't suppose we could consider doing this for Unix-based systems too?
I think it'd certainly be nice. It's also how quite a
Tom Lane wrote:
> Bruce Momjian writes:
> > Oh, what I normally do is to look at regression.diff, and if that looks
> > OK, I just apply it to the expected file like this:
>
> > cd expected
> > patch < ../regression.diff
>
> Oh, that explains a few things ...
>
> It's much better to jus
On Fri, 2006-02-10 at 14:04 -0500, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > Not everybody gets the chance to change the SQL in an application
> > program, however much they might want to and know they should. Third
> > party software is most software.
>
> Right. You are propo
Martijn van Oosterhout writes:
> The extra spaces is an interesting side-effect. In the past it would
> only have worked for the last column anyway, right?
Of course.
> Anyway, it is a fixable issue and I'd consider doing it if people think
> it's worth it.
I think it would be a good idea to ex
Martijn van Oosterhout wrote:
On Fri, Feb 10, 2006 at 08:06:53PM +0100, Michael Paesold wrote:
> A side affect of this newline patch is that all fields are now filled
> with
> white space up to the displayed column width, even for the last (or only
> column).
My intention was to only change f
Many thanks for explaining.
I learned something today...
On Fri, 10 Feb 2006, Stephan Szabo wrote:
> Date: Fri, 10 Feb 2006 08:59:51 -0800 (PST)
> From: Stephan Szabo <[EMAIL PROTECTED]>
> To: ohp@pyrenet.fr
> Cc: pgsql-hackers list
> Subject: Re: [HACKERS] how is that possible
>
>
> On Fri, 10
On Fri, Feb 10, 2006 at 08:06:53PM +0100, Michael Paesold wrote:
> A side affect of this newline patch is that all fields are now filled with
> white space up to the displayed column width, even for the last (or only
> column). I guess this is somehow required for consistent display.
> Otherwise
Subject line says it all. I'm going to be testing changes under both
Linux and WinXP, so I'm hoping those of you that do M$ hacking will
pass along your list of suggestions and/or favorite (and hated so I
know what to avoid) tools.
TiA,
Ron
---(end of broadcast)
On Fri, 2006-02-10 at 19:14 +0100, Martijn van Oosterhout wrote:
> On Fri, Feb 10, 2006 at 04:48:42PM +, Simon Riggs wrote:
> > If a cursor is defined NO SCROLL, which is the SQL Standard implicit
> > default, then we are safe to assume there will be no rewinds or backward
> > scans. The Postgr
Greg Stark <[EMAIL PROTECTED]> writes:
> That's why merely allocating tons of swap doesn't necessarily protect you.
> It's still possible for a process (or several processes if you allocate more
> swap than you have address space) to mmap gigabytes of memory without touching
> it and then start tou
But why do they need access to the files in the file system? Why not
put them on the local box but don't give them permissions to edit the
pg_hba file? They should still be able to connect.
On Feb 9, 2006, at 5:56 PM, Q Beukes wrote:
I did consider that, but the software we use (which agai
Bruce Momjian wrote:
The failure, I think, it because of the newline patch we got for psql
yesterday. I am seeking a diff from pgcrypto to fix it. My openssl is
too old.
A side affect of this newline patch is that all fields are now filled with
white space up to the displayed column width
Simon Riggs <[EMAIL PROTECTED]> writes:
> Not everybody gets the chance to change the SQL in an application
> program, however much they might want to and know they should. Third
> party software is most software.
Right. You are proposing to *break* some applications in order to
make other ones f
On Fri, Feb 10, 2006 at 04:48:42PM +, Simon Riggs wrote:
> If a cursor is defined NO SCROLL, which is the SQL Standard implicit
> default, then we are safe to assume there will be no rewinds or backward
> scans. The PostgreSQL current implicit default is SCROLL, which means
> that no part of th
Martijn van Oosterhout writes:
> Disabling overcommit has a serious cost in that most of your VM will
> never be used. Are people really suggesting that I can't run a few
> daemons, X and a web-browser on FreeBSD without allocating 3 times my
> physical memory in swap?
There's a possibility you
On Fri, 2006-02-10 at 11:58 -0500, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > On Fri, 2006-02-10 at 10:13 -0500, Tom Lane wrote:
> >> The merge step would certainly have to happen anyway, so this claim is
> >> not justified. You have not presented any evidence about how much of
Martijn van Oosterhout writes:
> Disclaimer: The Linux OOM killer has never killed the wrong process for
> me, so I don't have any bad experiences with overcommit.
You haven't tried real hard. What I've seen recently when I do something
that makes a PG backend go overboard is that the kernel zap
Bruce Momjian writes:
> Oh, what I normally do is to look at regression.diff, and if that looks
> OK, I just apply it to the expected file like this:
> cd expected
> patch < ../regression.diff
Oh, that explains a few things ...
It's much better to just copy the result file over the
On Fri, 10 Feb 2006 ohp@pyrenet.fr wrote:
> My understanding is that null or not, their should have been a foreign key
> violation.
Not as far as I can tell. MATCH (without partial or full) returns true if
any column in the row value constructor is NULL. MATCH FULL returns true
if all columns in
Simon Riggs <[EMAIL PROTECTED]> writes:
> On Fri, 2006-02-10 at 10:13 -0500, Tom Lane wrote:
>> The merge step would certainly have to happen anyway, so this claim is
>> not justified. You have not presented any evidence about how much of
>> the reported time is actually I/O related.
> You are ri
> On Fri, Feb 10, 2006 at 09:57:12AM -0500, Mark Woodward wrote:
>> > In most practical situations, I think
>> > exceeding work_mem is really the best solution, as long as it's not
>> > by more than 10x or 100x. It's when the estimate is off by many
>> > orders of magnitude that you've got a probl
On Fri, 2006-02-10 at 10:22 -0600, Jim C. Nasby wrote:
> On Fri, Feb 10, 2006 at 01:32:44PM +, Simon Riggs wrote:
> > I intend to add a short patch to pass down the cursor state during
> > planning, so that when it is explicitly specified the sort node is able
> > to recognise this and avoid wo
On Fri, Feb 10, 2006 at 10:01:18AM -0600, Jim C. Nasby wrote:
> BTW, I was shocked when I found out that FreeBSD actually has an OOM
> killer itself. Yet I've never heard of anyone having problems with it.
> Granted, the FreeBSD OOM could be better designed to pick the right
> process to kill, but
Kevin Grittner wrote:
> >>> On Thu, Feb 9, 2006 at 10:31 pm, in message
> <[EMAIL PROTECTED]>, Bruce Momjian
> wrote:
> >
> > OK, I got it working. The fix is to add GUC_REPORT to guc.c for
> > standard_conforming_strings. See the same flag on
> > session_authorization. That will cause libpq
On Fri, Feb 10, 2006 at 01:32:44PM +, Simon Riggs wrote:
> I intend to add a short patch to pass down the cursor state during
> planning, so that when it is explicitly specified the sort node is able
> to recognise this and avoid work. Also, to add a GUC to force the
> not-explicitly-specified
On Fri, 2006-02-10 at 10:13 -0500, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > Which shows that the *unnecessary* final merge takes 344 secs, adding
> > approximately 60% to the elapsed time of the query and nearly doubling
> > the CPU requirement.
>
> The merge step would certai
On Fri, Feb 10, 2006 at 09:57:12AM -0500, Mark Woodward wrote:
> > In most practical situations, I think
> > exceeding work_mem is really the best solution, as long as it's not
> > by more than 10x or 100x. It's when the estimate is off by many
> > orders of magnitude that you've got a problem. R
On Thu, Feb 09, 2006 at 05:04:38PM -0500, Tom Lane wrote:
> Martijn van Oosterhout writes:
> > When people talk about disabling the OOM killer, it doesn't stop the
> > SIGKILL behaviour,
>
> Yes it does, because the situation will never arise.
>
> > it just causes the kernel to return -ENOMEM fo
On Thu, Feb 09, 2006 at 03:13:22PM -0500, Greg Stark wrote:
> Stephen Frost <[EMAIL PROTECTED]> writes:
>
> > * Tom Lane ([EMAIL PROTECTED]) wrote:
> > > Greg Stark <[EMAIL PROTECTED]> writes:
> > > > It doesn't seem like a bad idea to have a max_memory parameter that if a
> > > > backend ever exc
The failure, I think, it because of the newline patch we got for psql
yesterday. I am seeking a diff from pgcrypto to fix it. My openssl is
too old.
---
Dave Page wrote:
>
>
> > -Original Message-
> > From: Mark
>>> On Thu, Feb 9, 2006 at 10:31 pm, in message
<[EMAIL PROTECTED]>, Bruce Momjian
wrote:
>
> OK, I got it working. The fix is to add GUC_REPORT to guc.c for
> standard_conforming_strings. See the same flag on
> session_authorization. That will cause libpq to see any changes made
to
> that va
My understanding is that null or not, their should have been a foreign key
violation.
Maybe I misunderstood.
On Fri, 10 Feb 2006, Stephan Szabo wrote:
> Date: Fri, 10 Feb 2006 06:48:02 -0800 (PST)
> From: Stephan Szabo <[EMAIL PROTECTED]>
> To: ohp@pyrenet.fr
> Cc: pgsql-hackers list
> Subject:
> -Original Message-
> From: Marko Kreen [mailto:[EMAIL PROTECTED]
> Sent: 10 February 2006 15:07
> To: Dave Page
> Cc: pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] FW: PGBuildfarm member snake Branch
> HEAD Status changed from OK to ContribCheck failure
>
> On 2/10/06, Dave
Simon Riggs <[EMAIL PROTECTED]> writes:
> Which shows that the *unnecessary* final merge takes 344 secs, adding
> approximately 60% to the elapsed time of the query and nearly doubling
> the CPU requirement.
The merge step would certainly have to happen anyway, so this claim is
not justified. You
On 2/10/06, Marko Kreen <[EMAIL PROTECTED]> wrote:
> On 2/10/06, Dave Page wrote:
> > Something broke snake again :-(. Looks like tsearch2 through the haze of
> > my Lemsip... I hate winter :-(
>
> AFAIR the reason for different length of psql's '' header lines
> was database encoding being U
On 2/10/06, Dave Page wrote:
> Something broke snake again :-(. Looks like tsearch2 through the haze of
> my Lemsip... I hate winter :-(
AFAIR the reason for different length of psql's '' header lines
was database encoding being UNICODE not SQL_ASCII. Can this be the case
there?
--
marko
On Fri, 10 Feb 2006 ohp@pyrenet.fr wrote:
> After a typo, I've just noticed the following :
>
> ~ 14:58:33: createdb test
> CREATE DATABASE
> ~ 14:58:42: psql test
> Welcome to psql 8.1.2, the PostgreSQL interactive terminal.
>
> Type: \copyright for distribution terms
>\h for help with
ohp@pyrenet.fr wrote:
> test=# create table t1 (i int primary key);
> NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index "t1_pkey" for
> table "t1"
> CREATE TABLE
> test=# create table t2 (i int references t2 1 on deley te cascade on
> update cascade
> );
The t2.i column is null
After a typo, I've just noticed the following :
~ 14:58:33: createdb test
CREATE DATABASE
~ 14:58:42: psql test
Welcome to psql 8.1.2, the PostgreSQL interactive terminal.
Type: \copyright for distribution terms
\h for help with SQL commands
\? for help with psql commands
\g
> Rick Gigger <[EMAIL PROTECTED]> writes:
>> However if hashagg truly does not obey the limit that is supposed to
>> be imposed by work_mem then it really ought to be documented. Is
>> there a misunderstanding here and it really does obey it? Or is
>> hashagg an exception but the other work_mem a
Are you using pgxs + gmake? That's the best way to set up a UDF. We
recently made changes to ensure that pgxs works on Windows, and several
people have used it.
This could easily blow up on you: -I"C:/Dev-Cpp/include" - why do you
need to use the IDE's include files?
If you really need an
I did consider that, but the software we use (which again uses postgresql)
atm only supports local connection to the database.
I am the database admin, the other admins just manage stuff like user
accounts,
checking logs, etc...
Unfortunately there is no other way to set it up, and like I mention
I'm interested in the behaviour of ExecSort, which *for all queries*
prepares the sort result for randomAccess, even when part of a plan that
will *never* go backwards/rewind etc.
A recent performance test shows this output from mid-way through a heap
sort with trace_sort=on (the query itself is
hm, I'm still stuck: can't compile extension with mingw compiler.
I use Dev-CPP IDE (4.9.9.2) with MingW 3.7. Has it been tested to compile
extensions under XP with PostgresQL 8.1.2 ?
Al I get are compiler errors:
gcc.exe -c fd.c -o fd.o -I"C:/Dev-Cpp/include"
-I"D:/.Work/postgresql/postgresql
***
*** 2463,2469
http://www.google.com/foo.bar.html"; target="_blank">YES
ff-bg
! document.write(15);
--- 2463,2469
http://www.google.com/foo.bar.html"; target="_blank">YES
ff-bg
! \x09document.write(15);
\x09 is a '\t'.
On 2/9/06, Tom Lane <[EMAIL PROTECTED]> wrote:
> Andrew Dunstan <[EMAIL PROTECTED]> writes:
> > Maybe this should be a configure flag, just like the port number is.
>
> It is ... that isn't the issue, the problem is exactly that Debian
> chooses to exercise the option to make their installations di
On Feb 10, 2006, at 17:24 , Dave Page wrote:
Something broke snake again :-(. Looks like tsearch2 through the
haze of
my Lemsip... I hate winter :-(
Hope you feel better soon! I've been taking 1500 to 2000mg of vitamin
C daily to try to stay healthy.
As for snake, I can't offer much.
M
Something broke snake again :-(. Looks like tsearch2 through the haze of
my Lemsip... I hate winter :-(
/D
> -Original Message-
> From: PG Build Farm
> [mailto:[EMAIL PROTECTED]
> Sent: 10 February 2006 02:20
> To: [EMAIL PROTECTED];
> [EMAIL PROTECTED]
> Subject: PGBuildfarm member
57 matches
Mail list logo
