On Wed, Aug 27, 2008 at 8:54 PM, ITAGAKI Takahiro
<[EMAIL PROTECTED]> wrote:
> Here is a contrib version of auto-explain.
> I'd like to add it the next commit-fest in September.
Here is my review:
*custom_guc_flags-0828.patch
It seems to be windows newline damaged? lots of ^M at the end of the
l
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 actual
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, i
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:
> 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:
http://cites
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
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.
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.
re
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
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 change
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
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: /
[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).
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, t
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 itsel
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 tha
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
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
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 under
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 ther
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 - us
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. "inser
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
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
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
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 4.
"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 sou
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
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 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 >1
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 loadin
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 al
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
"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
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 to_timestam
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 loo
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:
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
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 configurati
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
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_fo
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 co
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
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++ compi
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
===
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
www.pgadmin.or
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 v
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
Heikki Linnakangas napsal(a):
Zdenek Kotala wrote:
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 pgsql-
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
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 alternati
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 other
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
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 t
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 t
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 memor
> > 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)
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)
but
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]>
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 conne
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 situat
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 it
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 lef
[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
>> d
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 a
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 al
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 confu
67 matches
Mail list logo
