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 o
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 semi-
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:
http://archives.postgresql.org/pgsql-hackers/2009-
On Tue, Feb 10, 2009 at 11:18 PM, Tom Lane 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 then the extra CPU
On Tue, Feb 10, 2009 at 11:09 PM, Bruce Momjian wrote:
> Why not just call PQinitSSL(true) and do everything in your
> application?; from the libpq manual:
>
> If you are using SSL inside your application (in addition
> to inside libpq), you can use
> PQinitSSL(int) to tell libpq
> that t
Robert Haas writes:
> On Tue, Feb 10, 2009 at 10:38 PM, Tom Lane 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 support ordered scan anyway, I wonder
>
Bruce Momjian wrote:
> Andrew Chernow wrote:
> >
> > > On Tue, Feb 10, 2009 at 5:02 PM, Bruce Momjian 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
Andrew Chernow wrote:
>
> > On Tue, Feb 10, 2009 at 5:02 PM, Bruce Momjian 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: 82
> -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 w
On Tue, Feb 10, 2009 at 10:38 PM, Tom Lane 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 seems like
> 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, cu
Robert Haas 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
> reason why gincostes
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 i
On Tue, Feb 10, 2009 at 8:41 PM, Tom Lane wrote:
> "Jonah H. Harris" writes:
> > Cripes! I just had an idea and it looks like the buggers beat me to it
> :(
> > http://www.google.com/patents?id=4bqBEBAJ&dq=null+aware+anti-join
>
> I wonder if the USPTO is really clueless enough to accept th
"Jonah H. Harris" writes:
> Cripes! I just had an idea and it looks like the buggers beat me to it :(
> http://www.google.com/patents?id=4bqBEBAJ&dq=null+aware+anti-join
I wonder if the USPTO is really clueless enough to accept this?
Claim 1 would give Oracle ownership of the definition of N
On Tue, Feb 10, 2009 at 8:09 PM, Jonah H. Harris wrote:
> On Tue, Feb 10, 2009 at 3:10 PM, Tom Lane 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 co
On Tue, Feb 10, 2009 at 3:10 PM, Tom Lane 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 I've conclude
On Tue, Feb 10, 2009 at 5:02 PM, Bruce Momjian 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 line 853, this funct
> 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" writes:
> > My report contained a full re-creation script to reproduce the problem
> and
> > tonight I'm having t
"David Rowley" 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 large enough to
"David Rowley" 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 selectivity issue
On Tue, Feb 10, 2009 at 5:03 PM, Tom Lane wrote:
> Robert Haas 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:
>
>
On Tue, Feb 10, 2009 at 5:02 PM, Bruce Momjian 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
>> *crypto*.
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 datase
Robert Haas 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 (a.id = b.id)
wh
> 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
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
Alvaro Herrera 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 SnapshotResetXmin already know they
r
Tom Lane wrote:
> Jeff Davis 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
Alvaro Herrera 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 can't assume anything about
Jeff Davis 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 having it assume that
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 is
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 con
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 foo;
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?
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 i
On Tue, Feb 10, 2009 at 1:02 PM, Magnus Hagander wrote:
> Merlin Moncure wrote:
>> On Tue, Feb 10, 2009 at 12:03 PM, Dave Page wrote:
>>> On Tue, Feb 10, 2009 at 4:57 PM, Merlin Moncure wrote:
>>>
PQinitSSL is *broken*. It's always been broken. Since it already
takes a parameter, I s
Merlin Moncure wrote:
> On Tue, Feb 10, 2009 at 12:03 PM, Dave Page wrote:
>> On Tue, Feb 10, 2009 at 4:57 PM, Merlin Moncure 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
Tom Lane wrote:
> Heikki Linnakangas 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 think it
On Tue, Feb 10, 2009 at 5:05 PM, Merlin Moncure 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: http://www.enterprisedb.com
--
Sent via
Heikki Linnakangas 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 think it'd be
a serious error to be
On Tue, Feb 10, 2009 at 12:03 PM, Merlin Moncure wrote:
> On Tue, Feb 10, 2009 at 11:54 AM, Bruce Momjian wrote:
>> Merlin Moncure wrote:
>>> On Tue, Feb 10, 2009 at 11:52 AM, Bruce Momjian wrote:
>>> > Robert Haas wrote:
>>> >> > Would someone remind me why turning off ssl initialization in lib
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
On Tue, Feb 10, 2009 at 12:03 PM, Dave Page wrote:
> On Tue, Feb 10, 2009 at 4:57 PM, Merlin Moncure 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.
>
> Ad
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 initializ
On Tue, Feb 10, 2009 at 4:57 PM, Merlin Moncure 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 our Windows users
On Tue, Feb 10, 2009 at 11:54 AM, Bruce Momjian wrote:
> Merlin Moncure wrote:
>> On Tue, Feb 10, 2009 at 11:52 AM, Bruce Momjian wrote:
>> > Robert Haas wrote:
>> >> > Would someone remind me why turning off ssl initialization in libpq does
>> >> > not work for this case?
>> >>
>> >> That initia
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 wa
On Tue, Feb 10, 2009 at 11:14 AM, Tom Lane wrote:
> Robert Haas 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 wor
Merlin Moncure wrote:
> On Tue, Feb 10, 2009 at 11:52 AM, Bruce Momjian 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
> >> l
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 M
On Tue, Feb 10, 2009 at 11:52 AM, Bruce Momjian 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 but li
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
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 (pgsql-hackers@postgres
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 initia
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, LLC
> 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.
...Robert
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql
On Tue, Feb 10, 2009 at 11:14 AM, Tom Lane wrote:
> Robert Haas 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 wor
Magnus Hagander wrote:
> Merlin Moncure wrote:
> > On Tue, Feb 10, 2009 at 9:32 AM, Magnus Hagander
> > 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_ou
Robert Haas 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, we sho
On Tue, Feb 10, 2009 at 10:54 AM, Tom Lane wrote:
> Robert Haas 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
Tom Lane wrote:
> Robert Haas 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
Robert Haas 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 would help if t
>> 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
Simon Riggs 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, etc to the new table.
Merlin Moncure wrote:
> On Tue, Feb 10, 2009 at 9:32 AM, Magnus Hagander 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
On Tue, Feb 10, 2009 at 9:32 AM, Magnus Hagander 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 init stuff.
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
> decisio
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
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 n
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
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 postgresql
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 discuss
Thanks for your feedback, Emmanuel.
Here are my comments:
On 2/10/09, Emmanuel Cecchet 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 metadata table sho
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 the
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 p
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,
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 ser
78 matches
Mail list logo
