On Wed, Jun 23, 2010 at 5:32 AM, Robert Haas wrote:
> On Tue, Jun 22, 2010 at 3:45 PM, Robert Haas wrote:
>> On Tue, Jun 22, 2010 at 3:28 PM, Robert Haas wrote:
>>> Either I'm doing something wrong,
>>
>> I think it's this one. Stand by.
>
> OK, here's a new version with several fewer bugs.
Si
> -Original Message-
> From: Andrew Dunstan [mailto:and...@dunslane.net]
> Sent: Tuesday, June 22, 2010 7:47 PM
> To: Francis Markham
> Cc: Dann Corbit; pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] Implementation of Date/Time Input Interpretation
>
>
>
> Francis Markham wrote:
>
Francis Markham wrote:
Thank you for your prompt reply.
What is it exactly that you are trying to accomplish?
I want to be able to, from my own script, determine if postgres will
be able to interpret a string as a date or time. If you can suggest a
better way of accomplishing this
I received two errors (described below) in installing 9.0beta2 on Kubuntu
10.04 , RhodiumToad on IRC recommended I post them here.
I did not have a 2.x or 3.x python dev installed, but I was really only
interested in python3 via plython3u.
So...
sudo apt-get install python3-all-dev
Configure work
Thank you for your prompt reply.
> What is it exactly that you are trying to accomplish?
I want to be able to, from my own script, determine if postgres will
be able to interpret a string as a date or time. If you can suggest a
better way of accomplishing this beyond reimplementing your algorith
From: pgsql-hackers-ow...@postgresql.org
[mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Francis Markham
Sent: Tuesday, June 22, 2010 7:13 PM
To: pgsql-hackers@postgresql.org
Subject: [HACKERS] Implementation of Date/Time Input Interpretation
Greetings all,
I am currently implementing a
Greetings all,
I am currently implementing a script to import data into postgres. I would
like to apply the algorithm to detect date and time values, outlined at
http://developer.postgresql.org/pgdocs/postgres/datetime-input-rules.html
However, I am unfamiliar (and somewhat intimidated) by the p
Tom Lane wrote:
Another possibility is to just remove the inside-the-loop error test
altogether: make it just skip till it finds the desired item, and only
throw an error if it hits EOF without finding it. In the case that
the error test is trying to catch, this would mean significantly more
w
Andrew Dunstan writes:
> Tom Lane wrote:
>> In short, parallel pg_restore is guaranteed to fail on any input file
>> made with a pre-8.4 pg_dump on Windows.
> IIRC, you can reproduce this on Unix too by sending the output of
> pg_dump into a pipe. So it's not uniquely a Windows problem.
Right.
Tom Lane wrote:
In short, parallel pg_restore is guaranteed to fail on any input file
made with a pre-8.4 pg_dump on Windows. It may be that there's some
other mechanism involved in the reports we've gotten of parallel restore
failing only some of the time, but I'm thinking that the heretofore
On Tue, Jun 22, 2010 at 9:07 PM, Tom Lane wrote:
> 3. Perhaps pg_dump ought to emit a warning when it can't seek, instead
> of just silently not writing the data offsets. That behavior was okay
> before when lack of data offsets didn't really matter that much, but
> lack of data offsets is a seri
On Tue, Jun 22, 2010 at 1:58 AM, Robert Haas wrote:
> It doesn't? I didn't think it was making any assumptions about the
> ordering data type beyond the fact that it had a default btree
> opclass.
>
Actually, the return type of consistent method was replaced by float8.
Negative values are used
On Tue, Jun 22, 2010 at 3:45 PM, Robert Haas wrote:
> On Tue, Jun 22, 2010 at 3:28 PM, Robert Haas wrote:
>> Either I'm doing something wrong,
>
> I think it's this one. Stand by.
OK, here's a new version with several fewer bugs. This does appear to
work on both Linux and MacOS now, which are
I've dug into the problem reported by Igor Neyman:
http://archives.postgresql.org/pgsql-admin/2010-06/msg00148.php
Unlike previous complainants, Igor was kind enough to supply a pg_dump
archive file that triggers the problem. What I find is that his dump
file contains no data offsets, ie, dataStat
On Tue, Jun 22, 2010 at 3:28 PM, Robert Haas wrote:
> Either I'm doing something wrong,
I think it's this one. Stand by.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make chan
On Tue, Jun 22, 2010 at 1:32 PM, Robert Haas wrote:
> I don't think the burden of proof is on me to demonstrate that there's
> a case where this feature isn't available - we're usually quite
> reluctant to take advantage of platform-specific features unless we
> have strong evidence that they are
> In what environment do you see that causing a problem (compared to
> no keepalive)?
If it were Alpha3 right now, I'd have no issue with it, and if we're
talking about it for 9.1 I'd have no issue with it. I am, however,
extremely reluctant to introduce a default behavior change for Beta3.
--
Josh Berkus wrote:
> We might not want to enable them by default, though.
I have a hard time believing that "enabled by default" is a problem
with the default timings. That would result in sending and
receiving one small packet every two hours on an open connection
with no application traffic
All,
If we *don't* rely on tcp-keepalive for terminating SR connections where
the master is dead, what is the alternative? That issue, IMHO, is a
blocker for 9.0.
If tcp-keepalives are the only idea we have, then we need to work around
the limitations and implement them.
I'll also point out tha
On Tue, Jun 22, 2010 at 1:17 PM, Mike Fowler wrote:
>
>> Look at how the POSITION() pseudofunction is defined around gram.y
>> line 9651. Essentially any special syntax of this type gets converted
>> to a regular function call internally. So in your case I think there
>> will be some function th
On Tue, Jun 22, 2010 at 1:14 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Jun 22, 2010 at 12:50 PM, Tom Lane wrote:
>>> Robert Haas writes:
>>> By that argument, we need to be programming to bare metal on every disk
>>> access. Does anyone want to argue that depending on vendor-specifi
On Jun 22, 2010, at 18:43 , Robert Haas wrote:
> What does bother me is the fact that we are engineering a critical
> aspect of our system reliability around vendor-specific implementation
> details of the TCP stack, and that if any version of any operating
> system that we support (or ever wish to
Excerpts from Robert Haas's message of lun jun 21 22:18:46 -0400 2010:
> In pmdie(), we have the following code, which doesn't seem to make
> much sense. If the state is PM_RECOVERY at the top of this section it
> will get changed to PM_WAIT_BACKENDS and then to PM_WAIT_BACKENDS
> again. Either t
Look at how the POSITION() pseudofunction is defined around gram.y
line 9651. Essentially any special syntax of this type gets converted
to a regular function call internally. So in your case I think there
will be some function that gets called something ike this:
xmlexists(xpath_expression,
Robert Haas writes:
> On Tue, Jun 22, 2010 at 12:50 PM, Tom Lane wrote:
>> Robert Haas writes:
>> By that argument, we need to be programming to bare metal on every disk
>> access. Does anyone want to argue that depending on vendor-specific
>> filesystem functionality is not a house of cards?
On Tue, Jun 22, 2010 at 12:50 PM, Tom Lane wrote:
> Robert Haas writes:
>> What does bother me is the fact that we are engineering a critical
>> aspect of our system reliability around vendor-specific implementation
>> details of the TCP stack, and that if any version of any operating
>> system t
Robert Haas wrote:
> What does bother me is the fact that we are engineering a critical
> aspect of our system reliability around vendor-specific
> implementation details of the TCP stack, and that if any version
> of any operating system that we support (or ever wish to support
> in the future)
Robert Haas writes:
> What does bother me is the fact that we are engineering a critical
> aspect of our system reliability around vendor-specific implementation
> details of the TCP stack, and that if any version of any operating
> system that we support (or ever wish to support in the future) fa
depst...@alliedtesting.com wrote:
> Another issue:
>
> 4. The --link option doesn't seem to work on Windows: pg_upgrade still
> copies data from the old cluster to the new. There doesn't appear to
> be a way to upgrade a database on Windows without copying the entire
> uncompressed database, which
On Tue, Jun 22, 2010 at 12:32 PM, Magnus Hagander wrote:
>> Which brings us to the question of portability. A quick search around
>> the Internet suggests that this is supported on recent versions of
>> Linux, Free/OpenBSD, AIX, and HP/UX, and it appears to work on my Mac
>> also. I'm not clear
On Tue, Jun 22, 2010 at 18:16, Robert Haas wrote:
> On Tue, Jun 22, 2010 at 9:27 AM, Magnus Hagander wrote:
>>> I am inclined to punt the keepalives_interval, keepalives_idle, and
>>> keepalives_count parameters to 9.1. If these are needed for
>>> walreciever to work reliably, this whole approac
depst...@alliedtesting.com wrote:
> PostgreSQL 9.0 beta 2 Windows XP Professional SP2
>
> While migrating the database from 8.4 to 9.0 using pg_upgrade (now part
> of the Postgres project), the following issues came up:
>
> 1. When using the --logfile option, pg_upgrade quits with an error like
>
On Tue, Jun 22, 2010 at 9:27 AM, Magnus Hagander wrote:
>> I am inclined to punt the keepalives_interval, keepalives_idle, and
>> keepalives_count parameters to 9.1. If these are needed for
>> walreciever to work reliably, this whole approach is a dead-end,
>> because those parameters are not por
On Tue, 2010-06-22 at 12:19 +0200, Guillaume Lelarge wrote:
> Shamely simple : I only added some informations on the server's
> properties. See
> http://www.pgadmin.org/images/visualtour12/visualtour08.jpg. We only
> display the fact that the server is (or isn't) in recovery, and the
> result of th
Le 22/06/2010 11:41, Simon Riggs a écrit :
> On Tue, 2010-06-22 at 09:54 +0200, Guillaume Lelarge wrote:
>> I added support for Hot Standby /
>> Streaming Replication in pgAdmin (that was a really small patch, there
>> was not a lot to do)
>
> Well done.
>
> Does this mean that pgAdmin has a read
Le 22/06/2010 12:42, Simon Riggs a écrit :
> On Tue, 2010-06-22 at 12:19 +0200, Guillaume Lelarge wrote:
>> Shamely simple : I only added some informations on the server's
>> properties. See
>> http://www.pgadmin.org/images/visualtour12/visualtour08.jpg. We only
>> display the fact that the server
On Tue, Jun 22, 2010 at 15:20, Robert Haas wrote:
> On Mon, Feb 15, 2010 at 8:58 PM, Fujii Masao wrote:
>> On Tue, Feb 16, 2010 at 1:18 AM, Robert Haas wrote:
I'm all for this as a 9.1 submission, but let's not commit to trying to
debug it now. I would like a green buildfarm for awhil
On Mon, Feb 15, 2010 at 8:58 PM, Fujii Masao wrote:
> On Tue, Feb 16, 2010 at 1:18 AM, Robert Haas wrote:
>>> I'm all for this as a 9.1 submission, but let's not commit to trying to
>>> debug it now. I would like a green buildfarm for awhile before we wrap
>>> alpha4, and this sort of untested "
On Tue, 2010-06-22 at 09:54 +0200, Guillaume Lelarge wrote:
> I added support for Hot Standby /
> Streaming Replication in pgAdmin (that was a really small patch, there
> was not a lot to do)
Well done.
Does this mean that pgAdmin has a read only mode now?
What are the details of that support? I
On Mon, 2010-06-21 at 20:53 -0400, Robert Haas wrote:
> On Mon, Jun 21, 2010 at 7:51 PM, gabrielle wrote:
> > On Thu, 2010-06-17 at 14:50 -0400, Alvaro Herrera asked:
> >> How does it play with ON_ERROR_STOP/ROLLBACK?
> >
> > With ON_ERROR_STOP=ON, psql issues an error when it encounters one,
> >
Le 22/06/2010 06:40, Takahiro Itagaki a écrit :
> [...]
> Tom Lane wrote:
>
>> I'm of the opinion that this is a 9.1 problem. It needs more thought
>> than we can put into it now --- one obvious question is what about
>> monitoring on the slave side? Another is who should be able to see the
>>
41 matches
Mail list logo
