All local memory is safe to handle that way.
In my case I am reallocating memory for a global variable between
transactions. I wanted to make sure I don't leave allocated memory behind.
The problem only arises when you have memory to release _earlier_ than
that.
First I was looking for a way
Tom Lane [EMAIL PROTECTED] writes:
After much experimentation I was able to get it to work by invoking
memcpy through a function pointer, which seems to be sufficient to
disable this particular compiler's built-in intelligence about memcpy.
I can't say that I find this a nice clean solution;
On Wed, Feb 20, 2008 at 06:38:09PM -0500, Bruce Momjian wrote:
Aidan Van Dyk wrote:
* Josh Berkus [EMAIL PROTECTED] [080220 18:00]:
All,
I think we're failing to discuss the primary use-case for this, which
is one reason why the solutions aren't obvious.
However, imagine
On Wed, Feb 20, 2008 at 06:38:10PM -0500, Tom Lane wrote:
Aidan Van Dyk [EMAIL PROTECTED] writes:
* Josh Berkus [EMAIL PROTECTED] [080220 18:00]:
We need a server-based tool for the manipulating postgresql.conf, and
one which is network-accessable, allows updating individual settings,
On Wed, Feb 20, 2008 at 11:53:47PM +, Gregory Stark wrote:
Tom Lane [EMAIL PROTECTED] writes:
Andrew Dunstan [EMAIL PROTECTED] writes:
All this discussion seems to me to be going off into the clouds, where
every objection is met with some still more elaborate scheme. I think we
On Wed, Feb 20, 2008 at 06:17:37PM -0500, Aidan Van Dyk wrote:
* Josh Berkus [EMAIL PROTECTED] [080220 18:00]:
All,
I think we're failing to discuss the primary use-case for this, which
is one reason why the solutions aren't obvious.
However, imagine you're adminning 250 PostgreSQL
On Wed, Feb 20, 2008 at 03:02:49PM -0800, Josh Berkus wrote:
All,
I think we're failing to discuss the primary use-case for this, which
is one reason why the solutions aren't obvious.
And that use case is: multi-server management.
I don't agree that this is the primary use case. But I do
On Wed, Feb 20, 2008 at 06:14:27PM -0800, Joshua D. Drake wrote:
On Wed, 20 Feb 2008 09:42:02 -0500
Andrew Dunstan [EMAIL PROTECTED] wrote:
All this discussion seems to me to be going off into the clouds,
where every objection is met with some still more elaborate scheme. I
think we need
On Wed, Feb 20, 2008 at 03:56:38PM -0800, paul rivers wrote:
Tom Lane wrote:
Aidan Van Dyk [EMAIL PROTECTED] writes:
* Josh Berkus [EMAIL PROTECTED] [080220 18:00]:
We need a server-based tool for the manipulating postgresql.conf, and
one which is network-accessable, allows updating
Gevik Babakhani wrote:
I would like to have your opinion about the following behavior of TO_DATE.
Is this correct or a hidden feature?
There are quite a few complaints in the archive about to_date's incorrect or
questionable behavior. I'm sure this is one of them. This code needs a
general,
There are quite a few complaints in the archive about
to_date's incorrect or questionable behavior. I'm sure this
is one of them. This code needs a general, systematic review.
I am working on a todo item. I'll report and fix anything I encounter there.
Regards,
Gevik
I would like to have your opinion about the following behavior of TO_DATE.
Is this correct or a hidden feature?
case:
'mon 21-feb-2008' is obviously a bad date. It should be 'thu 21-feb-2008'
test:
testdb=# select to_date('mon 21-feb-2008','dy dd-mon-');
to_date
2008-02-21
(1
regarding http://archives.postgresql.org/pgsql-hackers/2008-02/msg00826.php
I was wondering why we have a custom written parser to parse the date/time
from/to string and vice versa?
Is there a historical reason? Would a yacc/lex parser be better?
Regards,
Gevik
---(end
On Wed, Feb 20, 2008 at 05:59:27PM -0500, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
On Tue, 2008-02-19 at 14:22 +0100, Magnus Hagander wrote:
I'd like to add a way for a client (in this case, typicallyi pgadmin,
phppgadmin or similar) to get the available options on the server
Magnus Hagander wrote:
I like the idea that was mentioned upthread of creating a new enum
category for GUC variables, instead of continuing to abuse the rather
inefficient string category for the purpose. One reason is that
we then would not be faced with making an incompatible change in
On Thu, Feb 21, 2008 at 09:15:13AM -0300, Alvaro Herrera wrote:
Magnus Hagander wrote:
I like the idea that was mentioned upthread of creating a new enum
category for GUC variables, instead of continuing to abuse the rather
inefficient string category for the purpose. One reason is
This is a postgresql 8.2.5 backend. connected to a jdbc client.
2008-02-21 06:12:30 EST [18880] 10.21.0.21 ERROR: insufficient data
left in message
2008-02-21 06:12:30 EST [18880] 10.21.0.21 STATEMENT: select * from
user_profile,user_profile_access where user_profile.uid=user_profile_a
Aidan Van Dyk wrote:
* Magnus Hagander [EMAIL PROTECTED] [080220 14:03]:
I think the first step is really for some people to show code that
rewrites the config file changing a setting reliably and correctly.
But what we're donig now is discussing *how to do that*, no?
Sort of, but
Magnus Hagander wrote:
On Wed, Feb 20, 2008 at 06:14:27PM -0800, Joshua D. Drake wrote:
On Wed, 20 Feb 2008 09:42:02 -0500
Andrew Dunstan [EMAIL PROTECTED] wrote:
All this discussion seems to me to be going off into the clouds,
where every objection is met with some still more elaborate
* Magnus Hagander [EMAIL PROTECTED] [080221 04:30]:
I would have thought that any larger enterprise was familiar with
these approaches, and are probably using them already to
manage/configure there general unix environments
What makes you think that all environments are unix environments?
On Wed, Feb 20, 2008 at 11:43:43PM +0700, Naz Gassiep wrote:
Not true, the zone.tab file has 398 zones defined, and in my PG 8.2
running on Debian, there are 564 timezones listed in pg_timezone_names.
The field I propose would indicate which 398 of those 564 are listed in
zone.tab as those
Dave Cramer [EMAIL PROTECTED] writes:
This is a postgresql 8.2.5 backend. connected to a jdbc client.
2008-02-21 06:12:30 EST [18880] 10.21.0.21 ERROR: insufficient data
left in message
AFAIK this means that the frontend sent an invalidly-formatted message.
There's some chance that the
On Wed, Feb 20, 2008 at 5:02 PM, in message
[EMAIL PROTECTED], Josh Berkus [EMAIL PROTECTED] wrote:
imagine you're adminning 250 PostgreSQL servers backing a
social networking application. You decide the application needs a
higher default sort_mem for all new connections, on all 250
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Do you know of any cross-platform tool that is capable of dealing with the
PostgreSQL configuration file in a context sensitive manner? Meaning that
it doesn't just treat it as a big file, but you can actually do for all
these 32 servers,
On Thu, 21 Feb 2008 10:30:00 +0100
Magnus Hagander [EMAIL PROTECTED] wrote:
Do you know of any cross-platform tool that is capable of dealing with the
PostgreSQL configuration file in a context sensitive manner? Meaning that
it doesn't just treat it as a big file, but you can actually do for
Zdenek Kotala wrote:
I like this idea. By my opinion only GUC variable with PGC_POSTMASTER
context must be in postgresql.conf. Most of them are related to memory
and networking configuration. Other can be only store in database. And
for startup, default value will work pretty well.
By the
Hi all.
The door was opened by Mr. Ralf S. Engelschall of a great developer.
http://www.ossp.org/pkg/lib/uuid/
It can be used from Version 1.6.1.
Please see,
http://winpg.jp/~saito/pg_work/OSSP_win32/
we can include in the next release.:-)
Thanks!
Regards,
Hiroshi Saito
Joshua D. Drake napsal(a):
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, 19 Feb 2008 15:22:42 -0300
Alvaro Herrera [EMAIL PROTECTED] wrote:
Joshua D. Drake wrote:
IMO this should all be in the database and that's it. The idea that
our global settings are in a file seems unusual
Gregory Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
I can't say that I find this a nice clean solution; but does anyone have
a better one?
I'm thinking instead of having struct varlena (which you're not allowed to
safely use any members of anyways) we should just have
Magnus Hagander wrote:
If they don't have an actual database, it's fairly common to use SQLite or
similar just to get proper database storage for it.
With all the concern about parsing in this thread, perhaps it's best
if this config-overrides file not be of the same syntax as postgresql.conf
Joshua D. Drake napsal(a):
Zdenek Kotala wrote:
I like this idea. By my opinion only GUC variable with PGC_POSTMASTER
context must be in postgresql.conf. Most of them are related to memory
and networking configuration. Other can be only store in database. And
for startup, default value will
Peter Eisentraut [EMAIL PROTECTED] writes:
Gevik Babakhani wrote:
I would like to have your opinion about the following behavior of TO_DATE.
Is this correct or a hidden feature?
There are quite a few complaints in the archive about to_date's incorrect or
questionable behavior. I'm sure
More questions
Feb 21 10:22:52 db02a postgres[3]: [742-1]
user=mocospace_user,db=jnj LOG: duration: 0.088 ms execute S_3:
select * from user_profile
,user_profile_access where
Feb 21 10:22:52 db02a postgres[3]: [742-2]
user_profile.uid=user_profile_access.uid and
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
I grow weary of repeating this: it's not about resource consumption, nor
about potential security holes in plpgsql itself. It's about handing
attackers the capability to further exploit *other* security holes.
Well, without specific
I have been looking at this thread for a bit and want to interject an idea.
A couple years ago, I offered a patch to the GUC system that added a
number of abilities, two left out were:
(1) Specify a configuration file on the command line.
(2) Allow the inclusion of a configuration file from
Gevik Babakhani [EMAIL PROTECTED] writes:
Would a yacc/lex parser be better?
Almost certainly neither workable nor an improvement if you did make it
work. Datetimes don't have enough structure to make yacc useful, and
it's not flexible enough either.
regards, tom lane
Mark Woodward wrote:
I have been looking at this thread for a bit and want to interject an idea.
A couple years ago, I offered a patch to the GUC system that added a
number of abilities, two left out were:
(1) Specify a configuration file on the command line.
(2) Allow the inclusion of a
Mark Woodward wrote:
I have been looking at this thread for a bit and want to interject an
idea.
A couple years ago, I offered a patch to the GUC system that added a
number of abilities, two left out were:
(1) Specify a configuration file on the command line.
(2) Allow the inclusion of
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, 21 Feb 2008 17:34:06 -
Greg Sabino Mullane [EMAIL PROTECTED] wrote:
There are so many simple ways to do bad things /without/ plpgsql, I
just don't see how the theoretical harm in it being used as an attack
vector even comes close to
Tom,
I grow weary of repeating this: it's not about resource consumption, nor
about potential security holes in plpgsql itself. It's about handing
attackers the capability to further exploit *other* security holes.
Well, without specific examples, I'm not sure I understand what plpgsql
Almost certainly neither workable nor an improvement if you
did make it work. Datetimes don't have enough structure to
make yacc useful, and it's not flexible enough either.
Understood. Thank you :)
---(end of broadcast)---
TIP 3: Have you
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, 21 Feb 2008 17:34:06 -
Greg Sabino Mullane [EMAIL PROTECTED] wrote:
There are so many simple ways to do bad things /without/ plpgsql, I
just don't see how the theoretical harm in it being used as an attack
vector even comes close to
Joshua D. Drake wrote:
Notice that user foo is not a super user. Now I log into
PostgreSQL and connect to the postgres database (the super users
database) as the non privileged user foo. The user foo in theory
has *zero* rights here accept that he can connect.
That's not true. The
Joshua D. Drake [EMAIL PROTECTED] writes:
In one fell swoop I could crash *any* postgresql database running 8.2.6
or below (I haven't tested this on 8.3).
Uh, I seem to have missed where the crash was in this example?
regards, tom lane
---(end
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, 21 Feb 2008 13:33:44 -0500
Andrew Dunstan [EMAIL PROTECTED] wrote:
That's not true. The public schema has public UC privs, and always
has had.
This disproves my point how?
There is nothing surprising (expect possibly to you) here.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, 21 Feb 2008 13:38:50 -0500
Tom Lane [EMAIL PROTECTED] wrote:
Joshua D. Drake [EMAIL PROTECTED] writes:
In one fell swoop I could crash *any* postgresql database running
8.2.6 or below (I haven't tested this on 8.3).
Uh, I seem to
Dave Cramer [EMAIL PROTECTED] writes:
More questions
Feb 21 10:22:52 db02a postgres[3]: [742-1]
user=mocospace_user,db=jnj LOG: duration: 0.088 ms execute S_3:
select * from user_profile
,user_profile_access where
Feb 21 10:22:52 db02a postgres[3]: [742-2]
Tom Lane [EMAIL PROTECTED] writes:
Gregory Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
I can't say that I find this a nice clean solution; but does anyone have
a better one?
I'm thinking instead of having struct varlena (which you're not allowed to
safely use any
Joshua D. Drake wrote:
Notice that user foo is not a super user. Now I log into
PostgreSQL and connect to the postgres database (the super users
database) as the non privileged user foo. The user foo in theory
has *zero* rights here accept that he can connect.
That's not
On Thu, Feb 21, 2008 at 10:43:27AM -0800, Joshua D. Drake wrote:
often. It is poor implementation and proof that the theoretical
security implications that are being brought up in this thread are far
from the practical reality.
We have this hole over here for historical reasons, so let's
Joshua D. Drake [EMAIL PROTECTED] writes:
Uh, I seem to have missed where the crash was in this example?
I wasn't willing to dump my machine. However I could:
A. Exhaust all resources
B. Fill up my hard drive
C. Render the application unusable for other users
D. Lock out DDL operations by
Joshua D. Drake wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, 21 Feb 2008 13:33:44 -0500
Andrew Dunstan [EMAIL PROTECTED] wrote:
That's not true. The public schema has public UC privs, and always
has had.
This disproves my point how?
You stated that this
Tom Lane wrote:
Anyway, as I said before, I don't object to installing plpgsql by
default. What I do object to is installing it in a way that makes it
difficult for the DBA to remove it, as would be the case if it were in
template0 for example.
... which means it can't be installed in
On Thu, 21 Feb 2008 14:14:48 -0500
Andrew Sullivan [EMAIL PROTECTED] wrote:
On Thu, Feb 21, 2008 at 10:43:27AM -0800, Joshua D. Drake wrote:
often. It is poor implementation and proof that the theoretical
security implications that are being brought up in this thread are far
from the
Alvaro Herrera [EMAIL PROTECTED] writes:
Tom Lane wrote:
Anyway, as I said before, I don't object to installing plpgsql by
default. What I do object to is installing it in a way that makes it
difficult for the DBA to remove it, as would be the case if it were in
template0 for example.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, 21 Feb 2008 14:15:28 -0500
Tom Lane [EMAIL PROTECTED] wrote:
Anyway, as I said before, I don't object to installing plpgsql by
default. What I do object to is installing it in a way that makes it
difficult for the DBA to remove it, as
Gregory Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
It might work to change struct varlena's contents to something like
char vl_len_[4]; /* Do not touch this field directly! */
char vl_dat[1];
Oh, that would probably fix this problem pretty well.
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Tom Lane wrote:
Anyway, as I said before, I don't object to installing plpgsql by
default. What I do object to is installing it in a way that makes it
difficult for the DBA to remove it, as would be the case if it were in
Alvaro Herrera [EMAIL PROTECTED] wrote:
The basic concept is spooling new coming data, and merge the spool and
the existing indexes into a new index at the end of data loading. It is
5-10 times faster than index insertion per-row, that is the way in 8.3.
Please see
Consider this test case:
create table baz (a int, b int);
insert into baz (select 1, generate_series(1, 300));
select baz.*, (select 1 from generate_series(1, 1) g(a)
where g.a baz.b)
from baz;
The final query consumes ~800 MB of memory on my
On Thursday 21 February 2008 11:36, Tom Lane wrote:
Would it satisfy people if plpgsql were in postgres, but neither
template DB, after initdb? T
No, the real-world use-case we're trying to satisfy is hosted and/or
locked-down installations where the developer doesn't have superuser access.
Itagaki-san,
Alvaro Herrera [EMAIL PROTECTED] wrote:
The basic concept is spooling new coming data, and merge the spool and
the existing indexes into a new index at the end of data loading. It is
5-10 times faster than index insertion per-row, that is the way in 8.3.
Thanks so much for
Josh Berkus [EMAIL PROTECTED] writes:
On Thursday 21 February 2008 11:36, Tom Lane wrote:
Would it satisfy people if plpgsql were in postgres, but neither
template DB, after initdb?
No, the real-world use-case we're trying to satisfy is hosted and/or
locked-down installations where the
Neil Conway [EMAIL PROTECTED] writes:
Two different classes of allocations in the EState's per-query context
are leaked:
(1) In FunctionNext(), we call ExecMakeTableFunctionResult() to compute
the result set of the SRF, which allocates the TupleDesc out-parameter
in the per-query memory
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
- --On Thursday, February 21, 2008 21:33:03 -0500 Tom Lane [EMAIL PROTECTED]
wrote:
Josh Berkus [EMAIL PROTECTED] writes:
On Thursday 21 February 2008 11:36, Tom Lane wrote:
Would it satisfy people if plpgsql were in postgres, but neither
Neil Conway [EMAIL PROTECTED] writes:
On Thu, 2008-02-21 at 21:42 -0500, Tom Lane wrote:
Yeah. I think it's hopeless to expect these functions to all hew to
the straight and narrow path. It seems to me that the right way is for
the sub-select to somehow run in its own per-query context.
On Thu, 2008-02-21 at 21:42 -0500, Tom Lane wrote:
Given your point (2), is this worth fixing by itself?
Right, probably not.
Yeah. I think it's hopeless to expect these functions to all hew to
the straight and narrow path. It seems to me that the right way is for
the sub-select to somehow
On Thu, Feb 21, 2008 at 6:44 AM, [EMAIL PROTECTED] wrote:
Hi.
That's the last release and refers to 8.3.0 and not to 8.2.5 as before. Hope
you can tell me if I created it correctly please.
no, it doesn't...
! /* GUC variables */
#ifdef TRACE_SORT
booltrace_sort =
Tatsuo Ishii [EMAIL PROTECTED] wrote:
5. Limitation with PostgreSQL
1) we do not implement SEARCH clause and CYCLE clause. This is because
we need array of rows to implement them. Note that there's no
support for array of rows in PostgreSQL.
What is difference between array of rows
On Fri, Feb 22, 2008 at 2:33 AM, Tom Lane [EMAIL PROTECTED] wrote:
Josh Berkus [EMAIL PROTECTED] writes:
On Thursday 21 February 2008 11:36, Tom Lane wrote:
Would it satisfy people if plpgsql were in postgres, but neither
template DB, after initdb?
No, the real-world use-case we're
Here is a patch so that the backend is linked in one piece instead of using
the SUBSYS.o files.
The question is how we want to activate that. I currently used make
BIGLINK=1, which is obviously just for testing. Should we just turn it on by
default and see if anyone complains?
--
Peter
On Fri, Feb 22, 2008 at 7:48 AM, Peter Eisentraut [EMAIL PROTECTED] wrote:
Here is a patch so that the backend is linked in one piece instead of using
the SUBSYS.o files.
The question is how we want to activate that. I currently used make
BIGLINK=1, which is obviously just for testing.
72 matches
Mail list logo
