Le 22/06/2010 06:40, Takahiro Itagaki a écrit :
[...]
Tom Lane t...@sss.pgh.pa.us 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
On Mon, 2010-06-21 at 20:53 -0400, Robert Haas wrote:
On Mon, Jun 21, 2010 at 7:51 PM, gabrielle gor...@gmail.com 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
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, Feb 15, 2010 at 8:58 PM, Fujii Masao masao.fu...@gmail.com wrote:
On Tue, Feb 16, 2010 at 1:18 AM, Robert Haas robertmh...@gmail.com 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
On Tue, Jun 22, 2010 at 15:20, Robert Haas robertmh...@gmail.com wrote:
On Mon, Feb 15, 2010 at 8:58 PM, Fujii Masao masao.fu...@gmail.com wrote:
On Tue, Feb 16, 2010 at 1:18 AM, Robert Haas robertmh...@gmail.com wrote:
I'm all for this as a 9.1 submission, but let's not commit to trying to
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 is (or
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 only mode
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 the
On Tue, Jun 22, 2010 at 9:27 AM, Magnus Hagander mag...@hagander.net 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
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
this:
On Tue, Jun 22, 2010 at 18:16, Robert Haas robertmh...@gmail.com wrote:
On Tue, Jun 22, 2010 at 9:27 AM, Magnus Hagander mag...@hagander.net 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
On Tue, Jun 22, 2010 at 12:32 PM, Magnus Hagander mag...@hagander.net 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.
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 can
Robert Haas robertmh...@gmail.com 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
Robert Haas robertmh...@gmail.com 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
On Tue, Jun 22, 2010 at 12:50 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com 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
Robert Haas robertmh...@gmail.com writes:
On Tue, Jun 22, 2010 at 12:50 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com 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
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,
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 the
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
On Tue, Jun 22, 2010 at 1:14 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Tue, Jun 22, 2010 at 12:50 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
By that argument, we need to be programming to bare metal on every disk
On Tue, Jun 22, 2010 at 1:17 PM, Mike Fowler m...@mlfowler.com 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
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
Josh Berkus j...@agliodbs.com 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
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.
--
On Tue, Jun 22, 2010 at 1:32 PM, Robert Haas robertmh...@gmail.com 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
On Tue, Jun 22, 2010 at 3:28 PM, Robert Haas robertmh...@gmail.com 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
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,
On Tue, Jun 22, 2010 at 3:45 PM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Jun 22, 2010 at 3:28 PM, Robert Haas robertmh...@gmail.com 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 Tue, Jun 22, 2010 at 1:58 AM, Robert Haas robertmh...@gmail.com 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.
On Tue, Jun 22, 2010 at 9:07 PM, Tom Lane t...@sss.pgh.pa.us 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
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
Andrew Dunstan and...@dunslane.net 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
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
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
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
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
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
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
-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:
Thank
On Wed, Jun 23, 2010 at 5:32 AM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Jun 22, 2010 at 3:45 PM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Jun 22, 2010 at 3:28 PM, Robert Haas robertmh...@gmail.com wrote:
Either I'm doing something wrong,
I think it's this one. Stand by.
41 matches
Mail list logo
