On 4/17/07, Tom Lane [EMAIL PROTECTED] wrote:
Florian Pflug [EMAIL PROTECTED] writes:
Tom Lane wrote:
The current documentation for RESET exhibits a certain lack of, um,
intellectual cohesiveness:
What about
RESET parameter
RESET { PLANS | TEMP | TEMPORARY }
RESET ALL { PARAMETERS |
Hi there
I made some changes in postgresql source code to let the table function work in
iteration fashion rather than materialization fashion. My main modifications
are in 'exec_simple_query' function, I changed 'portalRunSelect' to return just
one tuple instead of 'FETCH_ALL'. I made other
Islam Hegazy [EMAIL PROTECTED] writes:
My question is how to inform the client that there is a tuple to display =
and return back to the backend to continue the query execution?
I'd suggest you start by reading
http://developer.postgresql.org/pgdocs/postgres/protocol.html
and then develop a
Chris Browne wrote:
This strikes me as being a really super thing, having both Subversion
and Git repositories publicly available that are tracking the
PostgreSQL sources.
Stepping back to the SCM discussion, people were interested in finding
out what merits there were in having these sorts of
New buildfarm member Narwhal is failing the PL regression tests for
Python on REL8_1_STABLE. This appears to be because it's running Python
2.5 (the causes being a deprecated module - whrandom - and some changed
messages).
The former problem was fixed by Peter, and the latter by Tom but both
On 4/17/07, Dave Page [EMAIL PROTECTED] wrote:
New buildfarm member Narwhal is failing the PL regression tests for
Python on REL8_1_STABLE. This appears to be because it's running Python
2.5 (the causes being a deprecated module - whrandom - and some changed
messages).
I also suggest
Hello!
I'm trying to get the buildfarm to run on my XP x64 machine (still in
32-bit mode), and it's acting weird on me :-(
The plpython tests because of:
+ NOTICE: ('import failed -- No module named bisect',)
and
! ERROR: plpython: function import_test_two failed
! DETAIL: type
Tom Lane wrote:
Dave Page [EMAIL PROTECTED] writes:
Andrew Dunstan wrote:
The question in my mind is this: how much do we back-patch to cover new
and incompatible releases of software we depend on?
I guess that depends on the invasiveness - in this case it's a couple of
simple updates to
Dunno if anyone's noticed, but buildfarm member jackal has been crashing
intermittently in the cluster regression test. I found out that I can
reproduce that here on a Mac Mini (apparently the same or nearly same
hardware/software as jackal) --- just repeat the parallel tests often
enough, and
Josh Berkus wrote:
KaiGai,
It provides database users fine grained mandatory access control
including row and column level one, and integration with operating
system security policy.
Column level? We don't currently support that, except through VIEWs.
How is it implemented?
PGACE
Tom Lane wrote:
Josh Berkus [EMAIL PROTECTED] writes:
Column level? We don't currently support that, except through VIEWs.
How is it implemented?
It wasn't clear to me how much of this is actually working today and how
much is a paper design --- one thing in particular that stood out as
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
What's more, we have a SoC project for column level access controls.
... which presumably wouldn't involve any added dependency on outside code.
For people who are already using SELinux or Trusted Solaris, making the
database
For people who are already using SELinux or Trusted Solaris, making the
database dependent on that infrastructure might be seen as a plus, but
I'm not sure the rest of the world would be pleased.
Even where SELinux is available it has had mixed reviews - I habitually
disable it.
The
On 4/17/07, Marko Kreen [EMAIL PROTECTED] wrote:
If DISCARD is the final word, I start to prepare a patch.
Attached patch does following conversions:
RESET PLANS - DISCARD PLANS
RESET TEMP - DISCARD TEMP
RESET SESSION - DISCARD ALL
--
marko
discard.diff.gz
Description: GNU Zip compressed
Dave Page [EMAIL PROTECTED] writes:
Andrew Dunstan wrote:
The question in my mind is this: how much do we back-patch to cover new
and incompatible releases of software we depend on?
I guess that depends on the invasiveness - in this case it's a couple of
simple updates to the regression
Dave Page wrote:
New buildfarm member Narwhal is failing the PL regression tests for
Python on REL8_1_STABLE. This appears to be because it's running
Python 2.5 (the causes being a deprecated module - whrandom - and some
changed messages).
The former problem was fixed by Peter, and the
Andrew Dunstan wrote:
The question in my mind is this: how much do we back-patch to cover new
and incompatible releases of software we depend on? Python 2.5 was
released on 19 Sept 2006, long after Postgres 8.1. I guess you could
make a case to say that we should back-patch to the release
Tom Lane wrote:
Dunno if anyone's noticed, but buildfarm member jackal has been crashing
intermittently in the cluster regression test. I found out that I can
reproduce that here on a Mac Mini (apparently the same or nearly same
hardware/software as jackal) --- just repeat the parallel tests
The \COPY command rejects multibyte delimiters. Is this intentional
behavior?
Here is an example of the behavior:
[EMAIL PROTECTED] ~ $ touch foo
[EMAIL PROTECTED] ~ $ psql -p
Welcome to psql 8.3devel, the PostgreSQL interactive terminal.
Type: \copyright for distribution terms
Mark Dilger wrote:
The \COPY command rejects multibyte delimiters. Is this intentional
behavior?
It is certainly a known limitation, and I suspect removing it could add
non-trivial overhead to the input processing.
What is the use case for using such a delimiter?
cheers
andrew
Andrew Dunstan wrote:
Mark Dilger wrote:
The \COPY command rejects multibyte delimiters. Is this intentional
behavior?
It is certainly a known limitation, and I suspect removing it could add
non-trivial overhead to the input processing.
What is the use case for using such a delimiter?
Mark Dilger wrote:
Andrew Dunstan wrote:
Mark Dilger wrote:
The \COPY command rejects multibyte delimiters. Is this intentional
behavior?
It is certainly a known limitation, and I suspect removing it could
add non-trivial overhead to the input processing.
What is the use case for using
Andrew Dunstan [EMAIL PROTECTED] writes:
Mark Dilger wrote:
I'm working on fixing bugs relating to multibyte character encodings.
I wasn't sure whether this was a bug or not. I don't think we should
use the phrasing COPY delimiter must be a single character when, in
utf8 land, I did in
On looking at the code, there's another issue: the CSV escape and quote
characters are assumed to be the same in client and server encodings,
because they're checked for before we do transcoding. This pretty much
restricts them to be ASCII.
regards, tom lane
On Sun, Apr 01, 2007 at 12:36:01AM +0200, Peter Eisentraut wrote:
Tom Lane wrote:
I seem to remember that we'd agreed that autovacuum should ignore any
globally set statement_timeout, on the grounds that a poorly chosen
setting could indefinitely prevent large tables from being vacuumed.
Jim C. Nasby wrote:
On Sun, Apr 01, 2007 at 12:36:01AM +0200, Peter Eisentraut wrote:
Tom Lane wrote:
I seem to remember that we'd agreed that autovacuum should ignore any
globally set statement_timeout, on the grounds that a poorly chosen
setting could indefinitely prevent large tables from
How can I create a schema during initdb time?
For example pg_catalog, pg_toast, information_schema are created during
initdb time. Likewise I want to create my own schema at initdb time. How can
i do it? Also how to create a table into this schema at that time itself?
Thanks
Sharat.
sharath kumar wrote:
How can I create a schema during initdb time?
For example pg_catalog, pg_toast, information_schema are created
during initdb time. Likewise I want to create my own schema at initdb
time. How can i do it? Also how to create a table into this schema at
that time itself?
Tom Lane wrote:
Any suggestions how to extract some info out of this?
Does OS X have the catchsegv tool? If you can run postmaster with that,
you should get a backtrace when it crashes. Unless it has the same
problem as gdb, of course..
--
Heikki Linnakangas
EnterpriseDB
Heikki Linnakangas [EMAIL PROTECTED] writes:
Tom Lane wrote:
Any suggestions how to extract some info out of this?
Does OS X have the catchsegv tool?
No, but I suddenly remembered about CrashReporter, and sure enough it's
catching these crashes:
Exception: EXC_BAD_ACCESS (0x0001)
Codes:
Alvaro Herrera wrote:
Larry Rosenman wrote:
Greetings,
I think I found a bug, or at least a POLA violation. At work, I created
a user that is NOT a superuser, nor can that user create databases. When I
did a create database foo owner bar, all the schemas are set to be owned by
the
Tom Lane wrote:
Larry Rosenman [EMAIL PROTECTED] writes:
I guess the issue is that I'd expect public to be owned by the DB Owner
after
a CREATE DATABASE foo OWNER bar,
Why? Do you expect the system catalogs to be owned by the DB owner?
What about other random objects that might have
Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
Tom Lane wrote:
Any suggestions how to extract some info out of this?
Does OS X have the catchsegv tool?
No, but I suddenly remembered about CrashReporter, and sure enough it's
catching these crashes:
Exception: EXC_BAD_ACCESS
I wrote:
Thread 0 Crashed:
0 postmaster 0x001af4ef smgrextend + 12 (smgr.c:485)
1 postmaster 0x00029044 end_heap_rewrite + 208 (rewriteheap.c:278)
2 postmaster 0x000bdc22 cluster_rel + 850 (cluster.c:806)
3 postmaster 0x000be119 cluster + 160 (cluster.c:220)
AFAICS, a crash
Heikki Linnakangas [EMAIL PROTECTED] writes:
But I did notice that we're not fsyncing the newly written relation like
we should.
Good point, but doesn't the analogy to copy_relation_data say that we
should sync if not rd_istemp? (This is my fault BTW; your original
patch kept the data in
Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
But I did notice that we're not fsyncing the newly written relation like
we should.
Good point, but doesn't the analogy to copy_relation_data say that we
should sync if not rd_istemp?
Right. I don't know why I didn't copy that
A recent discussion led me to the idea that FK triggers are fired
unnecessarily during an UPDATE if the foreign-key column(s) contain
any NULLs, because ri_KeysEqual() treats two nulls as unequal,
and therefore we conclude the row has changed when it has not.
I claim that both ri_KeysEqual() and
Tom Lane wrote:
Mark Kirkwood [EMAIL PROTECTED] writes:
Tom Lane wrote:
The current documentation for RESET exhibits a certain lack of, um,
intellectual cohesiveness:
Synopsis
RESET configuration_parameter
RESET ALL
RESET { PLANS | SESSION | TEMP | TEMPORARY }
Maybe DISCARD for the plans
Florian G. Pflug wrote:
Initially, I'll post it on http://git.catalyst.net.nz/ and I can run a
daily import for you - once that's in place you can probably get a repo
with your work on http://repo.or.cz/
Ok - you can now clone from http://git.catalyst.net.nz/postgresql.git
viewable from
Florian G. Pflug wrote:
Cool - I'm new to git, so I really appreciate any help that I can get.
Great - I am a SoC mentor for 2 other projects (git and moodle) so I've
got some time set aside for SoC stuff. You might as well take advantage
of it :-)
For the kind of work you'll be doing (writing
On Tue, 2007-04-17 at 17:16 -0400, Tom Lane wrote:
A recent discussion led me to the idea that FK triggers are fired
unnecessarily during an UPDATE if the foreign-key column(s) contain
any NULLs, because ri_KeysEqual() treats two nulls as unequal,
and therefore we conclude the row has changed
On Fri, Apr 13, 2007 at 03:02:28PM +0200, Dany DeBontridder wrote:
On 4/13/07, Heikki Linnakangas [EMAIL PROTECTED] wrote:
Dany DeBontridder wrote:
I'm working to implement a new feature to pg_dump: the ability to dump
objects like function, indexes...
pg_dump already dumps functions
[EMAIL PROTECTED] (Bruce Momjian) writes:
Also done for PL/pgSQL:
o Add support for WITH HOLD and SCROLL cursors
o -Add support for WITH HOLD and SCROLL cursors
WITH HOLD support is not there.
regards, tom lane
On Sun, Apr 15, 2007 at 08:00:23PM -0300, Josh Berkus wrote:
Now, while each of these students has an assigned mentor, that doesn't
mean other people shouldn't help. If you're interested in their work,
please pitch in.
Note that we'll also be using the pgsql-students mailing list for
On Tue, Apr 17, 2007 at 12:51:51PM -0700, Joshua D. Drake wrote:
Jim C. Nasby wrote:
On Sun, Apr 01, 2007 at 12:36:01AM +0200, Peter Eisentraut wrote:
Tom Lane wrote:
I seem to remember that we'd agreed that autovacuum should ignore any
globally set statement_timeout, on the grounds that a
On looking at the code, there's another issue: the CSV escape and quote
characters are assumed to be the same in client and server encodings,
because they're checked for before we do transcoding. This pretty much
restricts them to be ASCII.
regards, tom lane
+1.
Jim,
Will all discussions take place here or in -students?
The idea is that discussions about the SoC *program* and where do I
submit ... questions will go on -students; any questions about actual
code will go here or on the appropriate dev list.
Probably worth posting about that to
Tom, Andrew, KaiGai,
Andrew Dunstan [EMAIL PROTECTED] writes:
What's more, we have a SoC project for column level access controls.
I don't see the SE stuff as a replacement for that, since it apparently
exists outside the standard SQL security model.
... which presumably wouldn't involve
On Tue, 17 Apr 2007, Tom Lane wrote:
A recent discussion led me to the idea that FK triggers are fired
unnecessarily during an UPDATE if the foreign-key column(s) contain
any NULLs, because ri_KeysEqual() treats two nulls as unequal,
and therefore we conclude the row has changed when it has
Tom Lane wrote:
[EMAIL PROTECTED] (Bruce Momjian) writes:
Also done for PL/pgSQL:
o Add support for WITH HOLD and SCROLL cursors
o -Add support for WITH HOLD and SCROLL cursors
WITH HOLD support is not there.
Thanks, I was wondering about that. TODO item split
Aidan Van Dyk [EMAIL PROTECTED] writes:
I have my CVS-GIT conversion running hourly from the anon-rsync of the
cvsroot. I don't know the specifics of the PostgreSQL rsync/mirror
setup, so I may be pulling it more frequently than it's actually
published, but until I hear from someone that
Tatsuo Ishii wrote:
On looking at the code, there's another issue: the CSV escape and quote
characters are assumed to be the same in client and server encodings,
because they're checked for before we do transcoding. This pretty much
restricts them to be ASCII.
Martin Langhoff wrote:
Aidan Van Dyk wrote:
And remember the warning I gave that my conversion is *not* a direct CVS
import - I intentionally *unexpand* all Keywords before stuffing them
into GIT so that merging and branching can ignore all the Keyword
conflicts...
My import is unexpanding
On Tuesday 17 April 2007 18:38, Jim C. Nasby wrote:
On Tue, Apr 17, 2007 at 12:51:51PM -0700, Joshua D. Drake wrote:
Jim C. Nasby wrote:
On Sun, Apr 01, 2007 at 12:36:01AM +0200, Peter Eisentraut wrote:
Tom Lane wrote:
I seem to remember that we'd agreed that autovacuum should ignore any
Robert Treat [EMAIL PROTECTED] writes:
I'm with Joshua on this one. Statement_timeout is often used as a means for
protection from long running statements due to server load and locking and
all of the above commands can certainly fall into that area. If people feel
strongly that the command
[EMAIL PROTECTED] (Bruce Momjian) writes:
Update error message for COPY with a multi-byte delimiter.
You forgot the CSV strings.
regards, tom lane
---(end of broadcast)---
TIP 5: don't forget to increase your free space
Aidan Van Dyk wrote:
I'm an unknown here, I know - I've used PostgreSQL for years, but only
recently started following the development community... And at this
I'm probably unknown here as well. Hi everyone ;-)
And remember the warning I gave that my conversion is *not* a direct CVS
import
* Florian G. Pflug [EMAIL PROTECTED] [070417 20:30]:
So - if you are committed to providing your gateway long term to
Florian, I'm happy to drop my gateway in favour of yours.
There seem to be other people than me who are interested in a git
mirror. Maybe we could declare one of those
Tom Lane wrote:
Robert Treat [EMAIL PROTECTED] writes:
I'm with Joshua on this one. Statement_timeout is often used as a means for
protection from long running statements due to server load and locking and
all of the above commands can certainly fall into that area. If people feel
strongly
Tatsuo Ishii [EMAIL PROTECTED] writes:
The message in question should be something like:
COPY delimiter must be a single ASCII character
If we phrase it like that we should enforce it like that --- ie, reject
high-bit-set characters.
But I'm a bit hesitant to do so, because it
Joshua D. Drake wrote:
Tom Lane wrote:
Robert Treat [EMAIL PROTECTED] writes:
I'm with Joshua on this one. Statement_timeout is often used as a means
for protection from long running statements due to server load and
locking and all of the above commands can certainly fall into that area.
Tom Lane wrote:
[EMAIL PROTECTED] (Bruce Momjian) writes:
Update error message for COPY with a multi-byte delimiter.
You forgot the CSV strings.
OK, I wasn't clear on those but I am now. I backpatched the doc change
to 8.2.X.
--
Bruce Momjian [EMAIL PROTECTED]
Alvaro Herrera wrote:
I think that is too strong an assumption, which is why I'm planning to
back-patch the change to reset statement_timeout to 0 on autovacuum till
8.0, as discussed. I think I should also backpatch the change to set
zero_damaged_pages as well (which is not on 8.0 AFAIR).
Martin Langhoff [EMAIL PROTECTED] writes:
Aidan Van Dyk wrote:
And remember the warning I gave that my conversion is *not* a direct CVS
import - I intentionally *unexpand* all Keywords before stuffing them
into GIT so that merging and branching can ignore all the Keyword
conflicts...
My
64 matches
Mail list logo
