In libpq, the definition is like:
PGresult *
PQprepare(PGconn *conn,
const char *stmtName, const char *query,
int nParams, const Oid *paramTypes)
Could we remove the parameter nParams?
e.g. insert into foo(id, name, address) values ($1, $2, $3)
PostgreSQL possibly can parse the prepared
Robert Haas wrote:
I think you have to resign yourself to the fact that a user who can
see only a subset of the rows in a table may very well see apparent
foreign-key violations. But so what?
So you're leaking information about the rows that they're not supposed
to be able to see. This is not
Well, the PGACE documentation says:
http://code.google.com/p/sepgsql/wiki/WhatIsPGACE
Datum pgacePreparePlanCheck(Relation rel)
In the latest patch, this hooks is replaced by pgaceBeginPerformCheckFK()
and pgaceEndPerformCheckFK(), but its purpose is unchanged.
Sorry for the
Andrew Dunstan wrote:
Attached is my WIP patch for parallel pg_restore. It's still very rough,
but seems to work.
Anyone who can test this with highend equipment would be helping some.
tried playing with this(on a 22Gb compressed dump using 4 connections)
but it does not seem to work at
On Thu, 2008-09-25 at 18:28 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
Version 7
Anyway, that's sufficiently bad that I'm bouncing the patch for
reconsideration.
No problem, I understand this needs discussion.
There's less detail here than first appears. There are
[EMAIL PROTECTED] (Gevik Babakhani) writes:
Advantage of C++ is that it reduce lot of OO code written in
C in PostgreSQL, but it is so big effort to do that without
small gain. It will increase number of bugs. Do not forget
also that C++ compiler is not so common (so good) on
different
Alvaro Herrera wrote:
Tom Lane wrote:
I think adding a subobject column to pg_shdepend is probably the best
answer --- we only didn't do that to start with because we thought it
wasn't needed.
Yep. I did consider adding it, but there was no use for it at the time
so I just left it out.
Hi,
As I'm interested in this topic, I thought I'd take a look at the
patch. I have no capability to test it on high end hardware but did
some basic testing on my workstation and basic review of the patch.
I somehow had the impression that instead of creating a new connection
for each restore
On Fri, 2008-09-26 at 11:20 +0100, Simon Riggs wrote:
After reading this for awhile, I realized that there is a rather
fundamental problem with it: it switches into consistent recovery
mode as soon as it's read WAL beyond ControlFile-minRecoveryPoint.
In a crash recovery situation that
Russell Smith wrote:
Hi,
As I'm interested in this topic, I thought I'd take a look at the
patch. I have no capability to test it on high end hardware but did
some basic testing on my workstation and basic review of the patch.
I somehow had the impression that instead of creating a new
So what have we decided about this suggestion. Should I submit the
patch or just forget about it? So far some people like it and some
people think that it is unneccessary. No one so far has suggested that
it would harm the system or people's use of it.
--
D'Arcy J.M. Cain [EMAIL PROTECTED]
Stefan Kaltenbrunner wrote:
Andrew Dunstan wrote:
Attached is my WIP patch for parallel pg_restore. It's still very
rough, but seems to work.
Anyone who can test this with highend equipment would be helping some.
tried playing with this(on a 22Gb compressed dump using 4 connections)
We already have an optional OID system column that can be specified
during table creation (WITH OIDS). We could have another optional oid
column (WITH ROW SECURITY) called security_context which would store the
oid of the role that can see the row; if the oid is zero (InvalidOid),
A
Andrew Dunstan wrote:
Do we know why we experience tuple concurrently updated errors if we
spawn thread too fast?
No. That's an open item.
Okay, I'll see if I can have a little more of a look into it. No
promises as the restore the restore isn't playing nicely.
the memory context is
Heikki Linnakangas napsal(a):
Zdenek Kotala wrote:
Attached is a new version, now with WAL-logging of the FSM truncation. I
decided to go with the separate WAL record for that, rather than
piggybacking on the smgrtruncate's WAL record. It seems much better from
a modularity point of view
iihero [EMAIL PROTECTED] writes:
In libpq, the definition is like:
PGresult *
PQprepare(PGconn *conn,
const char *stmtName, const char *query,
int nParams, const Oid *paramTypes)
Could we remove the parameter nParams?
No. We are not going to break every existing user of the
Zdenek Kotala wrote:
I performed performance test (iGEN) on SUN x4600 with 60 concurrent
users and see result:
...
I don't see any big difference. Throughput is similar. Only response
time seems to be better with your last FSM version.
I personally happy with performance.
Thanks! I've
Russell Smith wrote:
I'm sorry, I meant processes there. I'm aware there are no threads.
But my feeling was that when you forked with open files you got all of
the open file properties, including positions, and as you dupped the
descriptor, you share all that it's pointing to with every
On Thu, Sep 25, 2008 at 08:57:46PM -0400, Tom Lane wrote:
Another point is that the proposed behavior leaks quite a lot of
information, since it will fail operations on the basis of tuples that
supposedly aren't visible to the invoking user. While I admit that it's
hard to see an alternative
On Thu, Sep 25, 2008 at 10:32:24PM -0400, Tom Lane wrote:
I can't escape the lurking suspicion that some bright folk inside the
NSA have spent years thinking about this and have come up with some
reasonably self-consistent definition of row hiding in a SQL database.
But have they published it
Heikki Linnakangas napsal(a):
Zdenek Kotala wrote:
snip
I've also tried various pgbench tests, on a RAM disk and otherwise, as
well as the table population test I ran earlier, and don't see any
difference in performance.
I think performance is OK
Zdenek
--
Sent via
Andrew Sullivan [EMAIL PROTECTED] writes:
The above point, and other similar ones in every discussion of the
proposed functionality, makes me think once again either that the
requirements for this feature aren't understood by everyone, or else
that they're not actually explicit enough. I have
Zeugswetter Andreas OSB sIT wrote:
anyone can see it. SE-PostgreSQL would default to WITH ROW SECURITY and
use the oid to look up strings in pg_security.
The above explanation is not correct, as Tom mentioned.
The security system column is declared as TEXT type, however, every tuple
has a Oid
The sysadmin team would like to announce a planned maintenance window
for OS related updates on tribble.postgresql.org starting Sunday Sep 28
07:00 GMT (espected to last for an hour) affecting the following
publically visible services:
cvs.postgresql.org
wwwmaster.postgresql.org
This version of the patch should fix the shared file descriptor bug
Russell Smith noticed. It also disables the 1/2 second sleep between
forks, so the performance on a small db (regression) is vastly improved.
cheers
andrew
Index: pg_backup.h
On Sep 25, 2008, at 5:50 PM, Chris Browne wrote:
[EMAIL PROTECTED] (Gevik Babakhani) writes:
Advantage of C++ is that it reduce lot of OO code written in
C in PostgreSQL, but it is so big effort to do that without
small gain. It will increase number of bugs. Do not forget
also that C++
A.M. wrote:
Speaking of language choice, no one said that _all_ the source code
would need to be rewritten. It would be nice, for example, if
PostgreSQL rewrote the current GUC system with a glue language like
Lua (which is also very C-like).
No it wouldn't. All it would mean is that
I'm currently playing with Andrews parallel restore patch and it seems
that pg is far from taking advantage of the hardware I have for testing
(Dual Quad Core Xeon attached to Netapp with 68 spindles). with a
concurrency of 4 - I see iowait hovering ~1% CPU load at 20% peak and
around 15
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
samples %symbol name
1933314 21.8884 LWLockAcquire
1677808 18.9957 XLogInsert
8482279.6034 LWLockRelease
4141794.6892 DoCopy
3326333.7660 CopyReadLine
2665803.0181 UnpinBuffer
2216932.5099 heap_formtuple
Tom Lane wrote:
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
samples %symbol name
1933314 21.8884 LWLockAcquire
1677808 18.9957 XLogInsert
8482279.6034 LWLockRelease
4141794.6892 DoCopy
3326333.7660 CopyReadLine
2665803.0181 UnpinBuffer
2216932.5099
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
I suppose Andrew didn't yet put in the hack to avoid WAL logging
Yes I did. That's what the --truncate-before-load switch does (or should
do).
Well, it doesn't seem to be having any effect. Maybe Stefan is testing
a configuration
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
I suppose Andrew didn't yet put in the hack to avoid WAL logging
Yes I did. That's what the --truncate-before-load switch does (or should
do).
Well, it doesn't seem to be having any effect. Maybe Stefan is testing
a
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
heh no log archiving - I actually said that I'm now playing with
--truncate-before-load which seems to cause a noticeable performance (as
in IO generated) increase but I still see 13 context switches/s and
a profile that looks like:
Tom Lane wrote:
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
heh no log archiving - I actually said that I'm now playing with
--truncate-before-load which seems to cause a noticeable performance (as
in IO generated) increase but I still see 13 context switches/s and
a profile that looks
Hey folks,
Tom pointed out in the parent thread [1] that the error message for
bogus AM/PM markers in to_timestamp is pretty lame:
ERROR: invalid AM/PM string
I agree, and once I started thinking about this, I came up with other
gripes concerning the treatment of 12-hour time in
Brendan Jurd [EMAIL PROTECTED] writes:
One way to tidy this up would be to re-implement the meridiem markers
using the seq_search functions, i.e., make it work like the day and
month names. This would make it easy to accept any flavour of marker,
and the error messages thrown for bogus input
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
that one generates a huge amount of logs - output for ~60s into the load
is available here:
http://www.kaltenbrunner.cc/files/lwstats.txt (21MB!)
Huh ... essentially all the contention is for OidGenLock. I take it
you're loading into a table
On Fri, Sep 26, 2008 at 11:52 AM, Andrew Dunstan [EMAIL PROTECTED] wrote:
Speaking of language choice, no one said that _all_ the source code would
need to be rewritten. It would be nice, for example, if PostgreSQL rewrote
the current GUC system with a glue language like Lua (which is also very
Tom Lane wrote:
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
that one generates a huge amount of logs - output for ~60s into the load
is available here:
http://www.kaltenbrunner.cc/files/lwstats.txt (21MB!)
Huh ... essentially all the contention is for OidGenLock. I take it
you're loading
On Fri, 2008-09-26 at 12:38 -0400, Tom Lane wrote:
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
heh no log archiving - I actually said that I'm now playing with
--truncate-before-load which seems to cause a noticeable performance (as
in IO generated) increase but I still see 13
Simon Riggs [EMAIL PROTECTED] writes:
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
samples %symbol name
5552616.5614 LWLockAcquire
29721 8.8647 DoCopy
26581 7.9281 CopyReadLine
25105 7.4879 LWLockRelease
15743 4.6956 PinBuffer
14725 4.3919
On Fri, Sep 26, 2008 at 11:25 AM, Brendan Jurd [EMAIL PROTECTED] wrote:
One way to tidy this up would be to re-implement the meridiem markers
using the seq_search functions, i.e., make it work like the day and
month names. This would make it easy to accept any flavour of marker,
and the error
Alex Hunsaker [EMAIL PROTECTED] writes:
However that still leaves the original complaint around (at least IMHO):
select to_timestamp('AN', 'AM');
ERROR: invalid AM/PM string
select to_timestamp('11:47 PM 27 Sep a2008', 'HH:MI PM DD Mon ');
ERROR: invalid value for in source string
Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
samples %symbol name
5552616.5614 LWLockAcquire
29721 8.8647 DoCopy
26581 7.9281 CopyReadLine
25105 7.4879 LWLockRelease
15743 4.6956 PinBuffer
14725
On Fri, 2008-09-26 at 14:00 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
samples %symbol name
5552616.5614 LWLockAcquire
29721 8.8647 DoCopy
26581 7.9281 CopyReadLine
25105 7.4879
On Fri, Sep 26, 2008 at 2:45 AM, iihero [EMAIL PROTECTED] wrote:
In libpq, the definition is like:
PGresult *
PQprepare(PGconn *conn,
const char *stmtName, const char *query,
int nParams, const Oid *paramTypes)
Could we remove the parameter nParams?
e.g. insert into foo(id, name,
On Fri, 2008-09-26 at 20:07 +0200, Stefan Kaltenbrunner wrote:
Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
samples %symbol name
5552616.5614 LWLockAcquire
29721 8.8647 DoCopy
26581 7.9281 CopyReadLine
Merlin Moncure wrote:
On Fri, Sep 26, 2008 at 2:45 AM, iihero [EMAIL PROTECTED] wrote:
In libpq, the definition is like:
PGresult *
PQprepare(PGconn *conn,
const char *stmtName, const char *query,
int nParams, const Oid *paramTypes)
Could we remove the parameter nParams?
e.g. insert
Andrew Dunstan wrote:
This version of the patch should fix the shared file descriptor bug
Russell Smith noticed. It also disables the 1/2 second sleep between
forks, so the performance on a small db (regression) is vastly improved.
this works better but there is something fishy still -
Stefan Kaltenbrunner wrote:
Andrew Dunstan wrote:
This version of the patch should fix the shared file descriptor bug
Russell Smith noticed. It also disables the 1/2 second sleep between
forks, so the performance on a small db (regression) is vastly improved.
this works better but there
On Fri, 26 Sep 2008 17:10:44 -0400
Andrew Dunstan [EMAIL PROTECTED] wrote:
Yes, there are several funny things going on, including some stuff
with dependencies. I'll have a new patch tomorrow with luck. Thanks
for testing.
O.k. I took at look at the patch itself and although I don't
Dear colleagues,
I said earlier I'd ask around about some of the literature on security
controls vs. databse accessibility and side channels. I did, and I
heard back.
One person told me that this conference often has things on this
topic:
http://www.ieee-security.org/TC/SP-Index.html
From my
KaiGai Kohei wrote:
SE-PostgreSQL needs to be good enough for the NSA, but row-level
security in general does not.
BTW, it seems to me someone misunderstand I works as an agent of NSA.
Is it a humor, itn't it? I've paid my effort to improve the security
of open source software, not for
Tom Lane wrote:
Robert Haas [EMAIL PROTECTED] writes:
I think you have to resign yourself to the fact that a user who can
see only a subset of the rows in a table may very well see apparent
foreign-key violations. But so what?
So you're leaking information about the rows that they're
Joshua Drake wrote:
On Fri, 26 Sep 2008 17:10:44 -0400
Andrew Dunstan [EMAIL PROTECTED] wrote:
Yes, there are several funny things going on, including some stuff
with dependencies. I'll have a new patch tomorrow with luck. Thanks
for testing.
O.k. I took at look at the patch itself
Bruce Momjian [EMAIL PROTECTED] writes:
I am confused how knowing that a sequence number used for a primary key
exists or doesn't exist is leaking _meaningful_ information. People
might know the sequence number exists, but how is that information
useful. Now, if natural keys are used, that
[EMAIL PROTECTED] (Andrew Dunstan) writes:
A.M. wrote:
Speaking of language choice, no one said that _all_ the source code
would need to be rewritten. It would be nice, for example, if
PostgreSQL rewrote the current GUC system with a glue language like
Lua (which is also very C-like).
No it
Tom Lane wrote:
I think it's just a bug in 8.3.
Well, here's a patch that I think fixes it. If you're happy I'll apply
it to HEAD and 8.3.
cheers
andrew
? .deps
Index: like_match.c
===
RCS file:
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
I think it's just a bug in 8.3.
Well, here's a patch that I think fixes it. If you're happy I'll apply
it to HEAD and 8.3.
That patch isn't gonna apply to HEAD ;-). Also the introduction of
NextChar is simply broken, as it will skip
At 2008-09-22 12:54:34 -0500, [EMAIL PROTECTED] wrote:
can we tell there is consensus in create a new has_sequence_privilege()?
Abhijit will you make it? if not i can make a try...
Yes, I'll do it.
-- ams
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
I think it's just a bug in 8.3.
Well, here's a patch that I think fixes it. If you're happy I'll apply
it to HEAD and 8.3.
That patch isn't gonna apply to HEAD ;-). Also the introduction of
Andrew Dunstan [EMAIL PROTECTED] writes:
I'll have another look. What happens in that case though if you have
escape+x where x is a multibyte char?
TCHAR()'s just a no-op in multibyte encodings --- we handle ILIKE
using a preliminary downcasing pass in that case.
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
I'll have another look. What happens in that case though if you have
escape+x where x is a multibyte char?
TCHAR()'s just a no-op in multibyte encodings --- we handle ILIKE
using a preliminary downcasing pass in that case.
On Sat, Sep 27, 2008 at 4:08 AM, Tom Lane [EMAIL PROTECTED] wrote:
Alex Hunsaker [EMAIL PROTECTED] writes:
However that still leaves the original complaint around (at least IMHO):
select to_timestamp('AN', 'AM');
ERROR: invalid AM/PM string
select to_timestamp('11:47 PM 27 Sep a2008',
The literature pointers that Andrew just gave us seem promising to me.
Who's going to go searching for some useful info?
I couldn't find much on the pages linked directly from the link Andrew
sent, but a Google search for site:ieee-security.org database turned
up the following:
On Fri, Sep 26, 2008 at 06:15:46PM -0400, Bruce Momjian wrote:
I am confused how knowing that a sequence number used for a primary key
exists or doesn't exist is leaking _meaningful_ information.
This sort of side-channel intelligence is _exactly_ how certain kinds
of security exploits work:
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
I am confused how knowing that a sequence number used for a primary key
exists or doesn't exist is leaking _meaningful_ information. People
might know the sequence number exists, but how is that information
useful. Now, if natural
Tom Lane wrote:
Andrew Sullivan [EMAIL PROTECTED] writes:
The above point, and other similar ones in every discussion of the
proposed functionality, makes me think once again either that the
requirements for this feature aren't understood by everyone, or else
that they're not actually
68 matches
Mail list logo
