One of our customers seems to be running into exactly the issue
hypothesized about by Tom here:
http://www.postgresql.org/message-id/8040.1314403...@sss.pgh.pa.us
That is, the server is in low-memory conditions, and the client
occasionally issues an error saying it can't complete a certain action
Hi,
I noticed a couple of missing words (at least to my reading) in the
bgworker doc. This changes "...is started including the module name..." to
"...is started by including the module name..." and "...to obtain
information the status of the worker." to "...to obtain information
regarding the sta
On Fri, Feb 24, 2012 at 3:31 PM, Daniel Farina wrote:
> Having been in this position once before in a different but similar
> situation, there's one big caveat: initdb is *really* slow, so it is
> really painful for people who write Postgres-linked code that is
> compiled separately, whereby the i
I apologize. I guess the Travis CI integration is a little better than I
expected. I'm traveling but will turn off notifications as soon as I have a
chance to.
Per Peter's comment there is more info in the GitHub project, and I welcome
any feedback. I'll follow up with more once this is a little m
t a custom driver build, that would be
easier to investigate.
---
Maciek Sakrejda | System Architect | Truviso
1065 E. Hillsdale Blvd., Suite 215
Foster City, CA 94404
(650) 242-3500 Main
www.truviso.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to
> Text format is marked as 0, binary format is 1.
Sorry--I misread the docs. This is consistent and something does look fishy.
Thanks for the tarball. I can take a look tonight.
---
Maciek Sakrejda | System Architect | Truviso
1065 E. Hillsdale Blvd., Suite 215
Foster City, CA 94404
(650)
I'll try to look into this some more, but first of all, is the client
sequence above valid? As far as I can tell, it is. I'm guessing that
the root of the problem is providing the parameter as text and
requesting it back in binary, but I'll freely admit my knowledge of
the internals
s not what Radosław saw (his original test
only failed once named prepared statements kicked in)...
---
Maciek Sakrejda | System Architect | Truviso
1065 E. Hillsdale Blvd., Suite 215
Foster City, CA 94404
(650) 242-3500 Main
www.truviso.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@post
h the expected behavior you've noted.
Actually, the driver sends Parse / Bind / Describe with the unnamed
statement, but for some reason switches to Parse / Describe / Bind
with named ones.
---
Maciek Sakrejda | System Architect | Truviso
1065 E. Hillsdale Blvd., Suite 215
Foster City, CA
little confusing
that the result codes for "I don't know what format this will be in"
and "this will be in text format" are aliased.
It's too late to do anything about the second one and it's only a minor quibble.
Thanks for the help in making sense of this.
---
Mac
age
> with statement parameter's type int4, int8, varchar the format
> field wasn't set to 0, but 1.
I wasn't able to reproduce that with my standalone test case. When I
changed the parameter oid to 23, I still got the same behavior. Can
you alter my test case to reproduce
|| (!oneShot &&
paramsHasUnknown && queryHasUnknown && !query.isStatementDescribed());
---
Maciek Sakrejda | System Architect | Truviso
1065 E. Hillsdale Blvd., Suite 215
Foster City, CA 94404
(650) 242-3500 Main
www.truviso.com
--
Sent via pgsql-hackers mailing list (p
server does have this information, but I'm not surprised
that it doesn't send it correctly, since it seems pointless to send
the statement variation after already doing a Bind.
You may be able to change the JDBC code to call sendDescribePortal() instead.
---
Maciek Sakrejda | System Archite
While having more docs around extra_float_digits is a great idea, I
don't think the patch really clarifies much.
(Disclaimer: I honestly have only a vague idea of the reasoning behind
extra_float_digits existing in the first place, but perhaps that means
I'm a good target audience for the doc patc
On Sun, Mar 3, 2013 at 9:14 PM, Tom Lane wrote:
> The real difficulty is that there may be more than one storable value
> that corresponds to "1.23456" to six decimal digits. To be certain that
> we can reproduce the stored value uniquely, we have to err in the other
> direction, and print *more*
On Tue, Mar 5, 2013 at 12:03 AM, Albe Laurenz wrote:
> I don't think that it is about looking nice.
> C doesn't promise you more than FLT_DIG or DBL_DIG digits of
> precision, so PostgreSQL cannot either.
>
> If you allow more, that would mean that if you store the same
> number on different platf
On Tue, Mar 5, 2013 at 10:23 AM, Tom Lane wrote:
>> Why the discrepancy between
>> default behavior and what pg_dump gets?
>
> Basically, the default behavior is tuned to the expectations of people
> who think that what they put in is what they should get back, ie we
> don't want the system doing
VACUUM FREEZE sets both vacuum_freeze_min_age and vacuum_freeze_table_age
to 0, but only the former is documented. This patch notes that the other
setting is also affected.
(now with patch--sorry about that)
diff --git a/doc/src/sgml/ref/vacuum.sgml b/doc/src/sgml/ref/vacuum.sgml
index eb71581..5f03343 100644
--- a/doc/src/sgml/ref/vacuum.sgml
+++ b/doc/src/sgml/ref/vacuum.sgml
@@ -100,8 +100,9 @@ VACUUM [ FULL ] [ FREEZE ] [ VERBOSE ] ANALYZE [
Select
Hello,
I wanted to follow up on a bug report [1] from October. In a reply, Heikki
conceded that there does seem to be an issue with how Postgres interacts
with OpenSSL, but the nature of the API makes it difficult to fix.
I'm with Heroku Postgres, and though the issue is not Heroku-specific, it
d
On Sun, Jan 25, 2015 at 11:13 PM, Heikki Linnakangas <
hlinnakan...@vmware.com> wrote:
> I couldn't come up with any good solutions. I would suggest speaking to
> the OpenSSL folk. They must be aware of the issue, so what do they
> recommend, do they have any plans to fix it, and if there's anythi
21 matches
Mail list logo
