Andrew Dunstan [EMAIL PROTECTED] writes:
Martin Zaun wrote:
- issues locating the 14 required software packages:
- no luck getting Bison 1.875 or 2.2 Windows binaries
bison 1.875 is available here:
http://sourceforge.net/project/showfiles.php?group_id=23617package_id=22822
To the best of
On Tue, Jul 22, 2008 at 04:32:39PM +0200, Zdenek Kotala wrote:
Oh, so you're thinking of a charset as a sort of check constraint. If
your locale is turkish and you have a column marked charset ASCII then
storing lower('HI') results in an error.
Yeah, if you use strcoll function it fails when
Am Wednesday, 23. July 2008 schrieb Marko Kreen:
And the idea to turn pgfoundry into CPAN
is pointless. An user may willing to throw random modules to his
random perl script, but not to his whole db architecture.
Based on what reasoning?
--
Sent via pgsql-hackers mailing list
Hi,
Tom Lane wrote:
I hope you're not expecting the contents of shared memory to still be
trustworthy after a backend crash.
Hm.. that's a good point.
So I either need to bullet-proof the imessages with checksums or some
such. I'm not sure that's doable reliably. Not to speak about
Am Wednesday, 23. July 2008 schrieb Zdenek Kotala:
Is it fixed only on head or do you plan to backported to older branch as
well?
I don't see a need to backport this. The only difference is that now you will
get an error if no tclsh is found. The call configure TCLSH=... is the
same in all
Hi,
Le jeudi 24 juillet 2008, Tom Dunstan a écrit :
I guess that means you missed both the original discussion at
http://archives.postgresql.org/pgsql-hackers/2008-04/msg00132.php and
my initial patch in that direction and subsequent discussion at
Jonah H. Harris wrote:
On Mon, Jul 21, 2008 at 10:19 PM, Tom Lane [EMAIL PROTECTED] wrote:
Jonah H. Harris [EMAIL PROTECTED] writes:
The case I'm looking at is a large table which requires a lazy vacuum,
and a zero vacuum cost delay would cause too much I/O. Yet, this
table has enough
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Martin Zaun wrote:
- issues locating the 14 required software packages:
- no luck getting Bison 1.875 or 2.2 Windows binaries
bison 1.875 is available here:
http://sourceforge.net/project/showfiles.php?group_id=23617package_id=22822
On 7/24/08, Peter Eisentraut [EMAIL PROTECTED] wrote:
Am Wednesday, 23. July 2008 schrieb Marko Kreen:
And the idea to turn pgfoundry into CPAN
is pointless. An user may willing to throw random modules to his
random perl script, but not to his whole db architecture.
Based on what
I have some suggestions for additional psql features. I'm not planning
to work on them myself, just proposing them so others can do so if they
agree and wish to do so.
* default values for substitution values
Need a command to set the default value of a substitution variable, so
that it takes a
CREATE TABLE LIKE is useful to create a new partition from a template
table. We can use 3 options (INCLUDING DEFAULTS, CONSTRAINTS and INDEXES)
to copy more parameters from the template, but there are still some
uncopied parameters:
1. column storage parameters (toast options)
2. reloptions
On Thu, 2008-07-24 at 19:09 +0900, ITAGAKI Takahiro wrote:
CREATE TABLE LIKE is useful to create a new partition from a template
table. We can use 3 options (INCLUDING DEFAULTS, CONSTRAINTS and INDEXES)
to copy more parameters from the template, but there are still some
uncopied parameters:
Hi.
Sorry, very late reaction
I'm based on the environment of VC++2005 and MinGW by the reason for requiring
official
support. and since it does not have many resources, the environment of VC++2008 is
restricted.
Therefore, many suggestion can't be performed now:-(
- Original
On Thu, 2008-07-24 at 10:30 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
I would prefer it if you had a plan to introduce user definable
parameters, similar to custom_variable_classes. Perhaps call this
custom_table_options. So when we load a table and it has an option we
I performed review and I prepared own patch which contains only probes without
any issue. I suggest commit this patch because the rest of patch is independent
and it can be committed next commit fest after rework.
I found following issues:
1) SLRU probes.
I think it is good to have probes
On Tue, 2008-07-22 at 17:24 -0400, Tom Lane wrote:
In the case of plproxy, I think an integrated solution is pronounced
SQL-MED, and likewise plproxy in its present form doesn't move us
toward that goal.
While pl/proxy can be tweaked into a way of achieving functionality of
SQL-MED (SQL/MED
Simon Riggs [EMAIL PROTECTED] writes:
On Thu, 2008-07-24 at 10:30 -0400, Tom Lane wrote:
Given the very short list of supported
reloptions right now, why would you imagine that there will ever
be such a thing as installation-local reloptions?
There's a ton of ways to introduce
* shiftList() holds an exclusive lock on metapage throughout its run,
which means that it's impossible for two of them to run concurrently.
So why bother with concurrent deletion detection?
Because metapage is locked immediately before shiftList call, while metapage is
unlocked another process
On Mon, 2008-07-21 at 17:50 -0400, Jonah H. Harris wrote:
Currently, one cannot perform a concurrent VACUUM and ANALYZE. This
is a significant problem for tables which are not only large and have
designated cost-delays, but which are also heavily inserted into and
deleted from.
I suspect
On Tue, 2008-07-22 at 11:25 -0400, Tom Lane wrote:
Marko Kreen [EMAIL PROTECTED] writes:
And user can execute only pre-determines queries/functions on system2.
If that were actually the case then the security issue wouldn't loom
quite so large, but the dynamic_query example in the plproxy
On Thu, 2008-07-24 at 18:38 +0300, Hannu Krosing wrote:
On Tue, 2008-07-22 at 17:24 -0400, Tom Lane wrote:
In the case of plproxy, I think an integrated solution is pronounced
SQL-MED, and likewise plproxy in its present form doesn't move us
toward that goal.
I'm pretty sure that there is
On Jul 24, 2008, at 11:11 AM, Zdenek Kotala wrote:
I performed review and I prepared own patch which contains only
probes without any issue. I suggest commit this patch because the
rest of patch is independent and it can be committed next commit
fest after rework.
I found following
Sorry for the delay in the answer but i was busy with 2 projects and a talk...
On Sat, Jul 12, 2008 at 3:50 PM, Tom Lane [EMAIL PROTECTED] wrote:
I think it's probably reasonable as long as we keep the implicitly
granted rights as narrow as possible. INSERT on the parent table
would normally
On Thu, Jul 24, 2008 at 9:06 AM, Simon Riggs [EMAIL PROTECTED] wrote:
I suspect this is not the root problem, but one solution to it.
Agreed. It is not the root problem. However, until DSM is fully
implemented and working, not having the ability to gather statistics
during long vacuums is
Teodor Sigaev [EMAIL PROTECTED] writes:
* There is a bigger race condition, which is that after a scan has
returned a tuple from a pending page, vacuum could move the index entry
into the main index structure, and then that same scan could return that
same index entry a second time. This is a
Jaime Casanova [EMAIL PROTECTED] writes:
Another issue is the interaction with the planned column-level GRANT
feature.
Although that is a feature we want, is a WIP one... do we stop patches
because it can conflict with a project we don't know will be applied
soon?
Well, considering that
I wrote:
Really? Then GiST needs to be fixed too. Otherwise you risk having
queries return the same row twice. A bitmap indexscan plan would mask
such an index bug ... but a plain indexscan won't.
BTW, there's another issue I forgot about yesterday, which is that
the planner assumes that
Simon Riggs [EMAIL PROTECTED] writes:
I would prefer it if you had a plan to introduce user definable
parameters, similar to custom_variable_classes. Perhaps call this
custom_table_options. So when we load a table and it has an option we
don't recognise we ignore it if it is one of the
On Wed, 2008-07-23 at 12:38 -0400, Tom Lane wrote:
Greg Sabino Mullane [EMAIL PROTECTED] writes:
Code outside of core, is, in reality, less reviewed, less likely to work
well with recent PG versions, and more likely to cause problems. It's also
less likely to be found by people, less likely
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
NotDashEscaped: You need GnuPG to verify this message
shared_buffers is in disk block size, typically 8K
The table the OP is looking at (table 17.2 in the 8.3 docs) predates
the ability to specify shared_buffers in KB or MB instead of
On Thu, 2008-07-24 at 17:54 +, Greg Sabino Mullane wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
NotDashEscaped: You need GnuPG to verify this message
shared_buffers is in disk block size, typically 8K
The table the OP is looking at (table 17.2 in the 8.3 docs)
The fine manual claims that the base dn part of an LDAP URL
is meaningful:
The server will bind to the distinguished name specified as base
dn using the user name supplied by the client. If prefix and
suffix is specified, it will be prepended and appended to the
operations such as page splits. Do we need to change the planner to
assume that this only works nicely for btree?
It seems to that direction (backward or forward) has meaning only for indexes
with amcanorder = true. With amcanorder=false results will be occasionally for
any direction.
--
Teodor Sigaev [EMAIL PROTECTED] writes:
operations such as page splits. Do we need to change the planner to
assume that this only works nicely for btree?
It seems to that direction (backward or forward) has meaning only for
indexes with amcanorder = true. With amcanorder=false results will
Tatsuo Ishii [EMAIL PROTECTED] writes:
Reviewers, please let me know if you find problems with the
patches. If none, I would like to commit this weekend.
Given that everyone who has tested this has found a different way to
crash it, and that the frequency of crash reports shows no signs of
queries return the same row twice. A bitmap indexscan plan would mask
such an index bug ... but a plain indexscan won't.
Fuh. :(. Well. Will fix.
GiST:
- GiST already supports both scan directions in theory, but page split may
change order between forward and backward scans (user-defined
On Thu, 2008-07-24 at 09:06 -0700, Joshua D. Drake wrote:
On Thu, 2008-07-24 at 18:38 +0300, Hannu Krosing wrote:
On Tue, 2008-07-22 at 17:24 -0400, Tom Lane wrote:
In the case of plproxy, I think an integrated solution is pronounced
SQL-MED, and likewise plproxy in its present form
Teodor Sigaev [EMAIL PROTECTED] writes:
- GiST already supports both scan directions in theory, but page split may
change order between forward and backward scans (user-defined pageSplit
doesn't
preserve order of tuples). Holding of split until end of scan will produce
unacceptable
Hannu Krosing [EMAIL PROTECTED] writes:
On Thu, 2008-07-24 at 09:06 -0700, Joshua D. Drake wrote:
These are all excellent points but I think the real problem here is:
There is nothing that requires pl/proxy to be in core.
AFAIK, there is nothing that requires pl/perl, pl/tcl or pl/python to
On Thu, Jul 24, 2008 at 4:37 PM, Tom Lane [EMAIL PROTECTED] wrote:
Hannu Krosing [EMAIL PROTECTED] writes:
On Thu, 2008-07-24 at 09:06 -0700, Joshua D. Drake wrote:
These are all excellent points but I think the real problem here is:
There is nothing that requires pl/proxy to be in core.
There's some fairly squirrely logic in pg_dump/pg_restore that tries to
detect whether it's doing a data-only operation, ie, no schema
information is to be dumped or restored. The reason it wants to
know this is to decide whether to enable the --disable-triggers
code. However, since
Robert Haas [EMAIL PROTECTED] writes:
ISTM that if that if you're willing to admit, even with caveats, that
PL/perl, PL/tcl, or PL/python doesn't need to be in core, then
excluding anything else from core on the basis that it doesn't need to
be there is silly.
You are merely setting up a
Tom Lane wrote:
If the user says --disable-triggers, he should get
trigger disable commands around the data part of the dump, no matter
what he said or didn't say about schema dumping.
Right. They seem like orthogonal issues.
cheers
andrew
--
Sent via pgsql-hackers mailing list
On Thu, Jul 24, 2008 at 01:55:37PM +0900, Tatsuo Ishii wrote:
Program received signal SIGSEGV, Segmentation fault.
Thanks for the report. Here is the new patches from Yoshiyuki.
Thanks for the patch :)
Now, I get a different problem, this time with the following code
intended to materialize
Now, I get a different problem, this time with the following code
intended to materialize paths on the fly and summarize down to a
certain depth in a tree:
CREATE TABLE tree(
id INTEGER PRIMARY KEY,
parent_id INTEGER REFERENCES tree(id)
);
INSERT INTO tree
VALUES (1, NULL),
* Tom Lane ([EMAIL PROTECTED]) wrote:
Simon's patch to split up --schema-only into two switches has broken
this logic, but I'm inclined to just rip it out rather than trying
to fix it. If the user says --disable-triggers, he should get
trigger disable commands around the data part of the
Simon Riggs [EMAIL PROTECTED] wrote:
* access to version number
* simple mechanism for conditional execution
* ability to set substitution variables from command execution
* conditional execution whether superuser or not
Can we use pgScript for such flow controls?
On Thu, Jul 24, 2008 at 2:37 PM, Tom Lane [EMAIL PROTECTED] wrote:
Hannu Krosing [EMAIL PROTECTED] writes:
And it would be nice, if some well-maintained sample language (pl/sh or
even pl/dummy) which serves as a sample of latest ways to make use of
pl/function support in core pg code would be
Hello hackers,
I know the development community is in the middle of the July 2008
commit-fest, so I apologize if this design proposals are in
appropriate at this time.
I am looking to take advantage of PostgreSQL extensible type system
and implement unsigned integer support. The data I am
Ryan Bradetich [EMAIL PROTECTED] writes:
I am looking to take advantage of PostgreSQL extensible type system
and implement unsigned integer support.
This has been proposed before, and foundered before on the question
of implicit coercions. If you're willing to make all coercions *to*
unsigned
On Thu, Jul 24, 2008 at 12:09 PM, Tom Lane [EMAIL PROTECTED] wrote:
Jaime Casanova [EMAIL PROTECTED] writes:
Another issue is the interaction with the planned column-level GRANT
feature.
Although that is a feature we want, is a WIP one... do we stop patches
because it can conflict with a
Hello Tom,
On Thu, Jul 24, 2008 at 10:10 PM, Tom Lane [EMAIL PROTECTED] wrote:
Ryan Bradetich [EMAIL PROTECTED] writes:
I am looking to take advantage of PostgreSQL extensible type system
and implement unsigned integer support.
This has been proposed before, and foundered before on the
52 matches
Mail list logo
