hi,
When I read the postgresql codes, I noticed that the FunctionCallInfoData
structure(declared in the src/include/fmgr.h) contains two arrays 'arg' and
'argnull'.
Why don't you declare it as a pointer and allocate the memory from heap? It
saves more momery if 'arg' and 'argnull' declares as
On Mon, Feb 02, 2009 at 03:16:01PM +0800, Tao Ma wrote:
hi,
When I read the postgresql codes, I noticed that the FunctionCallInfoData
structure(declared in the src/include/fmgr.h) contains two arrays 'arg' and
'argnull'.
Why don't you declare it as a pointer and allocate the memory from
2009/2/2 Tao Ma feng_e...@163.com:
hi,
When I read the postgresql codes, I noticed that the FunctionCallInfoData
structure(declared in the src/include/fmgr.h) contains two arrays 'arg' and
'argnull'.
Why don't you declare it as a pointer and allocate the memory from heap? It
saves more
Bruce Momjian wrote:
Andrew Chernow wrote:
I am using a library that links with and initializes libcrypto (ie.
CRYPTO_set_locking_callback) but not SSL. This causes problems even
when using PQinitSSL(FALSE) because things like SSL_library_init(); are
not called (unless I manually call them,
well, true - but also, statically allocated table, without any predefined
size (with #DEFINE) , and no boundary check - is bad as well.
I suppose , this code is easy enough to let it be with your changes, but I
would still call it not pretty.
Well, it might merit a comment.
Actually - if
Peter Eisentraut pete...@gmx.net writes:
Andrew Dunstan wrote:
I didn't know such a thing even existed. What causes it to happen? I
agree it should be forbidden.
It was the only way to switch users before we had SET SESSION
AUTHORIZATION and SET ROLE and such. But the pg_restore man page
I wrote:
I'm almost done reviewing the patch, and will send along an updated
version shortly.
And here 'tis. I didn't commit because I have no way to test whether
I broke the Windows code path. Please test, and commit if OK.
There is an unfinished TODO item here: we really ought to make it
Gregory Stark píše v pá 30. 01. 2009 v 16:56 +:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
Zdenek Kotala wrote:
Bruce Momjian píše v pá 30. 01. 2009 v 10:41 -0500:
Well, I was thinking the new pg_class column would allow the upgrade to
verify the pre-upgrade
Robert Haas wrote:
IANAC, but that's my impression too. The simplified patch shouldn't
assume that row-level security in its current form is going to end up
getting put back in. AFAICS, there's no reason why the security ID
for tables can't be a regular attribute in pg_class, or why the
Heikki Linnakangas píše v so 31. 01. 2009 v 21:56 +0200:
Robert Haas wrote:
Ofcourse, the simplest way to me for handling type changes seems to be
to keep the old type OID reserved and have the new version of the type
with a new OID. Then the entire problem vanishes. But it was decided a
David E. Wheeler wrote:
Howdy,
Is it intentional that `LIMIT NULL` means the same as `LIMIT ALL`? If
so, I'd like to submit a patch to document it, because I've found it
useful in SQL functions:
http://justatheory.com/computers/databases/postgresql/dynamic-limit.html
Uh, I figure
On Mon, Feb 2, 2009 at 12:58 PM, Bruce Momjian br...@momjian.us wrote:
David E. Wheeler wrote:
Howdy,
Is it intentional that `LIMIT NULL` means the same as `LIMIT ALL`? If
so, I'd like to submit a patch to document it, because I've found it
useful in SQL functions:
On Feb 2, 2009, at 9:58 AM, Bruce Momjian wrote:
Is it intentional that `LIMIT NULL` means the same as `LIMIT ALL`? If
so, I'd like to submit a patch to document it, because I've found it
useful in SQL functions:
http://justatheory.com/computers/databases/postgresql/dynamic-limit.html
Uh,
Bruce Momjian br...@momjian.us wrote:
David E. Wheeler wrote:
Is it intentional that `LIMIT NULL` means the same as `LIMIT ALL`?
Uh, I figure LIMIT NULL should return no rows.
Why? Since the normal meaning of NULL is value unknown or does not
apply it would seem to be most reasonable, if
Tested and it looks good.
See
http://www.pgbuildfarm.org/cgi-bin/show_history.pl?nm=gothic_mothbr=HEAD
thanks Zdenek
Andrew Dunstan píše v po 02. 02. 2009 v 11:34 -0500:
Zdenek Kotala wrote:
Andrew Dunstan píše v ne 01. 02. 2009 v 16:38 -0500:
There is a new release of the
Bruce Momjian br...@momjian.us writes:
Uh, I figure LIMIT NULL should return no rows.
It's worked the way it does now since 7.1, and no one has complained;
in fact we've gotten bug reports when it was broken by the int8-limit
patch. So there are people depending on the behavior.
Tom Lane wrote:
I wrote:
I'm almost done reviewing the patch, and will send along an updated
version shortly.
And here 'tis.
Many many thanks. Your edits look very sensible, as always.
I didn't commit because I have no way to test whether
I broke the Windows code path. Please
Andrew Dunstan and...@dunslane.net writes:
Tom Lane wrote:
There is an unfinished TODO item here: we really ought to make it work
for tar-format archives. That's probably not hugely difficult, but
I didn't look into it, and don't think we should hold up applying the
existing patch for it.
Andrew Dunstan píše v ne 01. 02. 2009 v 16:38 -0500:
There is a new release of the buildfarm client code. It can be
downloaded from
http://pgfoundry.org/frs/download.php/2069/build-farm-3_2.tgz
I installed it on ghotic_moth and it look likes that there is problem
with other locales
Ruzsinszky Attila ruzsinszky.att...@gmail.com writes:
The situation:
We've got two machines. The source database (DB) is running on an RHEL
5.x machine
with PSQL 8.1.11. The destination DB is running on SuSE 11.0 with PSQL 8.3.x.
The mechines are relative far away each other and there is a
On Feb 2, 2009, at 10:17 AM, Tom Lane wrote:
It's worked the way it does now since 7.1, and no one has complained;
in fact we've gotten bug reports when it was broken by the int8-limit
patch. So there are people depending on the behavior.
Yeah, it's very useful. Here's a patch for the docs
On Feb 2, 2009, at 1:31 PM, Tom Lane wrote:
Ruzsinszky Attila ruzsinszky.att...@gmail.com writes:
The situation:
We've got two machines. The source database (DB) is running on an
RHEL
5.x machine
with PSQL 8.1.11. The destination DB is running on SuSE 11.0 with
PSQL 8.3.x.
The mechines
To summarize where I think we are, release-wise:
o Log streaming
hold for 8.5
o Hot standby
if committable for 8.4, fine, if not, 8.5, Heikki decides
o SE-PostgreSQL
no row-level security, if committable for 8.4, fine, if not, 8.5
o Others
We will focus on
Tom Lane wrote:
And here 'tis. I didn't commit because I have no way to test whether
I broke the Windows code path. Please test, and commit if OK.
Tested and committed.
Thanks to the people who reviewed and tested this - it was quite a
difficult piece of work, much more difficult
David E. Wheeler da...@kineticode.com writes:
On Feb 2, 2009, at 10:17 AM, Tom Lane wrote:
It's worked the way it does now since 7.1, and no one has complained;
in fact we've gotten bug reports when it was broken by the int8-limit
patch. So there are people depending on the behavior.
Yeah,
On Feb 2, 2009, at 12:43 PM, Tom Lane wrote:
Yeah, it's very useful. Here's a patch for the docs about it.
Seems to me that the SELECT reference page is a more appropriate place
for this type of detail. I've applied a patch there.
What about both? The LIMIT page is the first page I'd look
Andrew Dunstan wrote:
Still, that's not a 100% solution because of the cases where we use
reconnections to change user IDs --- the required password would
(usually) vary. It might be sufficient to forbid that case with
parallel restore, though; I think it's mostly a legacy thing anyway.
I
David E. Wheeler da...@kineticode.com writes:
On Feb 2, 2009, at 12:43 PM, Tom Lane wrote:
Seems to me that the SELECT reference page is a more appropriate place
for this type of detail. I've applied a patch there.
What about both?
We don't really have space to document every little
CVS HEAD is producing
execute.c: In function 'ecpg_store_result':
execute.c:394: warning: 'act_tuple' may be used uninitialized in this function
It looks to me like this is an actual bug, not just the compiler being
insufficiently smart to prove the variable is set before use.
Josh Berkus wrote:
Joshua, Kohei-san,
So, for 8.4: *if* we included in 8.4 a version of SEPostgres with all
features *except* row-level security, would it still be useful to the
SELinux community?
I think we're just not going to work out the headache-inducing issues
around row-level
On 2 Feb 2009, at 14:50, Robert Haas wrote:
well, true - but also, statically allocated table, without any
predefined
size (with #DEFINE) , and no boundary check - is bad as well.
I suppose , this code is easy enough to let it be with your
changes, but I
would still call it not pretty.
On Feb 2, 2009, at 1:10 PM, Tom Lane wrote:
David E. Wheeler da...@kineticode.com writes:
On Feb 2, 2009, at 12:43 PM, Tom Lane wrote:
Seems to me that the SELECT reference page is a more appropriate
place
for this type of detail. I've applied a patch there.
What about both?
We don't
On 1/30/09 5:43 PM, Josh Berkus j...@agliodbs.com wrote:
Joshua, Kohei-san,
So, for 8.4: *if* we included in 8.4 a version of SEPostgres with all
features *except* row-level security, would it still be useful to the
SELinux community?
Yes, it's definitely still useful. While many of the
We don't really have space to document every little niggling detail in
two places; if we did that, the main docs would become unreadably dense.
What, disk space? What do you mean by space?
Brain space.
...Robert
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
Andrew Dunstan wrote:
Magnus Hagander wrote:
Andrew Dunstan wrote:
Hiroshi Inoue wrote:
Eventually does the crash come from the call SetEnvironemntVariable
(.., NULL) on mingw-XP(or older?)?
I'm also interested in this issue and want to know the cause.
The debugger
Zdenek Kotala wrote:
Andrew Dunstan píše v ne 01. 02. 2009 v 16:38 -0500:
There is a new release of the buildfarm client code. It can be
downloaded from
http://pgfoundry.org/frs/download.php/2069/build-farm-3_2.tgz
I installed it on ghotic_moth and it look likes that there is
Tao Ma feng_e...@163.com writes:
When I read the postgresql codes, I noticed that the FunctionCallInfoData
structure(declared in the src/include/fmgr.h) contains two arrays 'arg' and
'argnull'.
Why don't you declare it as a pointer and allocate the memory from
heap?
Speed. We spend enough
On Mon, Feb 02, 2009 at 11:29:51AM -0200, Fernando Ike wrote:
Hi,
On Fri, Jan 30, 2009 at 3:03 PM, Fernando Ike f...@midstorm.org wrote:
Hi,,
My job, I maintainer some postgres server for clients. We have
many PL/(Java, Perl, Ruby, Python, R) and to more easy
administration, I
Hi,
On Fri, Jan 30, 2009 at 3:03 PM, Fernando Ike f...@midstorm.org wrote:
Hi,,
My job, I maintainer some postgres server for clients. We have
many PL/(Java, Perl, Ruby, Python, R) and to more easy
administration, I worked new little psql attribute to list languages
com
Euler Taveira de Oliveira wrote:
Alvaro Herrera escreveu:
New patch attached, with pg_dump support (thanks to Tom for the SQL
heads-up).
Great! We're close. Just two minor gripes:
+ char *validnsps[] = { toast };
Surely, you forgot to add a NULL at the end. Patch is
On 1 Feb 2009, at 21:35, Robert Haas wrote:
On Sun, Feb 1, 2009 at 3:25 PM, Grzegorz Jaskiewicz g...@pointblue.com.pl
wrote:
I don't like the fact that you hardcoded that here. I know that you
are
trying to pass on few calls in one go here, but still... ugly.
Well, I think you'll find
Magnus Hagander wrote:
Hmm. Actually, if I look at how things were before, I think we only
called SetEnvironmentVariable() in case we set a variable, and never if
we removed one. I'm not sure that's correct behavior, but it's
apparently non-crashing behavior. Perhaps we need to restore that
On Fri, 2009-01-23 at 12:09 -0500, Robert Haas wrote:
Could also be something like allow_connections_during_recovery.
+1 (should we say continuous recovery?)
Rather than a boolean, it seems more useful to specify a parameter that
has some additional usefulness, if we are going to have one
Andrew Dunstan wrote:
Zdenek Kotala wrote:
Andrew Dunstan píše v ne 01. 02. 2009 v 16:38 -0500:
There is a new release of the buildfarm client code. It can be
downloaded from
http://pgfoundry.org/frs/download.php/2069/build-farm-3_2.tgz
I installed it on ghotic_moth and it look
Zdenek Kotala wrote:
Andrew Dunstan píše v ne 01. 02. 2009 v 16:38 -0500:
There is a new release of the buildfarm client code. It can be
downloaded from
http://pgfoundry.org/frs/download.php/2069/build-farm-3_2.tgz
I installed it on ghotic_moth and it look likes that there is
Bruce Momjian wrote:
Robert Haas wrote:
IANAC, but that's my impression too. The simplified patch shouldn't
assume that row-level security in its current form is going to end up
getting put back in. AFAICS, there's no reason why the security ID
for tables can't be a regular attribute in
KaiGai Kohei wrote:
Why an OID? We store acl items now without a lookup table; I think
there will be at most the same number of SE-Linux entries. Also, by
using text we avoid the problem of cleaning out unreferenced pg_security
rows, improve performance (no lookups), and simplify the
Why an OID? We store acl items now without a lookup table; I think
there will be at most the same number of SE-Linux entries. Also, by
using text we avoid the problem of cleaning out unreferenced pg_security
rows, improve performance (no lookups), and simplify the code.
In addition, it
Robert Haas robertmh...@gmail.com wrote:
running this 5 times each on several queries,
dropping top and bottom results.
Running a complex query (posted in previous threads, runs about
300,000 time per day in a production web application), I got these
timings on a production quality machine
Bruce Momjian wrote:
At least, we cannot apply this scheme on the next phase (row-level)
due to the storage consumption and others. So, I don't think it is
a preferable way to design the first step without ignoring upcoming
expandability.
The big problem is that the security value on system
Kevin Grittner wrote:
Tom Lane t...@sss.pgh.pa.us wrote:
Jeff Davis pg...@j-davis.com writes:
There you see a snapshot of the table that never existed. Either
the
snapshot was taken before the UPDATE, in which case i=3 should be
included, or it was taken after the UPDATE, in which case
Teodor Sigaev teo...@sigaev.ru writes:
I'm very sorry, but v0.24 has a silly bug with not initialized value :(.
New version is attached
I looked at this a little bit --- it needs proofreading (VACUUME?).
Do we really need an additional column in pgstat table entries in
order to store something
Looked at this a bit ... do you think it's really a good idea to remove
the strategy number argument of comparePartial? The argument given in
the docs for it is that it might be needed to determine when to end the
scan, and that still seems plausible to me.
The description of extractQuery's
Bruce Momjian wrote:
KaiGai Kohei wrote:
Why an OID? We store acl items now without a lookup table; I think
there will be at most the same number of SE-Linux entries. Also, by
using text we avoid the problem of cleaning out unreferenced pg_security
rows, improve performance (no lookups), and
On Mon, Feb 2, 2009 at 8:10 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
Robert Haas robertmh...@gmail.com wrote:
running this 5 times each on several queries,
dropping top and bottom results.
Running a complex query (posted in previous threads, runs about
300,000 time per day in a
Tom Lane wrote:
Ruzsinszky Attila ruzsinszky.att...@gmail.com writes:
The DB is the same except the character coding. Source is LATIN2 and
the target DB is UTF8.
We wrote a trigger to copy the data from source to target with dblink.
The problem is the
different DB character coding! PGSQL
Joshua Brindle wrote:
The big problem is that the security value on system tables controls the
_object_ represented by the row, while on user tables the security value
represents access to the row. That is just an odd design, and why a
regular system table security value makes sense,
Bruce Momjian wrote:
The fundamental behavior above is that the S1 transaction is adding
_and_ removing rows from the S2 query's result set; S2 is seeing the
pre-query values that don't match its criteria and ignoring them and
blocking on a later row that does match its criteria. Once S1
Running a complex query (posted in previous threads, runs about
300,000 time per day in a production web application), I got these
timings on a production quality machine (4 quad CPU chips, that is 16
CPUs like this: Intel(R) Xeon(R) CPU X7350 @ 2.93GHz, 128 GB RAM, big
RAID with BBU). I
Robert Haas robertmh...@gmail.com writes:
Yikes! The impact of the patch is about what I'd expect, but the fact
that planning time has nearly tripled is... way poor.
We're going to need to see the test case, because I don't see that in
some simple tests here.
regards,
Tom, all,
In the attached patch-
* Tom Lane (t...@sss.pgh.pa.us) wrote:
* Some of the information_schema views are specified to respond to
per-column privileges; the column_privileges and columns views
certainly need work now to meet spec, and there might be others.
Done.
* It might be
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Robert Haas robertmh...@gmail.com writes:
Yikes! The impact of the patch is about what I'd expect, but the fact
that planning time has nearly tripled is... way poor.
We're going to need to see the test case, because I don't see that in
some simple
A good data set, plus complex queries against it, might be the data from
the US Census, specifically the TIGER data and the TIGER geocoder. I've
been following this thread with the intention of putting together a
large-data test set, but I just havn't found the time to yet. Right now
* Robert Haas (robertmh...@gmail.com) wrote:
I'm interested, but I need maybe a 1GB data set, or smaller. The
thing that we are benchmarking is the planner, and planning times are
related to the complexity of the database and the accompanying
queries, not the raw volume of data. (It's not
Robert Haas robertmh...@gmail.com writes:
I'm interested, but I need maybe a 1GB data set, or smaller. The
thing that we are benchmarking is the planner, and planning times are
related to the complexity of the database and the accompanying
queries, not the raw volume of data.
In fact, the
Bruce Momjian wrote:
Joshua Brindle wrote:
The big problem is that the security value on system tables controls the
_object_ represented by the row, while on user tables the security value
represents access to the row. That is just an odd design, and why a
regular system table security value
If we add a field on pg_ to store security label in text form,
it is necessary to attach a default one at the following points.
* pg_class
- InsertPgClassTuple() at heap.c
* pg_attribute
- InsertPgAttributeTuple() at heap.c
* pg_proc
- ProcedureCreate() at pg_proc.c
* pg_database
67 matches
Mail list logo
