Robert Haas escribió:
I was all prepared to admit that I hadn't actually looked at the patch
carefully enough, but I just looked at (and CVS HEAD) again and what
you've written here doesn't appear to describe what I'm seeing in the
code:
if ((portal-strategy
Jaime Casanova wrote:
On Thu, Feb 11, 2010 at 6:03 AM, Bruce Momjian br...@momjian.us wrote:
Of course, maybe the word LOCATION is wrong and it should be FUNCTION:
? ? ? ?ERROR: ?42P01: relation lkjasdf does not exist at character 15
? ? ? ?FUNCTION: ?parserOpenTable(),
On Thu, Feb 11, 2010 at 2:08 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Bruce Momjian wrote:
FYI, here is the output that had me confused:
ERROR: 42P01: relation lkjasdf does not exist at character 15
LOCATION: parserOpenTable, parse_relation.c:858
STATEMENT:
On Thu, Feb 11, 2010 at 2:38 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Robert Haas escribió:
I was all prepared to admit that I hadn't actually looked at the patch
carefully enough, but I just looked at (and CVS HEAD) again and what
you've written here doesn't appear to describe
Robert Haas escribió:
I'm not quite sure how to do this in practice. One idea would be to
record the catversion that created the relation in pg_class, and make
pg_upgrade preserve the catversion, but make CLUSTER or similar bump
it on successful completion. But I'm not sure if that covers
Robert Haas escribió:
On Thu, Feb 11, 2010 at 2:38 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Robert Haas escribió:
I was all prepared to admit that I hadn't actually looked at the patch
carefully enough, but I just looked at (and CVS HEAD) again and what
you've written here
On Thu, Feb 11, 2010 at 01:22:44PM -0500, Kevin Grittner wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote:
I think 'rsync' has the same problem.
There is a switch you can use to create the problem under rsync, but
by default rsync copies to a temporary file name and
On Thu, Feb 11, 2010 at 2:47 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Robert Haas escribió:
On Thu, Feb 11, 2010 at 2:38 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Robert Haas escribió:
I was all prepared to admit that I hadn't actually looked at the patch
On Thu, Feb 11, 2010 at 2:46 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Robert Haas escribió:
I'm not quite sure how to do this in practice. One idea would be to
record the catversion that created the relation in pg_class, and make
pg_upgrade preserve the catversion, but make
Alvaro Herrera írta:
Boszormenyi Zoltan escribió:
Robert Haas írta:
...
OK, please change it.
New patch is attached with the discussed changes.
This looks all wrong. PORTAL_ONE_SELECT is now being passed through
FillPortalStore,
Where do you read that? The
Robert Haas escribió:
On Thu, Feb 11, 2010 at 2:46 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Robert Haas escribió:
I'm not quite sure how to do this in practice. One idea would be to
record the catversion that created the relation in pg_class, and make
pg_upgrade preserve
Alvaro Herrera írta:
Robert Haas escribió:
On Thu, Feb 11, 2010 at 2:38 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Robert Haas escribió:
I was all prepared to admit that I hadn't actually looked at the patch
carefully enough, but I just looked at (and CVS HEAD)
On Tue, Feb 09, 2010 at 12:37:32PM +0900, Hitoshi Harada wrote:
I know +/- part is an issue. But as far as I know there's been no
infrastructure to handle such situation. My ideal plan is to introduce
some mechanism to make +/- operation abstract enough such like
sort opclass/opfamily,
Bruce Momjian br...@momjian.us writes:
Jaime Casanova wrote:
i like this with or without the (), but maybe we are breaking client
apps if change that
Ah, so you like FUNCTION.
You can NOT change the line tag without almost certainly breaking
log-reading tools like pgfouine. Even changing
Martijn van Oosterhout klep...@svana.org writes:
On Tue, Feb 09, 2010 at 12:37:32PM +0900, Hitoshi Harada wrote:
Now that specialized hard-coding +/- in source seems unacceptable,
I would like to hear how to handle this. Is there any better than
introducing new mechanism such like opclass?
I
On Wed, Feb 10, 2010 at 11:00:00AM +0900, Takahiro Itagaki wrote:
Bruce Momjian br...@momjian.us wrote:
Where are we on this patch? We should at least implement the completion
for 'LANGUAGE' in 'DO', and use the existing pg_language query for
completion. I am attaching a patch that does
Simon Riggs si...@2ndquadrant.com writes:
I understand that the final process to switch from one release to
another needs to be quick. Before that we can have any number of
preparatory steps. One of those is backup, if you're sane. Another one
should be a preparatory step that can be performed
On Thu, Feb 11, 2010 at 3:26 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Martijn van Oosterhout klep...@svana.org writes:
On Tue, Feb 09, 2010 at 12:37:32PM +0900, Hitoshi Harada wrote:
Now that specialized hard-coding +/- in source seems unacceptable,
I would like to hear how to handle this. Is
Robert Haas robertmh...@gmail.com writes:
On Thu, Feb 11, 2010 at 3:26 PM, Tom Lane t...@sss.pgh.pa.us wrote:
The real question is whether it's time to bite the bullet and stop
overloading the opclass infrastructure for semantics-declaration
purposes. Are there any other foreseeable cases
On Thu, 11 Feb 2010, Robert Haas wrote:
On Thu, Feb 11, 2010 at 3:26 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Martijn van Oosterhout klep...@svana.org writes:
On Tue, Feb 09, 2010 at 12:37:32PM +0900, Hitoshi Harada wrote:
Now that specialized hard-coding +/- in source seems unacceptable,
I
On Thu, 2010-02-11 at 19:29 +0200, Heikki Linnakangas wrote:
Aidan Van Dyk wrote:
* Heikki Linnakangas heikki.linnakan...@enterprisedb.com [100211 09:17]:
Yeah, if you're careful about that, then this change isn't required. But
pg_standby protects against that, so I think it'd be
Robert Haas robertmh...@gmail.com writes:
On Mon, Feb 8, 2010 at 10:37 PM, Hitoshi Harada umi.tan...@gmail.com wrote:
2010/2/9 Tom Lane t...@sss.pgh.pa.us:
Given the lack of time remaining in this CF, I'm tempted to propose
ripping out the RANGE support and just trying to get ROWS committed.
Tom Lane t...@sss.pgh.pa.us writes:
However, what it *is* associated with is a sort ordering, and the notion
that btree opclasses are what define orderings is sufficiently deeply
wired into the system that undoing it would be a huge PITA. So unless
we can see a pretty clear future need for
Dimitri Fontaine dfonta...@hi-media.com writes:
Tom Lane t...@sss.pgh.pa.us writes:
However, what it *is* associated with is a sort ordering, and the notion
that btree opclasses are what define orderings is sufficiently deeply
wired into the system that undoing it would be a huge PITA. So
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, Feb 11, 2010 at 03:19:14PM +0100, Dimitri Fontaine wrote:
Robert Haas robertmh...@gmail.com writes:
It seems that you're sort of frustrated with the system and the need
to go through a process before committing a patch;
I've been
On Thu, Feb 11, 2010 at 16:36, Mark Mielke m...@mark.mielke.cc wrote:
On 02/11/2010 08:13 AM, Bart Samwel wrote:
ISSUE #2: Reverse lookup?
There was a suggestion on the TODO list on the wiki, which basically said
that maybe we could use reverse lookup to find the hostname and then check
On 02/11/2010 04:54 PM, Bart Samwel wrote:
On Thu, Feb 11, 2010 at 16:36, Mark Mielke m...@mark.mielke.cc
mailto:m...@mark.mielke.cc wrote:
ISSUE #3: Multiple hostnames?
Currently, a pg_hba entry lists an IP / netmask combination. I
would suggest allowing lists of hostnames in
On Thu, Feb 11, 2010 at 17:21, Tom Lane t...@sss.pgh.pa.us wrote:
Bart Samwel b...@samwel.tk writes:
I've been working on a patch to add hostname support to pg_hba.conf.
Have you read the previous discussions about that?
Yes, mostly.
The previous discussions included all sorts of complex
On Thu, Feb 11, 2010 at 23:01, Mark Mielke m...@mark.mielke.cc wrote:
On 02/11/2010 04:54 PM, Bart Samwel wrote:
ISSUE #3: Multiple hostnames?
Currently, a pg_hba entry lists an IP / netmask combination. I would
suggest allowing lists of hostnames in the entries, so that you can at least
Thank you very much for the advice. Yes I think it should go to
announce. I will post a message.
--
Koichi Suzuki
2010/2/12 Karl Denninger k...@denninger.net:
Joshua D. Drake wrote:
On Thu, 2010-02-11 at 23:39 +0900, Koichi Suzuki wrote:
Dear Folks;
A very serious bug was
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
Jaime Casanova wrote:
i like this with or without the (), but maybe we are breaking client
apps if change that
Ah, so you like FUNCTION.
You can NOT change the line tag without almost certainly breaking
log-reading tools like
In addition, in the fix, I'm thinking I should add at least the
following check mechanism;
1. Check XNOOP record size to match the original WAL record.
2. Restore WAL segment at the time of pg_compress, compare restored
WAL with the original and check it is safe to use in the restoration,
both
On Thu, Feb 11, 2010 at 5:47 PM, Bruce Momjian br...@momjian.us wrote:
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
Jaime Casanova wrote:
i like this with or without the (), but maybe we are breaking client
apps if change that
Ah, so you like FUNCTION.
You can NOT change the
On Thu, Feb 11, 2010 at 4:31 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Mon, Feb 8, 2010 at 10:37 PM, Hitoshi Harada umi.tan...@gmail.com wrote:
2010/2/9 Tom Lane t...@sss.pgh.pa.us:
Given the lack of time remaining in this CF, I'm tempted to propose
On Wed, 2010-02-10 at 23:13 -0500, Greg Smith wrote:
Until then, working apps have to
be the primary motivation for what to work on here, unless there's a
really terrible problem with the driver. The existing psycopg license
and the web site issues were in combination enough to reach that
David Fetter da...@fetter.org wrote:
Syntax of DO command is:
DO code [ LANGUAGE lang_name ]
That's not the only syntax.
DO [LANGUAGE lang_name] code
also works, e.g.:
Hmmm, but we mention only above syntax in the documentation.
2010/2/12 Tom Lane t...@sss.pgh.pa.us:
The real question is whether it's time to bite the bullet and stop
overloading the opclass infrastructure for semantics-declaration
purposes. Are there any other foreseeable cases where we are going
to need to add operator knowledge of this sort?
Table
Takahiro Itagaki escreveu:
Should we fix the documentation when we add the tab completion?
Yes, it seems consistent with other commands having optional parameters in the
middle of the command rather than at the end.
--
Euler Taveira de Oliveira
http://www.timbira.com/
--
Sent via
On Wed, Feb 10, 2010 at 8:16 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
If they want to implement the warm standby using the (new) built-in
logic to keep retrying restore_command, they would set
standby_mode='on'. standby_mode='on' doesn't imply streaming replication.
On 02/11/2010 05:12 PM, Bart Samwel wrote:
On Thu, Feb 11, 2010 at 23:01, Mark Mielke m...@mark.mielke.cc
mailto:m...@mark.mielke.cc wrote:
On 02/11/2010 04:54 PM, Bart Samwel wrote:
ISSUE #3: Multiple hostnames?
Currently, a pg_hba entry lists an IP / netmask
On Fri, Feb 12, 2010 at 09:24:55AM +0900, Takahiro Itagaki wrote:
David Fetter da...@fetter.org wrote:
Syntax of DO command is:
DO code [ LANGUAGE lang_name ]
That's not the only syntax.
DO [LANGUAGE lang_name] code
also works, e.g.:
Hmmm, but we mention only above
On Thu, Feb 11, 2010 at 11:26:10PM -0200, Euler Taveira de Oliveira wrote:
Takahiro Itagaki escreveu:
Should we fix the documentation when we add the tab completion?
Yes, it seems consistent with other commands having optional
parameters in the middle of the command rather than at the end.
David Fetter escreveu:
It's consistent with how we do CREATE FUNCTION, where the order of
parameters after RETURNS is arbitrary.
If it is arbitrary the synopsis is wrong because it is imposing that code
should be written after DO. It should be:
DO { [ LANGUAGE lang_name ] | code } ...
--
On Fri, Feb 12, 2010 at 12:21:02AM -0200, Euler Taveira de Oliveira wrote:
David Fetter escreveu:
It's consistent with how we do CREATE FUNCTION, where the order of
parameters after RETURNS is arbitrary.
If it is arbitrary the synopsis is wrong because it is imposing that
code should be
Mark Mielke escreveu:
Of course, then I'll ask for the ability to simplify specifying multiple
databases:
We already support multiple users and/or databases for a single pg_hba.conf
line ...
--
Euler Taveira de Oliveira
http://www.timbira.com/
--
Sent via pgsql-hackers mailing list
On Fri, Feb 12, 2010 at 1:33 AM, Peter Geoghegan
peter.geoghega...@gmail.com wrote:
Why hasn't libpq had keepalives for years?
I guess that it's because keepalive doesn't work as expected
in some cases. For example, if the network outage happens
before a client sends some packets, keepalive
On Thu, Feb 11, 2010 at 12:35 PM, Marko Tiikkaja
marko.tiikk...@cs.helsinki.fi wrote:
On Thu, 11 Feb 2010 19:28:28 +0200, I wrote:
On Thu, 11 Feb 2010 10:53:22 -0500, Robert Haas robertmh...@gmail.com
wrote:
On Thu, Feb 11, 2010 at 8:46 AM, Marko Tiikkaja
marko.tiikk...@cs.helsinki.fi wrote:
On Wed, Feb 10, 2010 at 5:53 PM, Kurt Harriman harri...@acm.org wrote:
Revised patch is attached (4th edition).
This looks generally sane to me, though it seems entirely imaginable
that it might break something, somewhere, for somebody... in which
case I suppose we'll adjust as needed.
Peter,
On 02/11/2010 09:38 PM, Euler Taveira de Oliveira wrote:
Mark Mielke escreveu:
Of course, then I'll ask for the ability to simplify specifying multiple
databases:
We already support multiple users and/or databases for a single pg_hba.conf
line ...
Is there a reason you trimmed
Robert Haas robertmh...@gmail.com writes:
This looks simple and useful. I haven't tested it, but if it's really
this easy, we should definitely do it.
I should be out from under the window functions patch tomorrow,
will look at this one then.
regards, tom lane
--
On Wed, Feb 10, 2010 at 6:04 PM, Kurt Harriman harri...@acm.org wrote:
By the way, suggestions which must be carried out without
question are orders, not advice. When a statement,
meant to be imperative, is phrased softly as advice, it can
easily be mistaken as optional by newcomers who may
On Fri, Feb 12, 2010 at 12:11 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
This looks simple and useful. I haven't tested it, but if it's really
this easy, we should definitely do it.
I should be out from under the window functions patch tomorrow,
will
On Thu, Feb 11, 2010 at 11:22 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Simon Riggs wrote:
Might it not be simpler to add a parameter onto pg_standby?
We send %s to tell pg_standby the standby_mode of the server which is
calling it so it can decide how to act in each
Fujii Masao wrote:
On Wed, Feb 10, 2010 at 8:16 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
If they want to implement the warm standby using the (new) built-in
logic to keep retrying restore_command, they would set
standby_mode='on'. standby_mode='on' doesn't imply
On Fri, Feb 12, 2010 at 3:19 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Fujii Masao wrote:
On Wed, Feb 10, 2010 at 8:16 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
If they want to implement the warm standby using the (new) built-in
logic to keep
On Fri, Feb 12, 2010 at 7:28 AM, Fujii Masao masao.fu...@gmail.com wrote:
Yeah, even if primary_conninfo is not given, the standby tries to invoke
walreceiver by using the another connection settings (environment variables
or defaults). This is intentional behavior, and would make the setup of
On Wed, Feb 3, 2010 at 6:41 PM, Andrew Dunstan and...@dunslane.net wrote:
Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
%_SHARED has been around for several years now, and if there are genuine
security concerns about it ISTM they would apply today, regardless of these
Fujii Masao wrote:
On Fri, Feb 12, 2010 at 3:19 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Fujii Masao wrote:
But if we fail in restoring the archived WAL file, standby_mode = on
*always* tries to start streaming replication.
Hmm, somehow I thought it doesn't if you
The solution is to write the query in an unambiguous way:
SELECT $1::date + 1;
which is good practice, anyway. If it's not obvious to the type
inference system, it's probably not obvious to you, and will probably
surprise you ;)
That address this specific case, but it's ugly and not general.
Obviously this is less urgent than having a driver that works now, but
it's still important. I think we would attract some goodwill from the
python community if we were helping them move to python3, rather than
sitting around waiting 'til they've already moved and decided that they
can't use
Simon Riggs wrote:
On Thu, 2010-02-11 at 13:08 -0500, Tom Lane wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
-1. it isn't necessary for PITR. It's a new requirement for
standby_mode='on', unless we add the file size check into the backend. I
think we should add the
Fujii Masao wrote:
On Fri, Feb 12, 2010 at 4:04 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Fujii Masao wrote:
On Fri, Feb 12, 2010 at 3:19 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Fujii Masao wrote:
But if we fail in restoring the archived WAL
Joachim Wieland wrote:
On Fri, Feb 12, 2010 at 7:28 AM, Fujii Masao masao.fu...@gmail.com wrote:
Yeah, even if primary_conninfo is not given, the standby tries to invoke
walreceiver by using the another connection settings (environment variables
or defaults). This is intentional behavior, and
101 - 163 of 163 matches
Mail list logo
