Hi,
I am developing a backend module for postgresql. For some queries,
postgresql crashes: segmentation fault (most probably due to my own code).
How to get the function name line number where it crashes?
isophoqote
On Thu, Dec 11, 2008 at 04:29:56PM +0800, Alif Isophoqote wrote:
Hi,
I am developing a backend module for postgresql. For some queries,
postgresql crashes: segmentation fault (most probably due to my own code).
How to get the function name line number where it crashes?
Arrange for a core
Alif Isophoqote napsal(a):
Hi,
I am developing a backend module for postgresql. For some queries,
postgresql crashes: segmentation fault (most probably due to my own code).
How to get the function name line number where it crashes?
At first it depends on your OS. On unixes you should get
On Thu, 2008-12-11 at 09:44 +0200, Heikki Linnakangas wrote:
Simon Riggs wrote:
When the WAL starts streaming the *primary* can immediately perform
synchronous replication, i.e. commit waits for transfer.
Until the standby has obtained all the missing log files, it's not
up-to-date,
2008/12/10 Pavel Stehule [EMAIL PROTECTED]:
2008/12/10 Tom Lane [EMAIL PROTECTED]:
Pavel Stehule [EMAIL PROTECTED] writes:
next argument - if we accept AS for param names, then we introduce
nonconsistent behave with SQL/XML functions.
select xmlforest(c1, c2 as foo, c3) -- there foo isn't
Simon Riggs wrote:
On Thu, 2008-12-11 at 09:44 +0200, Heikki Linnakangas wrote:
Simon Riggs wrote:
When the WAL starts streaming the *primary* can immediately perform
synchronous replication, i.e. commit waits for transfer.
Until the standby has obtained all the missing log files, it's not
Hi, Pgsql-hackers.
We would like to obtain your opinion on these two questions:
1) We wanna append possibilities into Postgres engine, and wanna get top
estimation for
size of code, cost and time of implementation.
1.1) We divide possibilities to elementary features, find analogues in already
Hi, Pgsql-hackers.
We would like to obtain your opinion on these two questions:
1) We wanna append possibilities into Postgres engine, and wanna get top
estimation for
size of code, cost and time of implementation.
1.1) We divide possibilities to elementary features, find analogues in already
On Thu, 2008-12-11 at 11:29 +0200, Heikki Linnakangas wrote:
Simon Riggs wrote:
On Thu, 2008-12-11 at 09:44 +0200, Heikki Linnakangas wrote:
Simon Riggs wrote:
When the WAL starts streaming the *primary* can immediately perform
synchronous replication, i.e. commit waits for transfer.
Hi,
On Thu, Dec 11, 2008 at 7:09 PM, Simon Riggs [EMAIL PROTECTED] wrote:
Recent changes I have requested in the architecture are:
* making archiving optional on primary, so we don't need to send WAL
data *twice*.
Agreed. I'm not so much worried about the bandwidth, but it's a lot of
Hi,
On Thu, Dec 11, 2008 at 7:09 PM, Simon Riggs [EMAIL PROTECTED] wrote:
On Thu, 2008-12-11 at 11:29 +0200, Heikki Linnakangas wrote:
Simon Riggs wrote:
On Thu, 2008-12-11 at 09:44 +0200, Heikki Linnakangas wrote:
Simon Riggs wrote:
When the WAL starts streaming the *primary* can
On Wed, 2008-12-10 at 15:06 -0500, Aidan Van Dyk wrote:
Call me think, but I'm confused... In sync rep, there *can't be* any
catchign up do do... i.e. if the slave isn't accepting the WAL the
master stops doing *anything*...
In normal/steady state, yes, you are correct. But there is more...
Bruce Momjian wrote:
Bruce Momjian wrote:
KaiGai Kohei wrote:
CREATE TABLE t (
a int,
b text
) WITH (ROW_LEVEL_ACL=ON);
Let me outline the simplest API, assuming we are using table-level
granularity for the security columns.
CREATE TABLE would support
WITH
On Thu, Dec 11, 2008 at 4:43 AM, Dmitry Turin
[EMAIL PROTECTED] wrote:
We would like to obtain your opinion on these two questions:
This is the wrong place to do it.
2) We are captivated by price of Indians,
we listened much about low quality of code, written by Indians,
we are fearing, that
On Thu, 2008-12-11 at 19:19 +0900, Fujii Masao wrote:
All I've asked for is the ability to turn on and turn back on archiving,
yes, with synchronisation so its safe.
(snip)
OK, I will add such archiving feature. My new design of archiving is as
follows.
Primary
--
I extend
Heikki Linnakangas napsal(a):
Pavan Deolasee wrote:
/*
* We don't need to lock the page, as we're only looking at a single
bit.
*/
result = (map[mapByte] (1 mapBit)) ? true : false;
Isn't this a dangerous assumption to make ? I am not so sure that even
a bit
can be read
Our code contains about 200 copies of the following code:
tuple = SearchSysCache[Copy](FOOOID, ObjectIdGetDatum(fooid), 0, 0, 0);
if (!HeapTupleIsValid(tuple))
elog(ERROR, cache lookup failed for foo %u, fooid);
This only counts elog() calls, not user-facing error messages
constructed with
On Thu, Dec 11, 2008 at 3:13 PM, Dmitry Turin
[EMAIL PROTECTED] wrote:
Hi, Pgsql-hackers.
We would like to obtain your opinion on these two questions:
1) We wanna append possibilities into Postgres engine, and wanna get top
estimation for
size of code, cost and time of implementation.
Do we really need this kind of discussion here?
On Thu, Dec 11, 2008 at 4:43 PM, Sreejesh O S [EMAIL PROTECTED] wrote:
On Thu, Dec 11, 2008 at 3:13 PM, Dmitry Turin
[EMAIL PROTECTED] wrote:
Hi, Pgsql-hackers.
We would like to obtain your opinion on these two questions:
1) We wanna
On Thu, Dec 11, 2008 at 5:24 PM, Ibrar Ahmed [EMAIL PROTECTED] wrote:
Do we really need this kind of discussion here?
Dont know. But the post would have contained more specific matters.
On Thu, Dec 11, 2008 at 4:43 PM, Sreejesh O S [EMAIL PROTECTED]
wrote:
On Thu, Dec 11, 2008 at
Hi, Jonah and Ibrar.
This is the wrong place to do it.
Seggest other place.
2) We are captivated by price of Indians,
we listened much about low quality of code, written by Indians,
we are fearing, that American company will resale implementation to Indian
subcontractor
(i.e. real
This is the wrong place to do it.
Seggest other place.
No. This topic is off-topic for the mailing list. When someone
brings up an issue that is off-topic, it is not our job to find them
another place to discuss it.
...Robert
--
Sent via pgsql-hackers mailing list
Hi, Robert.
This is the wrong place to do it.
Seggest other place.
This topic is off-topic for the mailing list.
I feel strong desire to recall you, that Pg has no concreate instructions till
now
how to hire for appending features into engine.
And of cource, there is no usefull
The following plpgsql function errors out with cvs head:
CREATE function test_assign() returns void
AS
$$ declare x int;
BEGIN
x := 9E3/2;
END
$$ LANGUAGE 'plpgsql';
postgres=# select test_assign();
ERROR: invalid input syntax for integer: 4500.
CONTEXT: PL/pgSQL function
Hello Dmitry,
you are really on wrong place.
You have to accept, so your proposals are not interesting for this
community. Because PostgreSQL is under BSD licence, you can do own
project based on PostgreSQL source code. There you can test all your
ideas - it should not be first similar project -
Hi, Pavel.
you have to show some real product, real project
Money will not be confirmed, until size of it will be known.
No IT solution can be confirmed or not, but business solution.
Budget for implementation is part of business solution.
Dmitry (SQL50, HTML60)
--
Sent via
On Thu, Dec 11, 2008 at 5:01 PM, Zdenek Kotala [EMAIL PROTECTED] wrote:
IIRC, Memory reading/writing is atomic operation. Only one CPU(hw thread)
can access to the same memory address(es)* in same time*. The question is
how compiler compile C code to assembler. But this code seems to me
Peter Eisentraut [EMAIL PROTECTED] writes:
Our code contains about 200 copies of the following code:
tuple = SearchSysCache[Copy](FOOOID, ObjectIdGetDatum(fooid), 0, 0, 0);
if (!HeapTupleIsValid(tuple))
elog(ERROR, cache lookup failed for foo %u, fooid);
...
Shouldn't we try to refactor
Pavan Deolasee napsal(a):
On Thu, Dec 11, 2008 at 5:01 PM, Zdenek Kotala [EMAIL PROTECTED] wrote:
IIRC, Memory reading/writing is atomic operation. Only one CPU(hw thread)
can access to the same memory address(es)* in same time*. The question is
how compiler compile C code to assembler. But
On Thu, Dec 11, 2008 at 7:03 PM, Zdenek Kotala [EMAIL PROTECTED] wrote:
Yes, because it is not simple write operation. You need to read byte from
memory to register, set bit and write it back. Write memory itself is atomic
but somebody could change other bits between read and write.
Yeah,
Tom Lane wrote:
If we could just move the error into SearchSysCache it might be worth
doing, but I think there are callers that need the flexibility to not
fail.
Pass a boolean flag?
--
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication,
Pavan Deolasee wrote:
On Thu, Dec 11, 2008 at 5:01 PM, Zdenek Kotala [EMAIL PROTECTED] wrote:
IIRC, Memory reading/writing is atomic operation. Only one CPU(hw thread)
can access to the same memory address(es)* in same time*. The question is
how compiler compile C code to assembler. But this
On Thu, Dec 11, 2008 at 7:15 PM, Heikki Linnakangas
[EMAIL PROTECTED] wrote:
Yeah, if we accept that bits can be bogusly set. There is scenarios where
that can happen already, but they involve crashing, not during normal
operation and clean shut down. In the future, I'd like to move in the
2008/12/11 Dmitry Turin [EMAIL PROTECTED]:
Hi, Pavel.
you have to show some real product, real project
Money will not be confirmed, until size of it will be known.
No IT solution can be confirmed or not, but business solution.
Budget for implementation is part of business solution.
I
Pavan Deolasee [EMAIL PROTECTED] writes:
On Thu, Dec 11, 2008 at 5:01 PM, Zdenek Kotala [EMAIL PROTECTED] wrote:
IIRC, Memory reading/writing is atomic operation. Only one CPU(hw thread)
can access to the same memory address(es)* in same time*. The question is
how compiler compile C code to
* Simon Riggs [EMAIL PROTECTED] [081211 05:45]:
On Wed, 2008-12-10 at 15:06 -0500, Aidan Van Dyk wrote:
Call me think, but I'm confused... In sync rep, there *can't be* any
catchign up do do... i.e. if the slave isn't accepting the WAL the
master stops doing *anything*...
In
Hi, Pavel.
Money will not be confirmed, until size of it will be known.
I though some different, First you have to show real code
show read code before hiring
develop process is based
I'm not intersting process of development in pgsql-hackers@postgresql.org now -
i'm interesting method to
* Fujii Masao [EMAIL PROTECTED] [081211 05:25]:
- standalone
The primary doesn't archive the WAL only during replication. If replication
is
not in progress, the primary archives the WAL. That is, the primary switches
the modes whenever replication starts / ends.
That scares the
Hi, Pavel.
Let me replace We by Somebody for your comprehension.
Money will not be confirmed, until size of it will be known.
I though some different, First you have to show real code
show read code before hiring
develop process is based
I'm not intersting process of development in
KaiGai Kohei wrote:
Bruce Momjian wrote:
Bruce Momjian wrote:
KaiGai Kohei wrote:
CREATE TABLE t (
a int,
b text
) WITH (ROW_LEVEL_ACL=ON);
Let me outline the simplest API, assuming we are using table-level
granularity for the security columns.
Pavan Deolasee wrote:
On Thu, Dec 11, 2008 at 7:15 PM, Heikki Linnakangas
[EMAIL PROTECTED] wrote:
Do we have any tests to prove that the VM page lock does not indeed
become a bottleneck ?
No.
I can do some if we don't have already.
Oh, yes please!
Only the first update to a page needs
Pavel Stehule wrote:
2008/12/10 Pavel Stehule [EMAIL PROTECTED]:
2008/12/10 Tom Lane [EMAIL PROTECTED]:
Pavel Stehule [EMAIL PROTECTED] writes:
next argument - if we accept AS for param names, then we introduce
nonconsistent behave with SQL/XML functions.
select xmlforest(c1, c2 as
Pavel Stehule [EMAIL PROTECTED] writes:
what do you thing about?
select fce(p1,p2,p3, SET paramname1 = val, paramname2 = val)
I'm not really seeing any redeeming social value in that. It's more
keystrokes than the other; and if you dislike AS because of possible
confusion with other usages
On Thu, 2008-12-11 at 09:27 -0500, Aidan Van Dyk wrote:
But catchup *has* to be *done* before PostgreSQL can enter sync rep.
Not true. Please reread the thread where Heikki questions that and I
reply. This was Fujii-san's idea, which I now agree with.
--
Simon Riggs
On Thu, 2008-12-11 at 09:37 -0500, Aidan Van Dyk wrote:
* Fujii Masao [EMAIL PROTECTED] [081211 05:25]:
- standalone
The primary doesn't archive the WAL only during replication. If
replication is
not in progress, the primary archives the WAL. That is, the
primary switches
the
Ah, that is a good point, that if we have security column which is
usually null then we are requiring the NULL bitmask.
Yes, I think that would not be optimal, thus I think WITH SECURITY_CONTEXT
is needed.
I sure wish others were adding ideas to this discussion.
One such idea would be,
Zeugswetter Andreas OSB sIT wrote:
Ah, that is a good point, that if we have security column which is
usually null then we are requiring the NULL bitmask.
Yes, I think that would not be optimal, thus I think WITH
SECURITY_CONTEXT is needed.
I sure wish others were adding ideas to
Tom Lane [EMAIL PROTECTED] wrote:
In any case, I'm not wedded to using AS for this, and am happy to
consider other suggestions. But = isn't acceptable.
How about using a bare equals sign (or the = characters) for
parameter assignment, but require that the parameter name be prefixed
with
* Simon Riggs [EMAIL PROTECTED] [081211 10:03]:
Sending data twice is not a requirement I ever heard expressed, nor has
the lack of ability to send it twice been voiced as a criticism for any
form of replication I'm familiar with. Ask the DRBD guys if sending data
twice is necessary or
Bruce Momjian [EMAIL PROTECTED] writes:
Let me outline the simplest API, assuming we are using table-level
granularity for the security columns.
CREATE TABLE would support
WITH (ROWACL = TRUE/FALSE);
for row-level acl and:
WITH (SECEXT = TRUE/FALSE);
for SE-Linux, with 'SECEXTL'
2008/12/11 Tom Lane [EMAIL PROTECTED]:
Pavel Stehule [EMAIL PROTECTED] writes:
what do you thing about?
select fce(p1,p2,p3, SET paramname1 = val, paramname2 = val)
I'm not really seeing any redeeming social value in that. It's more
keystrokes than the other; and if you dislike AS because
KaiGai Kohei [EMAIL PROTECTED] writes:
I have a plan to add a new field (declared as int2 relrowacl) into
pg_class to show what column stores its Row-level ACLs.
If you want the column to be hidden in the same way that system
columns are, I'm afraid this is a pretty bad idea. There are way too
On Thu, 2008-12-11 at 15:20 +0200, Dmitry Turin wrote:
Hi, Pavel.
you have to show some real product, real project
Money will not be confirmed, until size of it will be known.
No IT solution can be confirmed or not, but business solution.
Budget for implementation is part of business
* Heikki Linnakangas [EMAIL PROTECTED] [081211 10:09]:
Simon Riggs wrote:
On Thu, 2008-12-11 at 09:27 -0500, Aidan Van Dyk wrote:
But catchup *has* to be *done* before PostgreSQL can enter sync rep.
Not true. Please reread the thread where Heikki questions that and I
reply. This was
2008/12/11 Kevin Grittner [EMAIL PROTECTED]:
Tom Lane [EMAIL PROTECTED] wrote:
In any case, I'm not wedded to using AS for this, and am happy to
consider other suggestions. But = isn't acceptable.
How about using a bare equals sign (or the = characters) for
parameter assignment, but require
On Thu, 2008-12-11 at 17:07 +0200, Heikki Linnakangas wrote:
Simon Riggs wrote:
On Thu, 2008-12-11 at 09:27 -0500, Aidan Van Dyk wrote:
But catchup *has* to be *done* before PostgreSQL can enter sync rep.
Not true. Please reread the thread where Heikki questions that and I
reply.
But SE-PostgreSQL does not need its table option to control
its availability per table granuality due to its security model.
Database ACL is a kind of DAC. It allows resource owners to
set up its access rights. In other hand, SE-PostgreSQL is an
implementation of MAC. It does not allow
Bruce Momjian wrote:
The idea is that the security columns will hold an OID and the OID will
point to a row in a table that contains the security rights/ACL for the
column, with multiple rows using the same rights OID. If you change the
rights on the column the code has to check the existing
Pavel Stehule [EMAIL PROTECTED] writes:
no, it's little bit different
Default is only stored parameter value. You created two functions with
two different signatures
myfunc(int)
myfunc(int, int)
Yeah, we already bit this bullet with variadic functions --- if you have
myfunc(int,
Simon Riggs wrote:
On Thu, 2008-12-11 at 09:27 -0500, Aidan Van Dyk wrote:
But catchup *has* to be *done* before PostgreSQL can enter sync rep.
Not true. Please reread the thread where Heikki questions that and I
reply. This was Fujii-san's idea, which I now agree with.
I think the
At this point I am so confused I don't have any response.
---
KaiGai Kohei wrote:
But SE-PostgreSQL does not need its table option to control
its availability per table granuality due to its security model.
Database
Ah, that is a good point, that if we have security
column which is
usually null then we are requiring the NULL bitmask.
Yes, I think that would not be optimal, thus I think WITH
SECURITY_CONTEXT is needed.
I sure wish others were adding ideas to this discussion.
One
Bruce Momjian [EMAIL PROTECTED] writes:
Let me outline the simplest API, assuming we are using table-level
granularity for the security columns.
CREATE TABLE would support
WITH (ROWACL = TRUE/FALSE);
for row-level acl and:
WITH (SECEXT = TRUE/FALSE);
for SE-Linux, with 'SECEXTL'
Zeugswetter Andreas OSB sIT wrote:
Please reread with above correction,
and I'll also try a little differently:
Since a pg_security row already represents a combination of rights
within selinux, I do not really see why that cannot be extended to a
combination
of rowacl and selinux rights
2008/12/11 Hannu Krosing [EMAIL PROTECTED]:
On Thu, 2008-12-11 at 15:20 +0200, Dmitry Turin wrote:
Hi, Pavel.
you have to show some real product, real project
Money will not be confirmed, until size of it will be known.
No IT solution can be confirmed or not, but business solution.
On Thursday 11 December 2008 15:28:08 Tom Lane wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
Our code contains about 200 copies of the following code:
tuple = SearchSysCache[Copy](FOOOID, ObjectIdGetDatum(fooid), 0, 0, 0);
if (!HeapTupleIsValid(tuple))
elog(ERROR, cache lookup
2008/12/11 Hannu Krosing [EMAIL PROTECTED]:
On Thu, 2008-12-11 at 15:20 +0200, Dmitry Turin wrote:
Hi, Pavel.
you have to show some real product, real project
Money will not be confirmed, until size of it will be known.
No IT solution can be confirmed or not, but business solution.
I'll send another path with at least 1 and 3 fixed and hunt around
again for a header file to put this guc into.
On 10 Dec 2008, at 04:22, ITAGAKI Takahiro [EMAIL PROTECTED]
wrote:
Hello,
Gregory Stark [EMAIL PROTECTED] wrote:
Here's an update to eliminate two small bitrot conflicts.
On Thursday 11 December 2008 04:52:51 Bruce Momjian wrote:
We do have a per-row HEAP_HASOID bit, so I wonder if we can have a
HEAP_HASSEC bit too. Right now the HEAP_HASOID is controlled by the
CREATE/ALTER table;
The current patch add HEAP_HASSECURITY bit to t_infomask. :-)
When
Bruce Momjian wrote:
At this point I am so confused I don't have any response.
Are you discussing the case when we start a PostgreSQL with $PGDATA
generated by different binary?
At first, please consider the case when we start SE-PostgreSQL with
$PGDATA generated by vanilla binary.
(1) In
On Thursday 11 December 2008 17:43:38 KaiGai Kohei wrote:
In addition, I want folks to remind that the Row-level ACLs are not
designed based on SQL standards. Thus, I called it one of the enhanced
securities.
We have a lot of things in our code that are nonstandard, beyond the standard,
On Thu, Dec 11, 2008 at 8:09 PM, Heikki Linnakangas
[EMAIL PROTECTED] wrote:
I'm not sure if we should set the bits in very aggressively. If we're more
aggressive about setting the bits, it also means that we have to clear the
bits more often, increasing the likelihood of contention that you
On Thu, 2008-12-11 at 16:48 +0100, Pavel Stehule wrote:
2008/12/11 Hannu Krosing [EMAIL PROTECTED]:
On Thu, 2008-12-11 at 15:20 +0200, Dmitry Turin wrote:
Hi, Pavel.
you have to show some real product, real project
Money will not be confirmed, until size of it will be known.
No
I think there should be only *one* underlying column and that it should
be manipulable by either SQL commands or selinux. Otherwise you're
making a lie of the primary argument for having the SQL feature at all.
I agree that we're getting pretty far afield from the original
proposal, but I
On Thursday 11 December 2008 17:09:25 Tom Lane wrote:
I think there should be only *one* underlying column and that it should
be manipulable by either SQL commands or selinux. Otherwise you're
making a lie of the primary argument for having the SQL feature at all.
Well, an SQL-manipulated row
2008/12/11 Hannu Krosing [EMAIL PROTECTED]:
On Thu, 2008-12-11 at 16:48 +0100, Pavel Stehule wrote:
2008/12/11 Hannu Krosing [EMAIL PROTECTED]:
On Thu, 2008-12-11 at 15:20 +0200, Dmitry Turin wrote:
Hi, Pavel.
you have to show some real product, real project
Money will not be
Peter Eisentraut wrote:
On Thursday 11 December 2008 17:09:25 Tom Lane wrote:
I think there should be only *one* underlying column and that it should
be manipulable by either SQL commands or selinux. Otherwise you're
making a lie of the primary argument for having the SQL feature at all.
On Thursday 11 December 2008 17:04:05 Bruce Momjian wrote:
The idea is that the security columns will hold an OID and the OID will
point to a row in a table that contains the security rights/ACL for the
column, with multiple rows using the same rights OID.
That sounds somewhat scary for a
Greg Stark [EMAIL PROTECTED] writes:
A variable prefetch_pages is defined as unsigned or int
in some places. Why don't you define it only once in a header
and include the header in source files?
Just... Which header?
MHO: the header that goes with the source file that is most concerned with
Peter Eisentraut [EMAIL PROTECTED] writes:
On Thursday 11 December 2008 17:09:25 Tom Lane wrote:
I think there should be only *one* underlying column and that it should
be manipulable by either SQL commands or selinux. Â Otherwise you're
making a lie of the primary argument for having the SQL
On Thursday 11 December 2008 17:11:28 Pavel Stehule wrote:
maybe this combination should be safe
$name = or $name - ...
it's not used everywhere
Why don't you actually just implement the whole thing first using a random,
simple, and nonconflicting syntax?
Adjusting the syntax to
On Thursday 11 December 2008 18:24:54 KaiGai Kohei wrote:
Peter Eisentraut wrote:
On Thursday 11 December 2008 17:09:25 Tom Lane wrote:
I think there should be only *one* underlying column and that it should
be manipulable by either SQL commands or selinux. Otherwise you're
making a lie
Peter Eisentraut wrote:
About the error message, I find neither version to be very good. People see
these messages and don't know what to do.
I agree. People see this:
ERROR: cache lookup failure for constraint 123123123
and they think it means the same as this:
ERROR: cache lookup
2008/12/11 Peter Eisentraut [EMAIL PROTECTED]:
On Thursday 11 December 2008 17:11:28 Pavel Stehule wrote:
maybe this combination should be safe
$name = or $name - ...
it's not used everywhere
Why don't you actually just implement the whole thing first using a random,
simple, and
Peter Eisentraut wrote:
On Thursday 11 December 2008 17:04:05 Bruce Momjian wrote:
The idea is that the security columns will hold an OID and the OID will
point to a row in a table that contains the security rights/ACL for the
column, with multiple rows using the same rights OID.
That
On Thu, Dec 11, 2008 at 4:29 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Greg Stark greg.st...@enterprisedb.com writes:
A variable prefetch_pages is defined as unsigned or int
in some places. Why don't you define it only once in a header
and include the header in source files?
Just... Which
On Thursday 11 December 2008 18:32:50 Tom Lane wrote:
How can we stick all of these in the same column at the same time?
Why would we want to?
Because we want to use SQL-based row access control and SELinux-based row
access control at the same time. Isn't this exactly one of the objections
Robert Haas robertmh...@gmail.com writes:
Ah, that makes sense. Here's a test case based on Greg's. This is
definitely more than linear once you get above about n = 80, but it's
not quadratic either. n = 1000 is only 43x n = 80, and while that's
surely more than 1000/80 = 12.5, it's also a
Peter Eisentraut pete...@gmx.net writes:
On Thursday 11 December 2008 18:32:50 Tom Lane wrote:
How can we stick all of these in the same column at the same time?
Why would we want to?
Because we want to use SQL-based row access control and SELinux-based row
access control at the same
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
Let me outline the simplest API, assuming we are using table-level
granularity for the security columns.
CREATE TABLE would support
WITH (ROWACL = TRUE/FALSE);
for row-level acl and:
WITH (SECEXT = TRUE/FALSE);
for
BTW, does anyone have an opinion about changing the upper limit for
default_stats_target to, say, 1? These tests suggest that you
wouldn't want such a value for a column used as a join key, but
I can see a possible argument for high values in text search and
similar applications.
Do
Vladimir Sitnikov sitnikov.vladi...@gmail.com writes:
Do you consider using hash tables?
Doubt it's really worth it, unless there's some way to amortize the
setup cost across multiple selectivity estimations; which would surely
complicate life.
One thing that just now occurred to me is that as
When looking at these numbers one might think the threshold of pain
is about 50, rather than 100 which is where I'd put it for the text
example. However, this is probably an extreme worst case.
On the whole I think we have some evidence here to say that upping the
default value of
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
Le 11 déc. 08 à 16:22, Tom Lane a écrit :
Yeah, we already bit this bullet with variadic functions --- if you
have
myfunc(int, float)
myfunc(int, variadic float[])
then it's ambiguous which one should be used for call
Do you consider using hash tables?
Doubt it's really worth it, unless there's some way to amortize the
setup cost across multiple selectivity estimations; which would surely
complicate life.
MCV lists are updated only during analyze phase, don't they? If the setup
cost is the cost of
Peter Eisentraut pete...@gmx.net writes:
On Thursday 11 December 2008 18:32:50 Tom Lane wrote:
How can we stick all of these in the same column at the same time?
Why would we want to?
Because we want to use SQL-based row access control and SELinux-based row
access control at the same
* Gregory Stark st...@enterprisedb.com [081211 14:47]:
Peter Eisentraut pete...@gmx.net writes:
On Thursday 11 December 2008 18:32:50 Tom Lane wrote:
How can we stick all of these in the same column at the same time?
Why would we want to?
Because we want to use SQL-based row access
On Thu, Dec 11, 2008 at 2:06 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Vladimir Sitnikov sitnikov.vladi...@gmail.com writes:
Do you consider using hash tables?
Doubt it's really worth it, unless there's some way to amortize the
setup cost across multiple selectivity estimations; which would
Dimitri Fontaine dfonta...@hi-media.com writes:
The sanest answer I can see is so, don't do that.
Is there any warning level message at CREATE FUNCTION time for the
user/dba to know he's doing something... border line, almost shooting
himself in the foot?
It's not that easy to produce a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Le 11 déc. 08 à 21:23, Tom Lane a écrit :
It's not that easy to produce a message that wouldn't be annoying
noise.
Something really amazing in PostgreSQL is the HINTs system in error
messages. Almost all the time thoses messages are focused and
1 - 100 of 169 matches
Mail list logo
