Hi,
I wanted to do some transformation on an inet value from
an SPI-using function. The inet Datum passed from SPI_getbinval()
to the values array in heap_form_tuple() obviously gives good data
to the frontend. When I use DatumGetInetP() on the Datum,
the structure passed to me is corrupt:
zozo=#
On 08.11.2011 11:22, Boszormenyi Zoltan wrote:
Hi,
I wanted to do some transformation on an inet value from
an SPI-using function. The inet Datum passed from SPI_getbinval()
to the values array in heap_form_tuple() obviously gives good data
to the frontend. When I use DatumGetInetP() on the Datu
On Tue, Nov 8, 2011 at 2:26 AM, Simon Riggs wrote:
> On Tue, Nov 8, 2011 at 2:54 AM, Robert Haas wrote:
>> It would still be nice to fix the case where we need to freeze a tuple
>> that is on a page someone else has pinned, but I don't have any good
>> ideas for how to do that.
>
> I think we nee
I ran into a performance problem described in this thread:
http://archives.postgresql.org/pgsql-performance/2011-10/msg00249.php
continued here:
http://archives.postgresql.org/pgsql-performance/2011-11/msg00045.php
OpenSSL compresses data by default, and that causes a
performance penalty of 100%
Excerpts from Robert Haas's message of mar nov 08 01:25:31 -0300 2011:
> But I can't help feeling that as we continue to add more features,
> we've eventually going to end up with our backs to the wall. Not sure
> what to do about that, but...
What I've imagined for a long time is psql being ab
On Tue, Nov 8, 2011 at 1:59 AM, Simon Riggs wrote:
> Please continue to expect that, I just haven't finished it yet...
OK.
So here's the deal: this is an effective, mostly automatic solution to
the performance problem noted in the original post. For example, at
32 clients, the original test cas
On Tue, Nov 8, 2011 at 14:59, Albe Laurenz wrote:
> I ran into a performance problem described in this thread:
>
> http://archives.postgresql.org/pgsql-performance/2011-10/msg00249.php
> continued here:
> http://archives.postgresql.org/pgsql-performance/2011-11/msg00045.php
>
> OpenSSL compresses
On 11/08/2011 03:59 PM, Albe Laurenz wrote:
> If there are concerns about that, maybe a GUC variable like
> ssl_compression (defaulting to off) would be a solution.
>
I'd vote for a libpq connect option instead. Something like
sslcompress=yes|no accompanied by PGSSLCOMPRESS environment
variable.
On Tue, Nov 8, 2011 at 3:59 PM, Albe Laurenz wrote:
> It is possible that this could cause a performance
> regression for people who SELECT lots of compressible
> data over really slow network connections, but is that
> a realistic scenario?
Yes, it's a realistic scenario. Please make it a optio
Marko Kreen writes:
> On Tue, Nov 8, 2011 at 3:59 PM, Albe Laurenz wrote:
>> It is possible that this could cause a performance
>> regression for people who SELECT lots of compressible
>> data over really slow network connections, but is that
>> a realistic scenario?
> Yes, it's a realistic scen
On Tue, Nov 8, 2011 at 2:24 AM, YAMAMOTO Takashi wrote:
> latestCompletedXid got backward due to concurrent updates
> and it fooled TransactionIdIsInProgress?
Ah ha! I bet that's it.
I think this could be avoided by a more sophisticated locking scheme.
Instead of waking up all the people trying
On Tue, Nov 8, 2011 at 2:34 PM, Tom Lane wrote:
>
> The fact of the matter is that in most situations where you want SSL,
> ie links across insecure WANs, compression is a win. Testing a local
> connection, as you seem to have done, is just about 100% irrelevant to
> performance in the real world
On 11/08/2011 09:34 AM, Tom Lane wrote:
Marko Kreen writes:
On Tue, Nov 8, 2011 at 3:59 PM, Albe Laurenz wrote:
It is possible that this could cause a performance
regression for people who SELECT lots of compressible
data over really slow network connections, but is that
a realistic scenari
Andrew Dunstan writes:
> On 11/08/2011 09:34 AM, Tom Lane wrote:
>> There might be some argument for providing a client option to disable
>> compression, but it should not be forced, and it shouldn't even be the
>> default. But before adding YA connection option, I'd want to see some
>> evidence
On Tue, Nov 8, 2011 at 9:58 AM, Tom Lane wrote:
> Andrew Dunstan writes:
>> On 11/08/2011 09:34 AM, Tom Lane wrote:
>>> There might be some argument for providing a client option to disable
>>> compression, but it should not be forced, and it shouldn't even be the
>>> default. But before adding
On Tue, Nov 8, 2011 at 4:34 PM, Tom Lane wrote:
> Marko Kreen writes:
>> On Tue, Nov 8, 2011 at 3:59 PM, Albe Laurenz wrote:
>>> It is possible that this could cause a performance
>>> regression for people who SELECT lots of compressible
>>> data over really slow network connections, but is that
Heikki Linnakangas writes:
> Hmm, it seems to be intentional, but I agree it's very much contrary to
> the usual convention that DatumGetXXXP() returns a detoasted and
> depacked datum. I think we should change it. I propose the attached
> patch. It changes DatumGetInetP() to do PG_DETOAST_DATU
On Tue, Nov 8, 2011 at 1:50 PM, Robert Haas wrote:
> But there's an efficiency argument against doing it that way. First,
> if we release the pin then we'll have to reacquire the buffer, which
> means taking and releasing a BufMappingLock, the buffer header
> spinlock, and the buffer content loc
2011/11/8 Alvaro Herrera :
> What I've imagined for a long time is psql being able to display each
> row in more than one line; for example something like
>
> \df
>
> Listado de funciones
> Esquema | Nombre | Tipo de dato de salida | Tipo
> Tipos de datos de argum
On Tue, Nov 8, 2011 at 10:08 AM, Simon Riggs wrote:
> On Tue, Nov 8, 2011 at 1:50 PM, Robert Haas wrote:
>> But there's an efficiency argument against doing it that way. First,
>> if we release the pin then we'll have to reacquire the buffer, which
>> means taking and releasing a BufMappingLock,
Tom Lane wrote:
> I distinctly recall us getting bashed a few years ago because there
> wasn't any convenient way to turn SSL compression *on*. Now that SSL
> finally does the sane thing by default, you want to turn it off?
>
> The fact of the matter is that in most situations where you want SSL,
Robert Haas writes:
> On Tue, Nov 8, 2011 at 2:26 AM, Simon Riggs wrote:
>> I think we need to avoid long pin hold times generally.
> In the case of a suspended sequential scan, which is the case where
> this has most recently bitten me on a production system, it actually
> seems rather unnecess
Excerpts from Dickson S. Guedes's message of mar nov 08 12:11:21 -0300 2011:
> Isn't that what pagers like 'less' and 'more' do already? May be we
> could provide a pager more specific to psql output as a contrib or
> extension.
Well, now that you mention it, all pagers I know are line-based. I
On Tue, Nov 8, 2011 at 10:26 AM, Tom Lane wrote:
> It strikes me that the only case where vacuum now has to wait is where
> it needs to freeze an old XID. Couldn't it do that without insisting on
> exclusive access? We only need exclusive access if we're going to move
> data around, but we could
Robert Haas writes:
> Interesting idea. I think in general we insist that you must have a
> buffer content lock to inspect the tuple visibility info, in which
> case that would be safe. But I'm not sure we do that absolutely
> everywhere. For instance, just last night I noticed this:
>
Tom Lane wrote:
> There might be some argument for providing a client option to disable
> compression, but it should not be forced, and it shouldn't even be the
> default. But before adding YA connection option, I'd want to see some
> evidence that it's useful over non-local connections.
Here are
On Tue, Nov 08, 2011 at 04:59:02PM +0100, Albe Laurenz wrote:
> Tom Lane wrote:
> > There might be some argument for providing a client option to disable
> > compression, but it should not be forced, and it shouldn't even be the
> > default. But before adding YA connection option, I'd want to see
On Tue, Nov 08, 2011 at 04:19:02PM +0100, Albe Laurenz wrote:
> Tom Lane wrote:
> > I distinctly recall us getting bashed a few years ago because there
> > wasn't any convenient way to turn SSL compression *on*. Now that SSL
> > finally does the sane thing by default, you want to turn it off?
> >
On Tue, Nov 8, 2011 at 10:54 AM, Tom Lane wrote:
> Robert Haas writes:
>> Interesting idea. I think in general we insist that you must have a
>> buffer content lock to inspect the tuple visibility info, in which
>> case that would be safe. But I'm not sure we do that absolutely
>> everywhere.
I think there is a need to provide prefix search to bypass
dictionaries.If you folks think that there is some credibility to such a
need then I can think about implementing it. How about an operator like
":#" that does this? The ":*" will continue to mean the same as
currently.
-Sushant.
On Tue,
On Tue, Nov 8, 2011 at 11:06 AM, k...@rice.edu wrote:
> I think that JDBC and Npgsql should also support disabling compression.
That's the *real* problem here...
You're quite right that if we allow controlling this on the libpq
side, it is surely desirable to allow controlling this via JDBC,
Npg
On Mon, Nov 7, 2011 at 12:20 PM, Kohei KaiGai wrote:
> If sepgsql would apply permission checks db_procedure:{install} on the
> OAT_POST_CREATE hook based on the funcion-oid within new entry of
> system catalog, we can relocate OAT_PREP_CREATE hook more conceptually
> right place, such as just aft
On Sat, Nov 5, 2011 at 10:42 AM, Peter Eisentraut wrote:
> We only build the language plpython2u or plpython3u, not both, in any
> build, but we always install the extension control files for all
> variants. Is there a reason for this, or just an oversight?
Sounds like an oversight.
--
Robert
On 2011-11-08 22:59, Albe Laurenz wrote:
In addition to the oprofile data I collected three times:
- the duration as shown in the server log
- the duration as shown by \timing
- the duration of the psql command as measured by "time"
[...]
I think this makes a good case for disabling compress
2011/11/8 Alvaro Herrera :
> Excerpts from Dickson S. Guedes's message of mar nov 08 12:11:21 -0300 2011:
>> Isn't that what pagers like 'less' and 'more' do already? May be we
>> could provide a pager more specific to psql output as a contrib or
>> extension.
>
> Well, now that you mention it, all
Jeroen Vermeulen writes:
> Another reason why I believe compression is often used with encryption
> is to maximize information content per byte of data: harder to guess,
> harder to crack. Would that matter?
Yes, it would. There's a reason why the OpenSSL default is what it is.
On 08.11.2011 17:06, Tom Lane wrote:
Heikki Linnakangas writes:
Hmm, it seems to be intentional, but I agree it's very much contrary to
the usual convention that DatumGetXXXP() returns a detoasted and
depacked datum. I think we should change it. I propose the attached
patch. It changes DatumGet
Hi!
I ran into a problem with PG 9.1 and bug is observed even in master. After
simplifying a query (original was 9Kb long!) it's possible to reproduce it easily:
CREATE TABLE wow (t1 text, t2 text);
CREATE INDEX idx ON wow (t1,t2);
SET enable_seqscan=off;
SET enable_bitmapscan=off;
EXPLAIN
S
On 11/06/2011 11:55 PM, Mark Kirkwood wrote:
I am guessing (at this point very much guessing) that pg_freespace map
may return its data faster, as pageinspect is gonna have to grovel
through all the pages for itself (whereas pg_freespacemap relies on
using info from the ... free space map fork)
2011-11-08 18:53 keltezéssel, Heikki Linnakangas írta:
> On 08.11.2011 17:06, Tom Lane wrote:
>> Heikki Linnakangas writes:
>>> Hmm, it seems to be intentional, but I agree it's very much contrary to
>>> the usual convention that DatumGetXXXP() returns a detoasted and
>>> depacked datum. I think w
Tom,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> The fact of the matter is that in most situations where you want SSL,
> ie links across insecure WANs, compression is a win. Testing a local
> connection, as you seem to have done, is just about 100% irrelevant to
> performance in the real world.
I'm
Teodor Sigaev writes:
> SELECT
> t1, t2
> FROM (
> SELECT t1, t2 FROM wow
> UNION ALL
> SELECT 'a', 'a' FROM wow
> ) t
> ORDER BY t1, t2;
Hmm, interesting.
> It's seems to me that check in create_merge_append_plan() is too restrictive:
> if (memcmp(sortColIdx, node->
> configuration data somewhere else, but we really need to be able to tell
> the difference between "starting PITR", "continuing PITR after a
> mid-recovery crash", and "finished PITR, up and running normally".
> A GUC is not a good way to do that.
Does a GUC make sense to you for how to handle s
Given the amount of fixes that went into the branch, and importance of them -
when can we expect 9.1.2 to be released officially ?
9.1.1 was stamped on 22nd of September.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.post
On 08.11.2011 20:46, Boszormenyi Zoltan wrote:
2011-11-08 18:53 keltezéssel, Heikki Linnakangas írta:
What do people think of backpatching this? I'm inclined to backpatch, on the
grounds
that the macro that detoasts and depacks should always work (ie. after this
patch), even
if the depacking i
Hackers,
I'd really like us to release an alpha version based on the finished
CF2. There have been a number of major features added to PostgreSQL
prior to this CF -- including Haas's performance improvements and range
types -- which we really want at least some users to test early.
Would it be p
On 03/01/2011 11:50 AM, Peter Eisentraut wrote:
On fre, 2011-02-11 at 16:49 +0100, Jan Urbański wrote:
I believe it's (b). But as we don't have time for that discussion that
late in the release cycle, I think we need to consider it identical to (c).
As I previously mentioned, I think that the
On Sun, Nov 6, 2011 at 5:38 AM, Magnus Hagander wrote:
>
> Looks pretty useful.
>
thanks for the review, attached is a new version of it
> One quick stylistic comment - we don't generally use "* 1.0" to turn
> an int into a double - just use a cast.
>
ok
>
> Hooking into a ring buffer seems li
This is the time of year when the Wisconsin Courts formalize their
annual plan for where people will be spending the bulk of their time
in the coming year. Two years ago at this time, managers decided
that serializable transactions were a big enough issue to justify
assigning about half of my 2011
I was curious if anyone running into these problems has gotten a chance
to test the 3 fixes committed here. It sounded like Linas even had a
repeatable test case?
For easier reference the commits are:
http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=2f55c535e1f026929cf20855b3
On Wed, Nov 9, 2011 at 12:56 AM, Josh Berkus wrote:
> I'd really like us to release an alpha version based on the finished
> CF2. There have been a number of major features added to PostgreSQL
> prior to this CF -- including Haas's performance improvements and range
> types -- which we really wa
On 8 November 2011 21:23, Kevin Grittner wrote:
> This is the time of year when the Wisconsin Courts formalize their
> annual plan for where people will be spending the bulk of their time
> in the coming year. Two years ago at this time, managers decided
> that serializable transactions were a bi
Hi,
I found the following error message misleading:
test=# create table cows2 (LIKE cows);
ERROR: inherited relation "cows" is not a table
STATEMENT: create table cows2 (LIKE cows);
I'm not trying to inherit a relation, I'm trying to base a table on
it. As it happens, "cows" is a foreign tabl
On Tue, Nov 8, 2011 at 1:07 PM, Greg Smith wrote:
> On 11/06/2011 11:55 PM, Mark Kirkwood wrote:
>
> I am guessing (at this point very much guessing) that pg_freespace map may
> return its data faster, as pageinspect is gonna have to grovel through all
> the pages for itself (whereas pg_freespacem
Alexander,
> People trying range types are likely to try indexes on them. GiST on range
> types implementation in head have some limitations:
... it's an alpha. There will always be one more patch.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing
On 11/8/11 1:23 PM, Kevin Grittner wrote:
> So the question is, would a
> patch which does the first two without the third be accepted by the
> community?
AFAIC, yes.
For that matter, Part 3 is useful without parts 1 and 2, if someone
wanted to work on that. I recall some academic work on automa
On 8 Nov 2011, at 21:23, Kevin Grittner wrote:
> This is the time of year when the Wisconsin Courts formalize their
> annual plan for where people will be spending the bulk of their time
> in the coming year. Two years ago at this time, managers decided
> that serializable transactions were a bi
* Kevin Grittner (kevin.gritt...@wicourts.gov) wrote:
> So the question is, would a
> patch which does the first two without the third be accepted by the
> community?
I'm about 99% sure the answer to that is 'yes'. Are you thinking of
having a background scheduler which handles the updating of
sc
Stephen Frost wrote:
> Are you thinking of having a background scheduler which handles
> the updating of schedule-driven (instead of trigger-driven) MVs..?
I'm trying not to get to far into discussing design in advance of
reviewing previous work and any papers on the topic. That said, it
seem
On Nov 8, 2011, at 2:54 PM, Stephen Frost wrote:
>> So the question is, would a
>> patch which does the first two without the third be accepted by the
>> community?
+1 Definitely.
> I'm about 99% sure the answer to that is 'yes'. Are you thinking of
> having a background scheduler which handles
> I'm about 99% sure the answer to that is 'yes'. Are you thinking of
> having a background scheduler which handles the updating of
> schedule-driven (instead of trigger-driven) MVs..? Not to try to
> feature-creep this on you, but you might consider how a new backend
> process which handles sch
I wrote:
> Not immediately sure what to do about this. The quick-and-dirty fix
> would be to only apply add_child_rel_equivalences to simple inheritance
> child relations, for which the added items must be Vars and must be
> different (which is what that code is expecting). Seems like a bit of a
On Nov 8, 2011, at 3:25 PM, Josh Berkus wrote:
>> I'm about 99% sure the answer to that is 'yes'. Are you thinking of
>> having a background scheduler which handles the updating of
>> schedule-driven (instead of trigger-driven) MVs..? Not to try to
>> feature-creep this on you, but you might con
On 11/08/2011 05:07 PM, Robert Treat wrote:
It's already easy to get "good enough" numbers based on user space
tools with very little overhead, so I think it's more important that
the server side tool be accurate rather than fast.
What user space method do you consider good enough here? I have
On Nov 8, 2011, at 4:23 PM, Josh Berkus wrote:
>> Well, there has to be some way to refresh an MV at regular intervals, no?
>
> For periodic update matviews, yes. However, Kevin needs only produce
> the command/function call for updating a generic periodic matview. He
> doesn't need to provide
>> No feature-creeping; the two features described will be hard enough.
>> Besides, we have pg_agent for that.
>
> Well, there has to be some way to refresh an MV at regular intervals, no?
For periodic update matviews, yes. However, Kevin needs only produce
the command/function call for updatin
Greg Jaskiewicz writes:
> Given the amount of fixes that went into the branch, and importance of them -
> when can we expect 9.1.2 to be released officially ?
> 9.1.1 was stamped on 22nd of September.
That's barely more than six weeks ago. Usually, in the absence of any
seriously nasty bugs, P
Sushant Sinha writes:
> I think there is a need to provide prefix search to bypass
> dictionaries.If you folks think that there is some credibility to such a
> need then I can think about implementing it. How about an operator like
> ":#" that does this? The ":*" will continue to mean the same as
On 11/08/2011 06:25 PM, Josh Berkus wrote:
I'm about 99% sure the answer to that is 'yes'. Are you thinking of
having a background scheduler which handles the updating of
schedule-driven (instead of trigger-driven) MVs..? Not to try to
feature-creep this on you, but you might consider how a n
On 17 October 2011 03:04, Robert Haas wrote:
> On Fri, Oct 14, 2011 at 11:12 AM, Robert Haas wrote:
>> On Wed, Oct 12, 2011 at 10:20 PM, Josh Kupershmidt
>> wrote:
On the third hand, Josh's previous batch of changes to clean up
psql's behavior in this area are clearly a huge improveme
* Josh Berkus (j...@agliodbs.com) wrote:
> > Well, there has to be some way to refresh an MV at regular intervals, no?
>
> For periodic update matviews, yes. However, Kevin needs only produce
> the command/function call for updating a generic periodic matview. He
> doesn't need to provide a sche
On 11/08/2011 07:34 PM, Tom Lane wrote:
I don't recall that we've fixed anything since September that seemed to
warrant an immediate release.
The backup+pg_clog failure issues fixed last week have been a nasty
problem hitting people for a while. Backup corruption is obviously
serious. O
On Tue, Nov 8, 2011 at 8:31 PM, Stephen Frost wrote:
> Perhaps that would be an acceptable initial version, but I'd be pretty
> disappointed and I certainly don't think we should stop there.
I agree that a built-in job scheduler would be pretty awesome, but I
think it's a completely separate proj
Greg Smith writes:
> I was curious how 9.0 fared last year for comparison, here's that data:
> Version Date Days Weeks
> 9.0.009/20/10
> 9.0.110/04/10142.0
> 9.0.212/16/107310.4
> 9.0.301/31/11466.6
> 9.0.404/18/117711.0
> 9.0.509/26/1
On Tue, Nov 8, 2011 at 3:56 PM, Josh Berkus wrote:
> I'd really like us to release an alpha version based on the finished
> CF2. There have been a number of major features added to PostgreSQL
> prior to this CF -- including Haas's performance improvements and range
> types -- which we really want
On Mon, Nov 7, 2011 at 11:25 PM, Robert Haas wrote:
> But I can't help feeling that as we continue to add more features,
> we've eventually going to end up with our backs to the wall. Not sure
> what to do about that, but...
Seriously, parts of psql are starting to become a real mess.
[tangenti
On Tue, Nov 8, 2011 at 8:12 PM, Thom Brown wrote:
> Why is this marked as done on with Wiki's todo list?
I assume you're referring to this item:
--
\dd is missing comments for several types of objects. Comments are
not handled at all for some object types, and are handled by both \dd
and the in
Josh Kupershmidt writes:
> We're essentially pretending that we support all server versions with
> this code, instead of erroring out on some definite old version and
> admitting "sorry, can't do it". ...
> I think we should draw a line somewhere about just how far back psql
> must support,
Says
On 11/08/2011 04:23 PM, Kevin Grittner wrote:
http://wiki.postgresql.org/wiki/Materialized_Views
That page describes three components: creating MVs, updating MVs, and
having the planner automatically detect when an MV matches some
portion of a regular query and using the MV instead of the specifi
On 11/08/2011 09:31 PM, Robert Haas wrote:
I know various people are working on patches to do various things, but the
only outstanding thing that sticks out in my mind as an outstanding
"big feature" patch is Alvaro's work on foreign key locks. I'm sure
there must be others... but I'm not sure
On mån, 2011-11-07 at 12:21 -0500, Robert Haas wrote:
> > As I'm plotting to write code for this, I wonder about how to handle
> > default privileges. For compatibility and convenience, we would
> still
> > want to have types with public privileges by default. Should we
> > continue to hardcode t
On Nov 9, 2011 3:25 AM, "Tom Lane" wrote:
>
> Greg Smith writes:
> > I was curious how 9.0 fared last year for comparison, here's that data:
>
> > Version Date Days Weeks
> > 9.0.009/20/10
> > 9.0.110/04/10142.0
> > 9.0.212/16/107310.4
> > 9.0.301/31/1146
Peter Eisentraut writes:
> Let me put this differently. Should we either continue to hardcode the
> default privileges in the acldefault() function, or should we instead
> initialize the system catalogs with an entry in pg_default_acl as though
> ALTER DEFAULT PRIVILEGES GRANT USAGE ON TYPES TO P
After some thought and experimentation, the best fix seems to be to
eliminate the ambiguity by wrapping subquery outputs in PlaceHolderVars
whenever there is a risk of confusion. The attached crude patch fixes
both test cases. It needs work (more comments and a regression test
case would be good
84 matches
Mail list logo
