On Sat, 2009-10-31 at 14:24 +0200, Peter Eisentraut wrote:
I have discovered an obscure segfault condition in PL/Python. In
PLy_output(), when the elog() call in the TRY branch throws an exception
(this can happen when a statement timeout kicks in, for example), the
PyErr_SetString() call in
Tom Lane wrote:
I wonder why backup_label isn't automatically removed
in normal crash recovery case.
Removing it automatically could be catastrophic if done
incorrectly, no?
It would be no less catastrophic if done incorrectly from outside the
postmaster; see for example the problems
Robert Haas escribió:
On Mon, Nov 2, 2009 at 12:40 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Robert Haas escribió:
I don't see anything in this code that is very rel-specific, so I
think it would be possible to implement spcoptions by just defining
RELOPT_KIND_TABLESPACE and
On Sun, 2009-09-27 at 21:49 -0400, Robert Haas wrote:
On Wed, Sep 23, 2009 at 3:26 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Jaime Casanova jcasa...@systemguards.com.ec writes:
i extracted the functions to connect that Heikki put on psql in his
patch for determining client_encoding from client
On Tue, Nov 3, 2009 at 6:25 AM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
If this is the case, then I think we could just decide that their name
is reloptions due to hysterical reasons and be done with it.
Yeah. It's particularly unfortunate that we call them reloptions in
the code
Robert Haas robertmh...@gmail.com writes:
Le 1 nov. 2009 à 13:43, Greg Stark gsst...@mit.edu a écrit :
We could have a column for all booleans, a column for all integers,
etc. but that's not really any more normalized than having a single
column for all the types with a rule for how to
Robert Haas escribió:
On Tue, Nov 3, 2009 at 6:25 AM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
If this is the case, then I think we could just decide that their name
is reloptions due to hysterical reasons and be done with it.
Yeah. It's particularly unfortunate that we call
On Tue, Nov 3, 2009 at 7:44 AM, Dimitri Fontaine dfonta...@hi-media.com wrote:
Robert Haas robertmh...@gmail.com writes:
Le 1 nov. 2009 à 13:43, Greg Stark gsst...@mit.edu a écrit :
We could have a column for all booleans, a column for all integers,
etc. but that's not really any more
On Tue, Nov 3, 2009 at 7:51 AM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Robert Haas escribió:
On Tue, Nov 3, 2009 at 6:25 AM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
If this is the case, then I think we could just decide that their name
is reloptions due to hysterical
We had a discussion back in July about our maintenance policy and the
upshot of that discussion was that there were relatively few
objections to dropping support for 7.4 - I believe Andrew Dunstan was
the only one who spoke against it, and it wasn't clear how strenuous
his objections were - but
Peter Eisentraut pete...@gmx.net writes:
Is anyone planning to do further work on this? This appears to be
blocking the client_encoding=auto feature.
Huh? Why would there be any linkage? This is just offering an
alternative way to set connection options, it has nothing to do
with what the
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
Here's an example that exercises those paths:
postgres=# SELECT 'aa' NOT SIMILAR TO 123;
ERROR: function pg_catalog.similar_escape(integer, unknown) does not exist
LINE 1: SELECT 'aa' NOT SIMILAR TO 123;
On Tue, 2009-11-03 at 09:32 -0500, Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
Is anyone planning to do further work on this? This appears to be
blocking the client_encoding=auto feature.
Huh? Why would there be any linkage? This is just offering an
alternative way to set
Robert Haas wrote:
We had a discussion back in July about our maintenance policy and the
upshot of that discussion was that there were relatively few
objections to dropping support for 7.4 - I believe Andrew Dunstan was
the only one who spoke against it, and it wasn't clear how strenuous
his
Albe == Albe Laurenz laurenz.a...@wien.gv.at writes:
Albe Removing postmaster.pid can lead to a corrupt database.
Albe Removing backup_label means that one of your backups will go
Albe wrong, and a subsequent pg_stop_backup() will throw an error.
Albe If you have a cluster failover during
Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
Is anyone planning to do further work on this? This appears to be
blocking the client_encoding=auto feature.
Huh? Why would there be any linkage? This is just offering an
alternative way to set connection options, it has nothing to
2009/11/3 Andrew Dunstan and...@dunslane.net:
Robert Haas wrote:
We had a discussion back in July about our maintenance policy and the
upshot of that discussion was that there were relatively few
objections to dropping support for 7.4 - I believe Andrew Dunstan was
the only one who spoke
Andrew Dunstan and...@dunslane.net writes:
Robert Haas wrote:
Part of the reason I suggest this is because it seems that not much
gets patched back that far any more.
Tom just backpatched something to 7.4 the other day.
A quick look in the cvs history shows 5 commits to 7.4 since the last
Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote:
LINE 1: SELECT 'aa' NOT SIMILAR TO 123;
^
LINE 1: SELECT 'aa' SIMILAR TO 123;
^
I think the former error location is better.
So do I.
-Kevin
--
Sent via
[ after further thought... ]
Andrew Gierth and...@tao11.riddles.org.uk writes:
How do you distinguish between these two scenarios:
1) you're starting up in a data dir where you crashed in the middle of
a backup
2) you're starting up in a data dir that is a restore of a base backup,
Tom Lane escribió:
A quick look in the cvs history shows 5 commits to 7.4 since the last
set of releases, 6 commits to 8.0, 8 to 8.1, 13 to 8.2, 18 to 8.3.
A couple of these patches were Windows-specific and were made only back
to 8.2 because we desupported Windows in older branches awhile
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote:
LINE 1: SELECT 'aa' NOT SIMILAR TO 123;
^
LINE 1: SELECT 'aa' SIMILAR TO 123;
^
I think the former error location is
Magnus Hagander wrote:
2009/11/3 Andrew Dunstan and...@dunslane.net:
Robert Haas wrote:
We had a discussion back in July about our maintenance policy and the
upshot of that discussion was that there were relatively few
objections to dropping support for 7.4 - I believe Andrew Dunstan was
the
On Tue, 2009-11-03 at 13:01 -0300, Alvaro Herrera wrote:
Tom Lane escribió:
A quick look in the cvs history shows 5 commits to 7.4 since the last
set of releases, 6 commits to 8.0, 8 to 8.1, 13 to 8.2, 18 to 8.3.
A couple of these patches were Windows-specific and were made only back
to
2009/11/3 Simon Riggs si...@2ndquadrant.com:
On Tue, 2009-11-03 at 13:01 -0300, Alvaro Herrera wrote:
Tom Lane escribió:
A quick look in the cvs history shows 5 commits to 7.4 since the last
set of releases, 6 commits to 8.0, 8 to 8.1, 13 to 8.2, 18 to 8.3.
A couple of these patches were
On Tue, Nov 3, 2009 at 4:29 PM, Simon Riggs si...@2ndquadrant.com wrote:
Unless there are unfixable data loss bugs in it, I say we keep it.
Many people still run it, so why make them move?
There are non-trivial amounts of effort required to produce and test
packages for each branch we
Tom Lane t...@sss.pgh.pa.us wrote:
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote:
LINE 1: SELECT 'aa' NOT SIMILAR TO 123;
^
LINE 1: SELECT 'aa' SIMILAR TO 123;
^
I
On Tue, 2009-11-03 at 16:37 +, Dave Page wrote:
On Tue, Nov 3, 2009 at 4:29 PM, Simon Riggs si...@2ndquadrant.com wrote:
Unless there are unfixable data loss bugs in it, I say we keep it.
Many people still run it, so why make them move?
There are non-trivial amounts of effort
Tom Lane wrote:
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote:
LINE 1: SELECT 'aa' NOT SIMILAR TO 123;
^
LINE 1: SELECT 'aa' SIMILAR TO 123;
^
I think the former
2009/11/3 Simon Riggs si...@2ndquadrant.com:
On Tue, 2009-11-03 at 16:37 +, Dave Page wrote:
On Tue, Nov 3, 2009 at 4:29 PM, Simon Riggs si...@2ndquadrant.com wrote:
Unless there are unfixable data loss bugs in it, I say we keep it.
Many people still run it, so why make them move?
On Mon, 2009-11-02 at 18:28 +, Simon Riggs wrote:
I like the NOT here because CHECK NOT = seems to convey pretty
clearly what it is you are checking for. Because NOT is reserved and
can't appear as a connective, I think that this approach might allow
a non-reserved leading word, thus
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
BTW, the corresponding error in the SIMILAR TO ... ESCAPE ... syntax is:
postgres=# SELECT 'aa' SIMILAR TO 123 ESCAPE 'f';
ERROR: function pg_catalog.similar_escape(integer, unknown) does not exist
LINE 1: SELECT 'aa' SIMILAR TO
Simon Riggs si...@2ndquadrant.com writes:
Personally, I would be more inclined to keep 7.4 as a supported version
and remove support for 8.0, possibly 8.1 also.
That would be basically useless from a maintenance-effort perspective
--- if you don't work back through the branches in a methodical
Tom Lane wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
BTW, the corresponding error in the SIMILAR TO ... ESCAPE ... syntax is:
postgres=# SELECT 'aa' SIMILAR TO 123 ESCAPE 'f';
ERROR: function pg_catalog.similar_escape(integer, unknown) does not exist
LINE 1:
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Tom Lane t...@sss.pgh.pa.us wrote:
Uh, why? It looks like it's complaining about the constant 123,
not about the operator.
I wrote that before I saw your post, which left me ambivalent. My
thinking was that it seems clearest to me when it
Jeff Davis pg...@j-davis.com writes:
I'm not excited about using NOT, because I think it has a hint of a
double-negative when combined with EXCLUSION.
Well, the choice of EXCLUSION isn't set in stone either ...
regards, tom lane
--
Sent via pgsql-hackers mailing list
On Tue, 2009-11-03 at 16:37 +, Dave Page wrote:
On Tue, Nov 3, 2009 at 4:29 PM, Simon Riggs si...@2ndquadrant.com wrote:
Unless there are unfixable data loss bugs in it, I say we keep it.
Many people still run it, so why make them move?
There are non-trivial amounts of effort
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
... But pointing to ESCAPE is just weird.
Maybe. The implementation's-eye view of this is that the construct is
data SIMILAR-operator (pattern ESCAPE-operator escape-char)
but I agree that isn't the way a user will think
On Tue, Nov 3, 2009 at 10:46 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Andrew Dunstan and...@dunslane.net writes:
Robert Haas wrote:
Part of the reason I suggest this is because it seems that not much
gets patched back that far any more.
Tom just backpatched something to 7.4 the other day.
A
On Tue, Nov 3, 2009 at 5:23 PM, Robert Haas robertmh...@gmail.com wrote:
Well, that would be overstating my position. We haven't stopped
supporting it, but there's less and less stuff that applies that far
back. I think it's better to draw a line in the sand and say we're
going to stop
Hi,
On Wed, Nov 4, 2009 at 12:01 AM, Andrew Gierth
and...@tao11.riddles.org.uk wrote:
2) you're starting up in a data dir that is a restore of a base backup,
but no recovery.conf has been created
Is the scenario 2 (i.e., a normal crash recovery without recovery.conf)
supported in postgres?
All,
So I'm going to make a case in favor of EOL'ing 7.4. In fact, I'd be in
favor of doing so in, say, February after an announcement this month.
The main reason I'm in favor of this is that we have a lot of users
using 7.4 out of inertia, and they need a message that 7.4 is not
supported to
On Tue, 2009-11-03 at 12:29 -0500, Robert Haas wrote:
You're
not going to take all those little dribs and drabs of responsibility
and transfer them to one person, or even one group of people.
With respect to all the people you just mentioned, I don't see any
reason why other people could not
Many people still run [7.4], so why make them move?
Many people still run 7.3... We made them move..
A nitpick. Nobody made anyone move.
PHP 4 was EOL some time ago but is still in widespread use. We still see
occasional postings regarding 7.3 and sometimes even earlier.
The software
On Tue, 2009-11-03 at 10:04 -0800, Steve Crawford wrote:
Users are, of course, free to use/self-support the software as they see
fit. It's open-source, after all.
I've heard that a lot recently: It's open source, after all.
Is this project not open source any more?
Surely this project
On Tue, Nov 03, 2009 at 10:32:17AM -0800, Josh Berkus wrote:
So I'm going to make a case in favor of EOL'ing 7.4. In fact, I'd be in
favor of doing so in, say, February after an announcement this month.
The main reason I'm in favor of this is that we have a lot of users
using 7.4 out of
Simon,
Why are we not even willing to ask
whether someone is willing? It all seems very strange to me.
Mostly because, I think, nobody can picture how this would be structured
or where the people would come from. Surely a 7.4 maintainer would do
only one platform? Or only source? Can we
On Tue, Nov 3, 2009 at 1:32 PM, Josh Berkus j...@agliodbs.com wrote:
Also, as Greg points out, 7.4 is just waiting for some exploit which is
horribly hard to backpatch for us to desupport it on short notice, and
that is NOT a service to our users.
That is along the line of my concerns as well.
Is a somewhat related question how long are the various commercial
support organizations committed to supporting 7.4?
I guess support companies might support their client's systems
for longer or shorter times than the community patches the old
versions. No doubt it's easier for them if the
On Tue, Nov 3, 2009 at 2:24 PM, Greg Sabino Mullane g...@turnstep.com wrote:
That will get some, but not others. What really makes people upgrade
their database is when their database driver stops working against it. :)
ROFL.
...Robert
--
Sent via pgsql-hackers mailing list
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
The other Greg wrote:
Realistically we're going to EOL it as soon as the first major bug is
found that *doesn't* back patch readily. There's relatively low cost
to
2009/11/3 Tom Lane t...@sss.pgh.pa.us:
Jeff Davis pg...@j-davis.com writes:
I'm not excited about using NOT, because I think it has a hint of a
double-negative when combined with EXCLUSION.
Well, the choice of EXCLUSION isn't set in stone either ...
Is this really a generalized uniqueness
Simon Riggs si...@2ndquadrant.com writes:
On Tue, 2009-11-03 at 12:29 -0500, Robert Haas wrote:
You're
not going to take all those little dribs and drabs of responsibility
and transfer them to one person, or even one group of people.
With respect to all the people you just mentioned, I don't
On Nov 3, 2009, at 10:32 AM, Josh Berkus wrote:
So I'm going to make a case in favor of EOL'ing 7.4. In fact, I'd
be in
favor of doing so in, say, February after an announcement this month
+1
And, frankly, I think that we still need a published deprecation
policy -- or at least a set of
On Tue, Nov 3, 2009 at 7:24 PM, Greg Sabino Mullane g...@turnstep.com wrote:
Realistically we're going to EOL it as soon as the first major bug is
found that *doesn't* back patch readily. There's relatively low cost
to supporting it up until that bug is found, and apparently it hasn't
been
Hi all,
It looks like Postgres has a restriction in DISTINCT ON queries where the
DISTINCT ON expressions must match the left side of the ORDER BY list. The
issue is that if a DISTINCT ON ... has multiple instances of a particular
expression, this check doesn't seem to fire correctly.
For
Hi,
On Tue, Nov 3, 2009 at 3:23 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
wrt. synchronous replication, if someone else has the cycles to look at
it, that would be great. I got stuck on the postmaster-process or not
question Fujii raised again now, not being able to
Josh Berkus wrote:
...The main reason I'm in favor of this is that we have a lot of users
using 7.4 out of inertia, and they need a message that 7.4 is not
supported to get them to upgrade.
I'm not entirely sure that inertia is the culprit. From what I've seen,
since 7.4 is a good, stable
On Tue, 2009-11-03 at 10:49 -0800, Josh Berkus wrote:
Why are we not even willing to ask
whether someone is willing? It all seems very strange to me.
Mostly because, I think, nobody can picture how this would be structured
or where the people would come from. Surely a 7.4 maintainer
On Tue, Nov 3, 2009 at 5:05 PM, Jeff Davis pg...@j-davis.com wrote:
We already have some reasonable agreement around EXCLUSION ... CHECK
WITH. We should stick with the current syntax unless there's a good
consensus around some other specific proposal.
Yeah. I don't like the inflexibility of
On Tue, 2009-11-03 at 21:31 +, Dean Rasheed wrote:
Is this really a generalized uniqueness constraint, extended to
support operators other than = ?
That has been discussed in the past:
http://archives.postgresql.org/message-id/1253119552.24770.203.ca...@jdavis
On Wed, Nov 4, 2009 at 3:17 AM, Emmanuel Cecchet m...@asterdata.com wrote:
For example, this query returns an error (but I guess it shouldn't):
SELECT DISTINCT ON ('1'::varchar, '1'::varchar) a FROM (SELECT 1 AS a) AS a
ORDER BY '1'::varchar, '1'::varchar, '2'::varchar;
This sounds
On Nov 3, 2009, at 10:17 PM, Emmanuel Cecchet m...@asterdata.com
wrote:
Hi all,
It looks like Postgres has a restriction in DISTINCT ON queries
where the DISTINCT ON expressions must match the left side of the
ORDER BY list. The issue is that if a DISTINCT ON ... has multiple
instances
On Tue, 2009-11-03 at 15:01 -0500, Tom Lane wrote:
Simon Riggs si...@2ndquadrant.com writes:
On Tue, 2009-11-03 at 12:29 -0500, Robert Haas wrote:
You're
not going to take all those little dribs and drabs of responsibility
and transfer them to one person, or even one group of people.
On Tue, Nov 3, 2009 at 12:33 AM, Robert Haas robertmh...@gmail.com wrote:
On Mon, Nov 2, 2009 at 10:14 AM, Euler Taveira de Oliveira
eu...@timbira.com wrote:
BTW, are you going to submit another WIP patch for next commitfest?
Well, Heikki was going to keep working on this and Hot Standby
Greg Stark gsst...@mit.edu writes:
On Wed, Nov 4, 2009 at 3:17 AM, Emmanuel Cecchet m...@asterdata.com wrote:
SELECT DISTINCT ON ('1'::varchar, '1'::varchar) a FROM (SELECT 1 AS a) AS a
ORDER BY '1'::varchar, '1'::varchar, '2'::varchar;
This sounds familiar. What version of Postgres are you
Robert Haas wrote:
I'm not averse to EOL'ing 7.4, but I don't think it's fair to claim that
we already stopped supporting it.
Well, that would be overstating my position. We haven't stopped
supporting it, but there's less and less stuff that applies that far
back. I think it's better
On Tue, Nov 3, 2009 at 12:13 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Tue, 2009-11-03 at 16:37 +, Dave Page wrote:
On Tue, Nov 3, 2009 at 4:29 PM, Simon Riggs si...@2ndquadrant.com wrote:
Unless there are unfixable data loss bugs in it, I say we keep it.
Many people still run
Tom Lane t...@sss.pgh.pa.us wrote:
select nosuchfunction(1,2,3,avalidfunction(4));
^
select nosuchfunction(1,2,3,avalidfunction(4));
^
Which of these is less likely to be misread about which function
Is it an expected behavior?
postgres=# CREATE TABLE t1 (a int, b int);
CREATE TABLE
postgres=# CREATE TABLE t2 (b int, c int);
CREATE TABLE
postgres=# CREATE TABLE t3 (d int) inherits (t1, t2);
NOTICE: merging multiple inherited definitions of column b
CREATE TABLE
The t3.d is
70 matches
Mail list logo
