Hi Alex,
I saw related checkins. This issue was actually fixed on 4th October, the
day on which 9.0.1 was released and 9.0.1 build missed this issue. If you
want a work around then please take required uuid library from 8.4
installation. Please let me know if you still have any issue related to
th
Excerpts from Mark Kirkwood's message of jue oct 28 02:20:56 -0300 2010:
> I'm seeing this on a Pitrtools managed warm standby box that we
> periodically bring the db fully up on in order to test if the standby is
> good.
>
> After the standby is up, then a db wide VACUUM produces:
>
> 2010-10-
Hi Dharmendra,
Thank you for confirming this and your time. If there are future plans by
EnterpriseDB to rebuild another version of the one-click installer for
PostgreSQL 9.0 and include the bug #5677 fix for Linux that would be great!
Regards,
Alexia
From: Dharmendra Goyal [mailto:dharmendra.
On 29/10/10 04:32, Alvaro Herrera wrote:
Excerpts from Mark Kirkwood's message of jue oct 28 02:20:56 -0300 2010:
I'm guessing the index error is due to the uninitialized table pages
(the index "content_node_node_type_id_inserted_idx" is on the "node"
table).
Not necessarily ... You s
Mark Kirkwood writes:
> On 29/10/10 04:32, Alvaro Herrera wrote:
>> Excerpts from Mark Kirkwood's message of jue oct 28 02:20:56 -0300 2010:
>>> I'm guessing the index error is due to the uninitialized table pages
>>> (the index "content_node_node_type_id_inserted_idx" is on the "node"
>>> table).
The following bug has been logged online:
Bug reference: 5732
Logged by: Josh Kupershmidt
Email address: schmi...@gmail.com
PostgreSQL version: 8.3 and HEAD
Operating system: Linux and OS X
Description:parsing of: "WHERE mycol=123AND ..."
Details:
I noticed that Pos
On 29/10/10 10:27, Tom Lane wrote:
Were there similar warnings on the master? Uninitialized-page warnings
are expected in certain error-recovery scenarios, but I'd be a little
worried if the slave appeared to be out of sync with the master.
I don't see any in the
"Josh Kupershmidt" writes:
> I noticed that Postgres in many cases will happily tokenize WHERE clauses
> having no space between a condition and "AND" or "OR".
This has nothing to do with AND or OR. Any situation where you have
some digits followed by something that can't be part of a number wi
On Thu, 2010-10-28 at 23:46 +, Josh Kupershmidt wrote:
> SELECT * FROM mytab WHERE mycol = 2OR true;
Is that inconsistent with the standard?
Other languages seem to allow similar things, such as ruby and perl. For
instance, in ruby:
puts 1if(true)
seems to be acceptable.
> although som
Jeff Davis writes:
> On Thu, 2010-10-28 at 23:46 +, Josh Kupershmidt wrote:
>> SELECT * FROM mytab WHERE mycol = 2OR true;
> Is that inconsistent with the standard?
I was just looking at that. The spec lumps both and under , and says that there
must be a (ie, whitespace or comment) betwe
On Thu, Oct 28, 2010 at 8:01 PM, Tom Lane wrote:
> "Josh Kupershmidt" writes:
>> I noticed that Postgres in many cases will happily tokenize WHERE clauses
>> having no space between a condition and "AND" or "OR".
>
> This has nothing to do with AND or OR. Any situation where you have
> some digi
On Thu, Oct 28, 2010 at 8:03 PM, Jeff Davis wrote:
> I don't really see a "bug" here. Is this causing you some kind of
> problem?
I happened to notice it while fixing up some code using multi-line
strings which had forgotten to put spaces in the SQL across lines. I
was just surprised Postgres did
Josh Kupershmidt writes:
> The only mild concern I have is if this could possibly lead to
> ambiguous parsing in some situations, though I've played with some
> examples and I haven't seen any yet. It would be nice to have this
> behavior documented somewhere though.
The fine manual currently say
Folks,
This doc says we ought to have the ssl_ciphers parameter:
http://www.postgresql.org/docs/9.0/static/runtime-config-connection.html#RUNTIME-CONFIG-CONNECTION-SECURITY
Nor is there anything in the 9.0 release notes about it going away.
Yet:
postgres=# select version();
On Thu, Oct 28, 2010 at 22:33, Josh Berkus wrote:
> Folks,
>
> This doc says we ought to have the ssl_ciphers parameter:
>
> http://www.postgresql.org/docs/9.0/static/runtime-config-connection.html#RUNTIME-CONFIG-CONNECTION-SECURITY
>
> Nor is there anything in the 9.0 release notes about it going
15 matches
Mail list logo
