Hi,
Thanks. Now it works.
Few questions:
1) Do you have an idea by when the Hot standby patch and Sync
replication patch will be integrated?
2) I have used 1 physical machine to try current patch of synchronous
replication. Is it OK for me to try with 2 separate machines for Primary
Standby
Hi,
I need SE-PostgreSQL *ONLY* for row level security, but AFAIK
SE-PostgreSQL
works only on SELinux. This, for me, is unacceptable, because I want to use
row level security on windows too. I don't need all that fancy security
stuffs.
I want to share with you my security experience,
On Sun, 2009-02-08 at 11:51 -0500, Tom Lane wrote:
Now, if you want to argue that we should get rid of SET WITHOUT OIDS
altogether, I'm not sure I could dispute it. But if we have the
ability
to do that ISTM we should offer the reverse too.
We should keep the ability to have OIDs. Some
BogDan, Thanks for your interesting.
At first, I would like to confirm whether you know the row-level security
feature is postponed to v8.5, or not. Thus, the latest patch set (toward
v8.4 development cycle) does not contain the row-level one.
Please note that the following my comments assume
Thanks for your feedback, Emmanuel.
Here are my comments:
On 2/10/09, Emmanuel Cecchet m...@frogthinker.org wrote:
Hi Amit,
I will be traveling until next Tuesday and will have no access to email so
don't be surprised if I don't follow up this week.
The overall approach seems sound. The
ITAGAKI Takahiro escreveu:
1. fillfactor.* options are silently ignored when the table doesn't have
toast relation. Should we notice the behabior to users?
ex. NOTICE: toast storage parameters are ignored
because the table doesn't have toast relations.
It was discussed
Tatsuo Ishii wrote:
Hi,
Is there any way to stop autovacuum temporarily?(other than edit
postgresql.conf and reload it)
Hmm, no, that's the only way.
I'm not sure that this calls for a change in autovacuum itself; it seems
to be that whatwe really need is the ability to change
ITAGAKI Takahiro wrote:
I tested this changes and found two issues:
1. fillfactor.* options are silently ignored when the table doesn't have
toast relation. Should we notice the behabior to users?
ex. NOTICE: toast storage parameters are ignored
because the table
I'm currently testing HotStandby v9g.
Seems like this patch version misses to update guc.c, which still
references XLOG_DEBUG when compiled with WAL_DEBUG. This got replaced with
XLOG_DEBUG_FLUSH, *_BGFLUSH and *_REDO, resulting in a compile error. Maybe
we want to reflect those changes with
Andrew Chernow wrote:
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
Hi Robert,
I am a little fuzzy on what you're proposing here, but I think you're
saying that you're only going to support range partitioning on
integers or dates and that you plan to use the text type to store the
integer or date values. FWIW, those don't seem like very good
decisions
On Tue, Feb 10, 2009 at 9:32 AM, Magnus Hagander mag...@hagander.net wrote:
How we worked around it:
We solved it by copying the SSL init sequence from fe-secure.c. Doesn't
seem like something that would change very often. So we
init_our_library(), PQinitSSL(0) and then do a few lines of SSL
Merlin Moncure wrote:
On Tue, Feb 10, 2009 at 9:32 AM, Magnus Hagander mag...@hagander.net wrote:
How we worked around it:
We solved it by copying the SSL init sequence from fe-secure.c. Doesn't
seem like something that would change very often. So we
init_our_library(), PQinitSSL(0) and
Simon Riggs si...@2ndquadrant.com writes:
But the ability to turn this on/off is not an important one, since even
the people who use OIDs seldom use this. They have CTAS; let them use
it.
Well, CTAS is a vastly inferior solution because you'd have to manually
move indexes, constraints, FKs,
maybe invent a special value to PQinitSSL for ssl only init?
We could do that, I guess. However, if an application passes this in to
an old version of libpq, there is no way to know that it didn't know
about it.
Well, you could create PQinitSSLExtended, but, as you say, the use
case is
Robert Haas robertmh...@gmail.com writes:
We could do that, I guess. However, if an application passes this in to
an old version of libpq, there is no way to know that it didn't know
about it.
Well, you could create PQinitSSLExtended, but, as you say, the use
case is pretty narrow...
It
Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
We could do that, I guess. However, if an application passes this in to
an old version of libpq, there is no way to know that it didn't know
about it.
Well, you could create PQinitSSLExtended, but, as you say, the use
case is pretty
On Tue, Feb 10, 2009 at 10:54 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
We could do that, I guess. However, if an application passes this in to
an old version of libpq, there is no way to know that it didn't know
about it.
Well, you could create
Robert Haas robertmh...@gmail.com writes:
Well, you could create PQinitSSLExtended, but, as you say, the use
case is pretty narrow...
It would help if there were a PQgetLibraryVersion() function.
Help how? There is nothing an app can do to work around the problem
AFAICS. Or if there were,
Magnus Hagander wrote:
Merlin Moncure wrote:
On Tue, Feb 10, 2009 at 9:32 AM, Magnus Hagander mag...@hagander.net
wrote:
How we worked around it:
We solved it by copying the SSL init sequence from fe-secure.c. Doesn't
seem like something that would change very often. So we
On Tue, Feb 10, 2009 at 11:14 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Well, you could create PQinitSSLExtended, but, as you say, the use
case is pretty narrow...
It would help if there were a PQgetLibraryVersion() function.
Help how? There is nothing
Tom Lane wrote:
If that's all you want, then PQinitSSLExtended is a perfectly good
answer.
How about PQinitCrypto(bool do_init), which would default to TRUE if
never called. PQinitSSL already handles the SSL part, just need control
over initializing crypto.
--
Andrew Chernow
eSilo,
Andrew Chernow wrote:
Tom Lane wrote:
If that's all you want, then PQinitSSLExtended is a perfectly good
answer.
How about PQinitCrypto(bool do_init), which would default to TRUE if
never called. PQinitSSL already handles the SSL part, just need control
over initializing
User Bmomjian wrote:
Log Message:
---
Add support for specifying port numbers.
Hmm, I suppose we can't readily run pg_dump against a stand-alone backend?
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list
Robert Haas wrote:
Would someone remind me why turning off ssl initialization in libpq does
not work for this case?
That initializes both libcrypto and libssl. The problem arises when
libcrypto has been initialized but libssl has not.
So initialize ssl in your application? What is the
On Tue, Feb 10, 2009 at 11:52 AM, Bruce Momjian br...@momjian.us wrote:
Robert Haas wrote:
Would someone remind me why turning off ssl initialization in libpq does
not work for this case?
That initializes both libcrypto and libssl. The problem arises when
libcrypto has been initialized
Heikki Linnakangas wrote:
User Bmomjian wrote:
Log Message:
---
Add support for specifying port numbers.
Hmm, I suppose we can't readily run pg_dump against a stand-alone backend?
I am confused by the question; we used to default to the 5432 port
numbers.
--
Bruce Momjian
Merlin Moncure wrote:
On Tue, Feb 10, 2009 at 11:52 AM, Bruce Momjian br...@momjian.us wrote:
Robert Haas wrote:
Would someone remind me why turning off ssl initialization in libpq does
not work for this case?
That initializes both libcrypto and libssl. The problem arises when
On Tue, Feb 10, 2009 at 11:14 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Well, you could create PQinitSSLExtended, but, as you say, the use
case is pretty narrow...
It would help if there were a PQgetLibraryVersion() function.
Help how? There is nothing
Bruce Momjian wrote:
Heikki Linnakangas wrote:
User Bmomjian wrote:
Log Message:
---
Add support for specifying port numbers.
Hmm, I suppose we can't readily run pg_dump against a stand-alone backend?
I am confused by the question; we used to default to the 5432 port
numbers.
I
On Tue, Feb 10, 2009 at 11:54 AM, Bruce Momjian br...@momjian.us wrote:
Merlin Moncure wrote:
On Tue, Feb 10, 2009 at 11:52 AM, Bruce Momjian br...@momjian.us wrote:
Robert Haas wrote:
Would someone remind me why turning off ssl initialization in libpq does
not work for this case?
On Tue, Feb 10, 2009 at 4:57 PM, Merlin Moncure mmonc...@gmail.com wrote:
PQinitSSL is *broken*. It's always been broken. Since it already
takes a parameter, I say add a special switch...the backwards
compatibility danger doesn't seem too bad.
Add a switch to what? I get very nervous for
Bruce Momjian wrote:
Andrew Chernow wrote:
Tom Lane wrote:
If that's all you want, then PQinitSSLExtended is a perfectly good
answer.
How about PQinitCrypto(bool do_init), which would default to TRUE if
never called. PQinitSSL already handles the SSL part, just need control
over
On Tue, Feb 10, 2009 at 12:03 PM, Dave Page dp...@pgadmin.org wrote:
On Tue, Feb 10, 2009 at 4:57 PM, Merlin Moncure mmonc...@gmail.com wrote:
PQinitSSL is *broken*. It's always been broken. Since it already
takes a parameter, I say add a special switch...the backwards
compatibility danger
Heikki Linnakangas wrote:
Bruce Momjian wrote:
Heikki Linnakangas wrote:
User Bmomjian wrote:
Log Message:
---
Add support for specifying port numbers.
Hmm, I suppose we can't readily run pg_dump against a stand-alone backend?
I am confused by the question; we used to
On Tue, Feb 10, 2009 at 12:03 PM, Merlin Moncure mmonc...@gmail.com wrote:
On Tue, Feb 10, 2009 at 11:54 AM, Bruce Momjian br...@momjian.us wrote:
Merlin Moncure wrote:
On Tue, Feb 10, 2009 at 11:52 AM, Bruce Momjian br...@momjian.us wrote:
Robert Haas wrote:
Would someone remind me why
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
I was thinking that we could sidestep the whole port number question if
we didn't try to start up postmaster, and used a stand-alone backend (
postgres --single) instead.
That would be a good place to get to eventually, but I
On Tue, Feb 10, 2009 at 5:05 PM, Merlin Moncure mmonc...@gmail.com wrote:
PQinitSSL(SSL_ONLY) or something, where the constant is carefully
chosen to not be accidentally passed in by older libpq users.
Ahh, OK. That would be painless.
--
Dave Page
EnterpriseDB UK:
Tom Lane wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
I was thinking that we could sidestep the whole port number question if
we didn't try to start up postmaster, and used a stand-alone backend (
postgres --single) instead.
That would be a good place to get to
Merlin Moncure wrote:
On Tue, Feb 10, 2009 at 12:03 PM, Dave Page dp...@pgadmin.org wrote:
On Tue, Feb 10, 2009 at 4:57 PM, Merlin Moncure mmonc...@gmail.com wrote:
PQinitSSL is *broken*. It's always been broken. Since it already
takes a parameter, I say add a special switch...the backwards
On Tue, Feb 10, 2009 at 1:02 PM, Magnus Hagander mag...@hagander.net wrote:
Merlin Moncure wrote:
On Tue, Feb 10, 2009 at 12:03 PM, Dave Page dp...@pgadmin.org wrote:
On Tue, Feb 10, 2009 at 4:57 PM, Merlin Moncure mmonc...@gmail.com wrote:
PQinitSSL is *broken*. It's always been broken.
On Tue, 2009-02-10 at 15:17 +0100, Bernd Helmle wrote:
I'm currently testing HotStandby v9g.
Seems like this patch version misses to update guc.c, which still
references XLOG_DEBUG when compiled with WAL_DEBUG. This got replaced with
XLOG_DEBUG_FLUSH, *_BGFLUSH and *_REDO, resulting in a
I wrote (in response to Kevin Grittner's recent issues):
Reflecting on this further, I suspect there are also some bugs in the
planner's rules about when semi/antijoins can commute with other joins;
After doing some math I've concluded this is in fact the case. Anyone
want to check my work?
With the new snapshot maintenance code, it looks like we can advance the
xmin more aggressively.
For instance:
S1:
INSERT INTO foo VALUES(1);
S2:
BEGIN;
DECLARE c1 CURSOR FOR SELECT i FROM foo;
S1:
DELETE FROM foo;
S2:
DECLARE c2 CURSOR FOR SELECT i FROM foo;
CLOSE c1;
S1:
VACUUM VERBOSE
ITAGAKI Takahiro wrote:
2. psql's \d+ doesn't show toast storage parameters.
Neither \d+ for base tables nor toast relations show toast.* parameters
though there are some values in pg_class.reloptions.
I think we should show toast.* parameters in \d+ for base tables
because it has
Hi,
Le 10 févr. 09 à 21:10, Tom Lane a écrit :
I wrote (in response to Kevin Grittner's recent issues):
Reflecting on this further, I suspect there are also some bugs in the
planner's rules about when semi/antijoins can commute with other
joins;
After doing some math I've concluded this
Jeff Davis pg...@j-davis.com writes:
With the new snapshot maintenance code, it looks like we can advance the
xmin more aggressively.
The original design for that contemplated having snapmgr.c track
all the snapshots (cf the comment for RegisteredSnapshots). I don't
particularly care for
Alvaro Herrera alvhe...@commandprompt.com writes:
Note that it introduces a LEFT JOIN on pg_class to itself that's always
present, even for server versions that do not support reloptions.
Personally I'd be more worried about the unnest(). Also, please
schema-qualify that function name; you
Tom Lane wrote:
Jeff Davis pg...@j-davis.com writes:
With the new snapshot maintenance code, it looks like we can advance the
xmin more aggressively.
The original design for that contemplated having snapmgr.c track
all the snapshots (cf the comment for RegisteredSnapshots). I don't
Alvaro Herrera alvhe...@commandprompt.com writes:
For example, maybe we could keep track of counts of snapshots removed
since the last xmin calculation, and only run this routine if the number
is different from zero (or some small positive integer).
I think most of the callers of
I had an email today about an old bug that I reported back in July 2008.
http://archives.postgresql.org/pgsql-bugs/2008-07/msg00026.php
I didn't receive any response at the time and I didn't really follow it up.
My report contained a full re-creation script to reproduce the problem and
A6. (A antijoin B on (Pab)) leftjoin C on (Pbc)
= A antijoin (B leftjoin C on (Pbc)) on (Pab)
The second form is in fact equivalent to null-extending the A/B antijoin
--- the actual contents of C cannot affect the result. So we could just
I don't understand why antijoins need to
Robert Haas robertmh...@gmail.com writes:
I don't understand why antijoins need to null-extend the tuple at all.
Well, we are talking theoretical definition here, not implementation.
But if you need an example where the column values can be referenced:
select * from a left join b on
I've been putting a little bit of thought into how to go about testing the
performance of this patch. From reading the previous threads quite a bit of
testing was done with a certain data set where all that tested found it to
be a big winner with staggering performance gains with the skewed
On Tue, Feb 10, 2009 at 5:02 PM, Bruce Momjian br...@momjian.us wrote:
Merlin Moncure wrote:
PQinitSSL(0) was specifically designed to allow applications to set up
SSL on their own. How does this not work properly?
this has nothing to do with who initializes ssl. this is all about
On Tue, Feb 10, 2009 at 5:03 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
I don't understand why antijoins need to null-extend the tuple at all.
Well, we are talking theoretical definition here, not implementation.
But if you need an example where the
David Rowley dgrow...@gmail.com writes:
My report contained a full re-creation script to reproduce the problem and
tonight I'm having the same problem with CVS Head. To my untrained eye it
looks like the planner is not properly pushing down the row count.
It looks more like a multicolumn
David Rowley dgrow...@gmail.com writes:
Currently I'm unsure the best way to ensure that the hash join goes into
more than one batch apart from just making the dataset very large.
Make work_mem very small?
But really there are two different performance regimes here, one where
the hash data is
From: Tom Lane [mailto:t...@sss.pgh.pa.us]
Sent: 10 February 2009 22:30
To: David Rowley
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Bug #4284
David Rowley dgrow...@gmail.com writes:
My report contained a full re-creation script to reproduce the problem
and
tonight I'm
On Tue, Feb 10, 2009 at 5:02 PM, Bruce Momjian br...@momjian.us wrote:
PQinitSSL(false) initializes crypto? Please point me to exact function
calls that are the problem? Everything is very vague.
File: src/interfaces/libpq/fe-secure.c
Func: init_ssl_system
Line: 823
Starting at around
On Tue, Feb 10, 2009 at 3:10 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I wrote (in response to Kevin Grittner's recent issues):
Reflecting on this further, I suspect there are also some bugs in the
planner's rules about when semi/antijoins can commute with other joins;
After doing some math
On Tue, Feb 10, 2009 at 8:09 PM, Jonah H. Harris jonah.har...@gmail.comwrote:
On Tue, Feb 10, 2009 at 3:10 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I wrote (in response to Kevin Grittner's recent issues):
Reflecting on this further, I suspect there are also some bugs in the
planner's rules
Jonah H. Harris jonah.har...@gmail.com writes:
Cripes! I just had an idea and it looks like the buggers beat me to it :(
http://www.google.com/patents?id=4bqBEBAJdq=null+aware+anti-join
I wonder if the USPTO is really clueless enough to accept this?
Claim 1 would give Oracle ownership of
On Tue, Feb 10, 2009 at 8:41 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Jonah H. Harris jonah.har...@gmail.com writes:
Cripes! I just had an idea and it looks like the buggers beat me to it
:(
http://www.google.com/patents?id=4bqBEBAJdq=null+aware+anti-join
I wonder if the USPTO is
Jeff Davis asked me if I'd be willing to do a review of the GIN fast
insert patch about two weeks ago, but I haven't actually had a chance
to read through it in detail until tonight. I can't say I really know
anything about GIN (though I did take this opportunity to RTM), so
apologies in advance
Robert Haas robertmh...@gmail.com writes:
I think this is related to the problems with gincostestimate() that
Tom Lane was complaining about here:
http://archives.postgresql.org/message-id/20441.1234209...@sss.pgh.pa.us
I am not 100% sure I'm understanding this correctly, but I think the
The idea I came up with for benchmarking was a little similar to what
I
remember from the original tests. I have a sales orders table and a
products
table. My version of the sales orders table contains a customer
column.
Data
for 10 customers is populated into the sales orders table,
On Tue, Feb 10, 2009 at 10:38 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I think this code needs to be somehow rewritten to make things degrade
gracefully when the pending list is long - I'm not sure what the best
way to do that is. Inventing a new data structure to store TIDs that
is never lossy
-Original Message-
From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers-
ow...@postgresql.org] On Behalf Of Tom Lane
But really there are two different performance regimes here, one where
the hash data is large enough to spill to disk and one where it isn't.
Reducing
Andrew Chernow wrote:
On Tue, Feb 10, 2009 at 5:02 PM, Bruce Momjian br...@momjian.us wrote:
PQinitSSL(false) initializes crypto? Please point me to exact function
calls that are the problem? Everything is very vague.
File: src/interfaces/libpq/fe-secure.c
Func: init_ssl_system
Bruce Momjian wrote:
Andrew Chernow wrote:
On Tue, Feb 10, 2009 at 5:02 PM, Bruce Momjian br...@momjian.us wrote:
PQinitSSL(false) initializes crypto? Please point me to exact function
calls that are the problem? Everything is very vague.
File: src/interfaces/libpq/fe-secure.c
Robert Haas robertmh...@gmail.com writes:
On Tue, Feb 10, 2009 at 10:38 PM, Tom Lane t...@sss.pgh.pa.us wrote:
It strikes me that part of the issue here is that the behavior of this
code is much better adapted to the bitmap-scan API than the traditional
indexscan API. Since GIN doesn't
On Tue, Feb 10, 2009 at 11:09 PM, Bruce Momjian br...@momjian.us wrote:
Why not just call PQinitSSL(true) and do everything in your
application?; from the libpq manual:
If you are using acronymSSL/ inside your application (in addition
to inside applicationlibpq/application), you can use
On Tue, Feb 10, 2009 at 11:18 PM, Tom Lane t...@sss.pgh.pa.us wrote:
For queries that select only a single index entry, there might be some
speed degradation, but a quick test suggests it's in the
single-digit-percentage range if everything's cached; and of course if
you have to go to disk
Robert Haas wrote:
I am not in love with the idea of using PQinitSSL(SOME_MAGIC_VALUE)
The issue I see is the inability to toggle crypto initialization. I
think crypto init and ssl init are 2 different things. Thus, I proposed
the below:
We often discuss changing user-visible behavior of various kinds and are
usually clueless on the question of someone might rely on this or how
many people are still using this etc. Still, it is clearly often
useful to revise interfaces from time to time.
I have been thinking, with a
Bruce Momjian wrote:
Now that pg_migrator is BSD licensed, and already in C, I am going to
spend my time trying to improve pg_migrator for 8.4:
http://pgfoundry.org/projects/pg-migrator/
What is the plan now? Get pg_upgrade working, get pg_migrator working,
ship pg_migrator in core
77 matches
Mail list logo
