On Wed, Apr 4, 2012 at 8:00 AM, Tom Lane wrote:
> umi.tan...@gmail.com writes:
>> http://www.postgresql.org/docs/9.1/static/spi-spi-execute.html
>
>> ===
>> SPI_execute("INSERT INTO foo SELECT * FROM bar", false, 5);
>> will allow at most 5 rows to be inserted into the table.
>> ===
>
>> This seem
>> Those code fragment judges the return value from
>> SSL_read(). secure_read() does retrying when SSL_ERROR_WANT_READ *and*
>> SSL_ERROR_WANT_WRITE returned. However, pqsecure_read() does not retry
>> when SSL_ERROR_WANT_READ. It seems they are not consistent. Comments?
>
> There's no particular
Stephen Frost writes:
> The single-user option *sounds* viable, but, iirc, it actually isn't due
> to the limitations on what can be done in that mode.
Yeah. IMO the right long-term fix is to be able to run pg_dump and psql
talking to a standalone backend, but nobody's gotten round to making
tha
Harold,
* Harold Giménez (harold.gime...@gmail.com) wrote:
> Possible workarounds on the current version:
This has actually been discussed before and unfortunately there aren't
any trivial solutions.
> * Rewrite pg_hba.conf temporarily while the pg_upgrade script runs to
> disallow any other con
On Wed, Apr 4, 2012 at 4:10 PM, Thom Brown wrote:
> +1 to anything that separates these out. Cramming them into one list
> like we currently have is confusing.
+1 as well.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mai
Hi all,
I've written a pg_upgrade wrapper for upgrading our users (heroku) to
postgres 9.1. In the process I encountered a specific issue that could
easily be improved. We've had this process work consistently for many users
both internal and external, with the exception of just a few for whom the
On Wed, Apr 4, 2012 at 12:47 PM, Tom Lane wrote:
> Now, Scott's comment seems to me to offer a principled way out of this:
> if we define the intended semantics of search_path as being similar
> to the traditional understanding of Unix PATH, then it's not an error
> or even unexpected to have refe
> > I'm afraid not re-initializing materialize_needed for the next query
> > in the latest dblink patch.
I've found no need to worry about the re-initializing issue.
> I've committed a revised version of the previous patch.
Thank you for that.
> I'm not sure that the case of dblink_is_busy not
On Wed, Apr 4, 2012 at 7:02 PM, Tom Lane wrote:
> Greg Stark writes:
>> On Wed, Apr 4, 2012 at 9:34 PM, Simon Riggs wrote:
>>> Why is this pgbench run accessing so much unhinted data that is > 1
>>> million transactions old? Do you believe those numbers? Looks weird.
>
>> I think this is in the
On Wed, Apr 4, 2012 at 4:34 PM, Simon Riggs wrote:
> Interesting. You've spoken at length how this hardly ever happens and
> so this can't have any performance effect. That was the reason for
> kicking out my patch addressing clog history, wasn't it?
Uh, no, the reason for kicking out your clog h
On Wed, Apr 4, 2012 at 4:23 PM, Simon Riggs wrote:
> Measurement?
>
> Sounds believable, I just want to make sure we have measured things.
Yes, I measured things. I didn't post the results because they're
almost identical to the previous set of results which I already
posted. That is, I wrote t
On Wed, Apr 4, 2012 at 11:59 PM, Tom Lane wrote:
> The renaming you propose would only be acceptable to those who have
> forgotten that history. I haven't.
I had. I looked it up
http://archives.postgresql.org/pgsql-bugs/2010-08/msg00044.php
That was quite a thread.
--
greg
--
Sent via pgsql
On Tue, Apr 3, 2012 at 7:29 AM, Huchev wrote:
> For a C implementation, it could interesting to consider LZ4 algorithm, since
> it is written natively in this language. In contrast, Snappy has been ported
> to C by Andy from the original C++ Google code, which lso translate into
> less extensive u
On 4/4/12 4:02 PM, Tom Lane wrote:
> Greg Stark writes:
>> On Wed, Apr 4, 2012 at 9:34 PM, Simon Riggs wrote:
>>> Why is this pgbench run accessing so much unhinted data that is > 1
>>> million transactions old? Do you believe those numbers? Looks weird.
>
>> I think this is in the nature of the
Greg Stark writes:
> On Wed, Apr 4, 2012 at 9:34 PM, Simon Riggs wrote:
>> Why is this pgbench run accessing so much unhinted data that is > 1
>> million transactions old? Do you believe those numbers? Looks weird.
> I think this is in the nature of the workload pgbench does. Because
> the updat
Peter Eisentraut writes:
> On fre, 2011-12-23 at 19:51 +0200, Peter Eisentraut wrote:
>> On ons, 2011-12-21 at 11:04 +0100, Pavel Stehule wrote:
>>> this patch adds a bytea_agg aggregation.
>> Why not call it string_agg?
> Here is a patch to do the renaming. As it stands, it fails the
> opr_san
Kyotaro HORIGUCHI writes:
> I'm afraid not re-initializing materialize_needed for the next query
> in the latest dblink patch.
> I will confirm that and send the another one if needed in a few hours.
I've committed a revised version of the previous patch. I'm not sure
that the case of dblink_is_
Marko Kreen writes:
> On Wed, Apr 4, 2012 at 10:17 PM, Tom Lane wrote:
>> Given the lack of consensus around the suspension API, maybe the best
>> way to get the underlying libpq patch to a committable state is to take
>> it out --- that is, remove the "return zero" option for row processors.
>
On Wed, Apr 4, 2012 at 9:05 PM, Robert Haas wrote:
> Here's a sample of how often that's firing, by second, on
> this test (pgbench with 32 clients):
>
> 4191 19:54:21
> 4540 19:54:22
Hm, so if that's evenly spread out that's 1/4ms between slru flushes
and if each flush takes 5-10ms that's go
On Wed, Apr 4, 2012 at 9:34 PM, Simon Riggs wrote:
> Why is this pgbench run accessing so much unhinted data that is > 1
> million transactions old? Do you believe those numbers? Looks weird.
I think this is in the nature of the workload pgbench does. Because
the updates are uniformly distributed
I'm afraid not re-initializing materialize_needed for the next query
in the latest dblink patch.
I will confirm that and send the another one if needed in a few hours.
# I need to catch the train I usually get on..
> Hello, This is the new version of dblink patch.
regards,
--
Kyotaro Horiguchi
On Wed, Apr 4, 2012 at 10:17 PM, Tom Lane wrote:
> Given the lack of consensus around the suspension API, maybe the best
> way to get the underlying libpq patch to a committable state is to take
> it out --- that is, remove the "return zero" option for row processors.
> Since we don't have a test
On 04/04/2012 03:09 PM, Tom Lane wrote:
I wrote:
The idea I had in mind was to compensate for adding list-removal logic
by getting rid of the concept of an unused entry. If the removal is
conditional then you can't do that and you end up with the complications
of both methods. Anyway I've no
On 04-04-2012 17:07, Peter Eisentraut wrote:
> postgres -D ... --debug-print-plan
>
> which fails, because you need to write --ssl=on or
> --debug-print-plan=true etc.
>
> Have others had the same experience? Would it be worth supporting the
> case without value to default to on/true?
>
Please,
On Wed, Apr 4, 2012 at 9:05 PM, Robert Haas wrote:
> Yes, the SLRU is thrashing heavily. In this configuration, there are
> 32 CLOG buffers. I just added an elog() every time we replace a
> buffer. Here's a sample of how often that's firing, by second, on
> this test (pgbench with 32 clients):
On Wed, Apr 4, 2012 at 6:25 PM, Alvaro Herrera
wrote:
>
> Excerpts from Greg Stark's message of mié abr 04 14:11:29 -0300 2012:
>> On Wed, Apr 4, 2012 at 1:00 PM, Robert Haas wrote:
>> > , everybody's next few CLOG requests hit some other
>> > buffer but eventually the long-I/O-in-progress buffer
On Wed, Apr 4, 2012 at 1:00 PM, Robert Haas wrote:
>> I'll do some testing to try to confirm whether this theory is correct
>> and whether the above fix helps.
Very interesting work.
> Having performed this investigation, I've discovered a couple of
> interesting things. First, SlruRecentlyU
On fre, 2011-12-23 at 19:51 +0200, Peter Eisentraut wrote:
> On ons, 2011-12-21 at 11:04 +0100, Pavel Stehule wrote:
> > this patch adds a bytea_agg aggregation.
> >
> > It allow fast bytea concatetation.
>
> Why not call it string_agg? All the function names are the same between
> text and byte
Dave Page wrote:
Exactly - which is why I was objecting to recommending a distribution
of PostgreSQL that came in a packaging system that we were told
changed /usr/local to be world writeable to avoid the use/annoyance of
the standard security measures on the platform.
We... that's not exac
On 4 April 2012 19:53, Peter Eisentraut wrote:
> ... would be really nice to have. Especially pgbench and pg_upgrade for
> me, but it would be useful to have man pages for everything.
>
> Unfortunately, we can't just replace the sect1's in in Appendix F [0]
> with refentry's, because the content
Every so often I find myself trying to write
postgres -D ... --ssl
or
postgres -D ... --debug-print-plan
which fails, because you need to write --ssl=on or
--debug-print-plan=true etc.
Have others had the same experience? Would it be worth supporting the
case without value to default to on/tr
On Wed, Apr 4, 2012 at 1:11 PM, Greg Stark wrote:
> On Wed, Apr 4, 2012 at 1:00 PM, Robert Haas wrote:
>> , everybody's next few CLOG requests hit some other
>> buffer but eventually the long-I/O-in-progress buffer again becomes
>> least recently used and the next CLOG eviction causes a second ba
On ons, 2012-04-04 at 16:29 -0300, Alvaro Herrera wrote:
> > Unfortunately, we can't just replace the sect1's in in Appendix F [0]
> > with refentry's, because the content model of DocBook doesn't allow
> > that. (You can't have a mixed sequence of sect1 and refentry, only one
> > or the other.)
>
2012/4/4 Heikki Linnakangas :
> On 30.03.2012 12:36, Pavel Stehule wrote:
>>
>> 2012/3/28 Heikki Linnakangas:
>>>
>>> In prepare_expr(), you use a subtransaction to catch any ERRORs that
>>> happen
>>>
>>> during parsing the expression. That's a good idea, and I think many of
>>> the
>>> check_* fu
Excerpts from Joachim Wieland's message of mié abr 04 15:43:53 -0300 2012:
> On Wed, Apr 4, 2012 at 8:27 AM, Andrew Dunstan wrote:
> >> Sure, PrintStatus is just there for now to see what's going on. My
> >> plan was to remove it entirely in the final patch.
> >
> > We need that final patch NOW,
I think this patch is doing two things: first touching infrastructure
stuff and then adding lock_timeout on top of that. Would it work to
split the patch in two pieces?
--
Álvaro Herrera
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7
Excerpts from Peter Eisentraut's message of mié abr 04 15:53:20 -0300 2012:
> ... would be really nice to have. Especially pgbench and pg_upgrade for
> me, but it would be useful to have man pages for everything.
>
> Unfortunately, we can't just replace the sect1's in in Appendix F [0]
> with re
2012-04-04 17:12 keltezéssel, Boszormenyi Zoltan írta:
2012-04-04 16:22 keltezéssel, Boszormenyi Zoltan írta:
2012-04-04 15:17 keltezéssel, Boszormenyi Zoltan írta:
Hi,
2012-04-04 12:30 keltezéssel, Boszormenyi Zoltan írta:
Hi,
attached is a patch to implement a framework to simplify and
cor
Kyotaro HORIGUCHI writes:
>> What I'm currently thinking we should do is just use the old method
>> for async queries, and only optimize the synchronous case.
> Ok, I agree with you except for performance issue. I give up to use
> row processor for async query with dblink_is_busy called.
Yeah, t
I wrote:
> The idea I had in mind was to compensate for adding list-removal logic
> by getting rid of the concept of an unused entry. If the removal is
> conditional then you can't do that and you end up with the complications
> of both methods. Anyway I've not tried to code it yet.
I concluded
... would be really nice to have. Especially pgbench and pg_upgrade for
me, but it would be useful to have man pages for everything.
Unfortunately, we can't just replace the sect1's in in Appendix F [0]
with refentry's, because the content model of DocBook doesn't allow
that. (You can't have a m
Hello, This is the new version of dblink patch.
- Calling dblink_is_busy prevents row processor from being used.
- some PGresult leak fixed.
- Rebased to current head.
> A hack on top of that hack would be to collect the data into a
> tuplestore that contains all text columns, and then convert
Excerpts from Greg Stark's message of mié abr 04 14:11:29 -0300 2012:
> On Wed, Apr 4, 2012 at 1:00 PM, Robert Haas wrote:
> > , everybody's next few CLOG requests hit some other
> > buffer but eventually the long-I/O-in-progress buffer again becomes
> > least recently used and the next CLOG evic
On Wed, Apr 4, 2012 at 1:00 PM, Robert Haas wrote:
> 3. I noticed that the blocking described by "slru.c:311 blocked by
> slru.c:405" seemed to be clumpy - I would get a bunch of messages
> about that all at once. This makes me wonder if the SLRU machinery is
> occasionally making a real bad deci
Andrew Dunstan writes:
> On 04/04/2012 12:13 PM, Tom Lane wrote:
>> Does anyone feel that it's a bad idea that list entries are never
>> reclaimed? In the worst case a transient load peak could result in
>> a long list that permanently adds search overhead. Not sure if it's
>> worth the extra co
On Wed, Apr 4, 2012 at 1:00 PM, Robert Haas wrote:
> , everybody's next few CLOG requests hit some other
> buffer but eventually the long-I/O-in-progress buffer again becomes
> least recently used and the next CLOG eviction causes a second backend
> to begin waiting for that buffer.
This still so
On 04/04/2012 12:13 PM, Tom Lane wrote:
Andrew Dunstan writes:
On 04/02/2012 01:03 PM, Tom Lane wrote:
When I said "list", I meant a "List *". No fixed size.
Ok, like this?
I think this could use a bit of editorialization (I don't think the
"stripe" terminology is still applicable, in par
Robert Haas writes:
> On Wed, Apr 4, 2012 at 12:22 PM, Tom Lane wrote:
>> You're getting squishy on me ...
> My feeling on this is that it's OK to warn if the search_path is set
> to something that's not valid, and it might also be OK to not warn.
> Right now we emit a NOTICE and I don't feel te
2012/4/4 Heikki Linnakangas :
> On 04.04.2012 19:32, Tom Lane wrote:
>>
>> Heikki Linnakangas writes:
>>>
>>> I don't think I'm getting my point across by explaining, so here's a
>>> modified version of the patch that does what I was trying to say.
>>
>>
>> Minor side point: some of the diff noise
On 04.04.2012 19:32, Tom Lane wrote:
Heikki Linnakangas writes:
I don't think I'm getting my point across by explaining, so here's a
modified version of the patch that does what I was trying to say.
Minor side point: some of the diff noise in this patch comes from
s/copy_plpgsql_datum/plpgsql
On Wed, Apr 4, 2012 at 9:53 AM, Dobes Vandermeer wrote:
> I think there is something to be gained by having a first-class concept of a
> "document" in the database. It might save some trouble managing
> parent/child relations, versioning, things like that.
Methinks this needs a *lot* more specif
Heikki Linnakangas writes:
> I don't think I'm getting my point across by explaining, so here's a
> modified version of the patch that does what I was trying to say.
Minor side point: some of the diff noise in this patch comes from
s/copy_plpgsql_datum/plpgsql_copy_plpgsql_datum/, which seems en
On Wed, Apr 4, 2012 at 12:22 PM, Tom Lane wrote:
> Scott Mead writes:
>> On Wed, Apr 4, 2012 at 12:02 PM, Tom Lane wrote:
>>> Well, that's an interesting analogy. Are you arguing that we should
>>> always accept any syntactically-valid search_path setting, no matter
>>> whether the mentioned sc
On Wed, Apr 4, 2012 at 8:00 AM, Robert Haas wrote:
> There's some apparent regression on the single-client test, but I'm
> inclined to think that's a testing artifact of some kind and also
> probably not very important. It would be worth paying a small price
> in throughput to avoid many-second e
Scott Mead writes:
> On Wed, Apr 4, 2012 at 12:02 PM, Tom Lane wrote:
>> Well, that's an interesting analogy. Are you arguing that we should
>> always accept any syntactically-valid search_path setting, no matter
>> whether the mentioned schemas exist? It wouldn't be hard to do that.
>I th
Magnus Hagander writes:
> On Wed, Apr 4, 2012 at 17:57, Tom Lane wrote:
>> I rather wonder whether the #ifdef WIN32 bit in the backend isn't dead
>> code though. If the port isn't in nonblock mode, we shouldn't really
>> get here at all, should we?
> Not in a position to look at the code right
Andrew Dunstan writes:
> On 04/02/2012 01:03 PM, Tom Lane wrote:
>> When I said "list", I meant a "List *". No fixed size.
> Ok, like this?
I think this could use a bit of editorialization (I don't think the
"stripe" terminology is still applicable, in particular), but the
general idea seems OK
On Wed, Apr 4, 2012 at 12:02 PM, Tom Lane wrote:
> Scott Mead writes:
> > Personally, I feel that if unix will let you be stupid:
> > $ export PATH=/usr/bin:/this/invalid/crazy/path
> > $ echo $PATH
> > /usr/bin:/this/invalid/crazy/path
> > PG should trust that I'll get where I'm goi
Scott Mead writes:
> Personally, I feel that if unix will let you be stupid:
> $ export PATH=/usr/bin:/this/invalid/crazy/path
> $ echo $PATH
> /usr/bin:/this/invalid/crazy/path
> PG should trust that I'll get where I'm going eventually :)
Well, that's an interesting analogy. Are you
On Wed, Apr 4, 2012 at 17:57, Tom Lane wrote:
> Tatsuo Ishii writes:
>> Those code fragment judges the return value from
>> SSL_read(). secure_read() does retrying when SSL_ERROR_WANT_READ *and*
>> SSL_ERROR_WANT_WRITE returned. However, pqsecure_read() does not retry
>> when SSL_ERROR_WANT_READ.
Tatsuo Ishii writes:
> Those code fragment judges the return value from
> SSL_read(). secure_read() does retrying when SSL_ERROR_WANT_READ *and*
> SSL_ERROR_WANT_WRITE returned. However, pqsecure_read() does not retry
> when SSL_ERROR_WANT_READ. It seems they are not consistent. Comments?
There's
Yeb Havinga writes:
> Using a cursor argument name equal to another plpgsql variable results
> in the error:
> cursor .. has no argument named ""
> The attached patch fixes that.
> Instead of solving the issue like is done in the patch, another way
> would be to expose internal_yylex() so that
umi.tan...@gmail.com writes:
> http://www.postgresql.org/docs/9.1/static/spi-spi-execute.html
> ===
> SPI_execute("INSERT INTO foo SELECT * FROM bar", false, 5);
> will allow at most 5 rows to be inserted into the table.
> ===
> This seems not true unless I'm missing something.
Hmm ... that did
Marko Kreen writes:
> On Tue, Apr 03, 2012 at 05:32:25PM -0400, Tom Lane wrote:
>> Well, there are really four levels to the API design:
>> * Plain old PQexec.
>> * Break down PQexec into PQsendQuery and PQgetResult.
>> * Avoid waiting in PQgetResult by testing PQisBusy.
>> * Avoid waiting in PQse
Shigeru HANADA wrote:
>> During a foreign scan, type input functions are used to convert
>> the text representation of values. If a foreign table is
misconfigured,
>> you can get error messages from these functions, like:
>>
>> ERROR: invalid input syntax for type double precision: "etwas"
>> or
On Wed, Apr 4, 2012 at 6:26 AM, Josh Berkus wrote:
>
> > While I was doing this I always thought this would have been a better
> > approach for my previous project, an accounting application. If I could
> > just have stored entities like invoice & customer as a single document
> that
> > is inse
Hi,
While looking into SSL code in secure_read() of be-secure.c and
pqsecure_read() of fe-secure.c, I noticed subtle difference between
them.
In secure_read:
--
case SSL_ERROR_WANT_READ:
case
On 4.4.2012 05:35, Greg Smith wrote:
> On 03/05/2012 05:20 PM, Tomas Vondra wrote:
>> What is the current state of this effort? Is there someone else working
>> on that? If not, I propose this (for starters):
>>
>>* add a new page "Performance results" to the menu, with a list of
>> member
On 04/04/2012 05:03 AM, Joachim Wieland wrote:
Second, all the PrintStatus traces are annoying and need to be removed, or
perhaps better only output in debugging mode (using ahlog() instead of just
printf())
Sure, PrintStatus is just there for now to see what's going on. My
plan was to remove
On Mon, Apr 2, 2012 at 12:33 PM, Robert Haas wrote:
> This particular example shows the above chunk of code taking >13s to
> execute. Within 3s, every other backend piles up behind that, leading
> to the database getting no work at all done for a good ten seconds.
>
> My guess is that what's happ
On Tue, Apr 3, 2012 at 11:04 AM, Robert Haas wrote:
> OK, but it seems like a pretty fragile assumption that none of the
> workers will ever manage to emit any other error messages. We don't
> rely on this kind of assumption in the backend, which is a lot
> better-structured and less spaghetti-li
Using a cursor argument name equal to another plpgsql variable results
in the error:
cursor .. has no argument named ""
The attached patch fixes that.
Instead of solving the issue like is done in the patch, another way
would be to expose internal_yylex() so that could be used instead of
yylex
On Tue, Apr 3, 2012 at 9:26 AM, Andrew Dunstan wrote:
> First, either the creation of the destination directory needs to be delayed
> until all the sanity checks have passed and we're sure we're actually going
> to write something there, or it needs to be removed if we error exit before
> anything
On Tue, Apr 3, 2012 at 11:12 PM, Greg Stark wrote:
> On Wed, Apr 4, 2012 at 1:19 AM, Dave Page wrote:
>> then, we're talking about making parts of the filesystem
>> world-writeable so it doesn't even matter if the user is running as an
>> admin for a trojan or some other nasty to attack the syste
74 matches
Mail list logo
