On Wed, Mar 3, 2010 at 1:12 AM, Tom Lane wrote:
> Jaime Casanova writes:
>> On Wed, Mar 3, 2010 at 1:00 AM, Tom Lane wrote:
>>> No, I intentionally didn't back-patch that. The only benefit of the
>>> change is throwing a useful error message for questionable syntax.
>
>> then, maybe a fix in th
Jaime Casanova writes:
> On Wed, Mar 3, 2010 at 1:00 AM, Tom Lane wrote:
>> No, I intentionally didn't back-patch that. Â The only benefit of the
>> change is throwing a useful error message for questionable syntax.
> then, maybe a fix in the docs of back branches?
What's to fix? The documenta
On Wed, Mar 3, 2010 at 1:00 AM, Tom Lane wrote:
> David Fetter writes:
>> On Tue, Mar 02, 2010 at 11:02:54PM -0500, Jaime Casanova wrote:
>>> On Tue, Mar 2, 2010 at 8:53 PM, Tom Lane wrote:
Instead of trying (and failing) to allow <> at the end of a DECLARE
section, throw an error mess
(2010/03/03 14:26), Robert Haas wrote:
> 2010/3/2 KaiGai Kohei:
>> Is it an expected behavior?
>>
>> postgres=> CREATE SEQUENCE s;
>> CREATE SEQUENCE
>> postgres=> ALTER TABLE s RENAME sequence_name TO abcd;
>> ALTER TABLE
>>
>> postgres=> CREATE TABLE t (a int primary key, b text);
>>
David Fetter writes:
> On Tue, Mar 02, 2010 at 11:02:54PM -0500, Jaime Casanova wrote:
>> On Tue, Mar 2, 2010 at 8:53 PM, Tom Lane wrote:
>>> Instead of trying (and failing) to allow <> at the end of a DECLARE
>>> section, throw an error message saying explicitly that the label must go
>>> before
In response to Bruce Momjian :
> Well, I can easily make it do what you expect, and I don't see many
> error returns in that area of the code, so I just wrote a patch that
> does what you would expect rather than throw an error.
Well, that's great and better than an error, thx.
> test=> sel
2010/3/2 KaiGai Kohei :
> Is it an expected behavior?
>
> postgres=> CREATE SEQUENCE s;
> CREATE SEQUENCE
> postgres=> ALTER TABLE s RENAME sequence_name TO abcd;
> ALTER TABLE
>
> postgres=> CREATE TABLE t (a int primary key, b text);
> NOTICE: CREATE TABLE / PRIMARY KEY will create implici
On Tue, Mar 2, 2010 at 6:54 PM, Bruce Momjian wrote:
> Robert Haas wrote:
>> > Adding SQL to indicate whether it should be re-planned or not is completely
>> > unappealing. If I could change the code, today, I'd just turn off or choose
>> > not to use PREPARE/EXECUTE. Today, PREPARE/EXECUTE seems
On Tue, Mar 02, 2010 at 11:02:54PM -0500, Jaime Casanova wrote:
> On Tue, Mar 2, 2010 at 8:53 PM, Tom Lane wrote:
> > Log Message:
> > ---
> > Instead of trying (and failing) to allow <> at the end of a DECLARE
> > section, throw an error message saying explicitly that the label must go
>
Tom Lane wrote:
> I'm beginning to think nobody is going to step up and fix contrib/xml2,
> so I had a look at it myself.
Funny -- I was about to start working on this when the earthquake hit
here ... glad you got it :-)
--
Alvaro Herrerahttp://www.CommandPrompt.c
Scott Bailey wrote:
> Tom Lane wrote:
> > Asher Hoskins writes:
> >> I can't seem to get to_timestamp() or to_date() to work with quarters,
> >
> > The source code says
> >
> > * We ignore Q when converting to date because it is not
> > * normative.
> >
Tom Lane wrote:
Andrew Dunstan writes:
Baiji is now failing, however. Perhaps it is not finding the XSLT lib or
dll?
Curious indeed, because it passed yesterday, *after* I had made all
those changes in contrib/xml2 itself. The only deltas since then are
your MSVC script additions.
On Mar 2, 2010, at 6:00 PM, Andrew Dunstan wrote:
>> Perhaps add a note that some other interface to allow preloaded modules to
>> also be available to plperl may be provided in the future.
>
> No, that's far from a done deal.
Hence the “may.” But either way.
David
--
Sent via pgsql-hacker
Andrew Dunstan writes:
> Baiji is now failing, however. Perhaps it is not finding the XSLT lib or
> dll?
Curious indeed, because it passed yesterday, *after* I had made all
those changes in contrib/xml2 itself. The only deltas since then are
your MSVC script additions. Now presumably, the XSLT
(2010/03/03 11:22), Tom Lane wrote:
> KaiGai Kohei writes:
>> Is it an expected behavior?
>
> There's no particular reason to forbid it, is there?
Perhaps, it is harmless.
It just seemed to me the renameatt() was not implemented correctly
according to the documentation.
--
KaiGai Kohei
--
S
KaiGai Kohei writes:
> Is it an expected behavior?
There's no particular reason to forbid it, is there?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql
Is it an expected behavior?
postgres=> CREATE SEQUENCE s;
CREATE SEQUENCE
postgres=> ALTER TABLE s RENAME sequence_name TO abcd;
ALTER TABLE
postgres=> CREATE TABLE t (a int primary key, b text);
NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index "t_pkey" for
table "t"
David E. Wheeler wrote:
On Mar 2, 2010, at 4:33 PM, Andrew Dunstan wrote:
I propose to add the following note to the docs:
Preloading modules using plperl.on_init does not make them available
for use by plperl. External perl modules can only be used in plperlu.
Perhaps add a no
On Tue, 2010-03-02 at 12:47 -0800, Marc Munro wrote:
> IIUC this is only a problem for WAL from HOT updates and vacuums. If no
> vacuums or HOT updates have been performed, there is no risk of
> returning bad data. So WAL that does not contain HOT updates or vacuums
> could be applied on the sta
"David E. Wheeler" writes:
> PS: Do you have builds of 7.0 laying around? Sheesh!
Use it for testing pg_dump back that far ...
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgr
On Mar 2, 2010, at 5:14 PM, Tom Lane wrote:
> Rather than trying to fix this, I think we should just rip it out and
> allow only the documented syntax. Objections?
+1 If it never worked, seems like a no-brainer.
Best,
David
PS: Do you have builds of 7.0 laying around? Sheesh!
--
Sent via p
There's a novice question here
http://archives.postgresql.org/pgsql-novice/2010-03/msg5.php
that shows up a problem in plpgsql's grammar. The documentation
states that when a block is labeled, the label must precede the
DECLARE keyword if any:
http://developer.postgresql.org/pgdocs/postgres/pl
On Mar 2, 2010, at 4:33 PM, Andrew Dunstan wrote:
> I propose to add the following note to the docs:
>
> Preloading modules using plperl.on_init does not make them available
> for use by plperl. External perl modules can only be used in plperlu.
Perhaps add a note that some other interface t
Peter Eisentraut wrote:
> On m?n, 2010-02-22 at 10:32 -0500, Bruce Momjian wrote:
> > Simon Riggs wrote:
> > > On Mon, 2009-10-19 at 12:56 -0300, Alvaro Herrera wrote:
> > > > Simon Riggs wrote:
> > > > >
> > > > > On Fri, 2009-08-07 at 15:58 -0400, Alvaro Herrera wrote:
> > > > > > Tom Lane wrote
David Fetter wrote:
> On Thu, Feb 25, 2010 at 07:20:58PM -0500, Bruce Momjian wrote:
> >
> > Did we ever get tab completion support for these backslash commands?
>
> Nope :/
>
> Not sure if I'll be able to get to it this week, either.
What is the TODO description then?
--
Bruce Momjian
There appears to be some significant misunderstanding of what can be
done effectively using the various *_init settings for plperl.
In particular, some people have got an expectation that modules loaded
in plperl.on_init will thereby be available for use in trusted plperl.
I propose to add
Tom Lane wrote:
> Bruce Momjian writes:
> > Sure, I can easily do that, but I am not sure how to generate a typedef
> > list for that release, except to use the old typedef collection method
> > for that file. Is that OK?
>
> One of the things I noticed while patching was that the 8.3 typedef li
Andrew Dunstan wrote:
Tom Lane wrote:
BTW, now that I look at red_bat's failure, it seems that the MSVC build
scripts try to run the contrib/xml2 test even when xml2 hasn't been
built for lack of libxml. This doesn't explain mastodon's problem
but maybe a second look is needed at all the co
On 3/2/10 12:47 PM, Marc Munro wrote:
> To take it further still, if vacuum on the master could be prevented
> from touching records that are less than max_standby_delay seconds old,
> it would be safe to apply WAL from the very latest vacuum. I guess HOT
> could be handled similarly though that m
Robert Haas wrote:
> > Adding SQL to indicate whether it should be re-planned or not is completely
> > unappealing. If I could change the code, today, I'd just turn off or choose
> > not to use PREPARE/EXECUTE. Today, PREPARE/EXECUTE seems like it should
> > always be considered slower unless one c
Dimitri Fontaine wrote:
> Craig Ringer writes:
> > 1) People preparing statements to save on parse+plan time; and
> > 2) People preparing statements to get convenenient param placement.
> >
> > I suspect that most of (1) also want (2), but many of (2) don't care much
> > about (1) and are just pre
Greg Smith wrote:
> Bruce Momjian wrote:
> >> Right now you can't choose "master bloat", but you can choose the other
> >> two. I think that is acceptable for 9.0, assuming the other two don't
> >> have the problems that Tom foresees.
> >>
> >
> > I was wrong. You can choose "master bloat" w
Greg Stark wrote:
> On Mon, Mar 1, 2010 at 5:50 PM, Josh Berkus wrote:
> > I don't think that defer_cleanup_age is a long-term solution. ?But we
> > need *a* solution which does not involve delaying 9.0.
>
> So I think the primary solution currently is to raise max_standby_age.
>
> However there
Dickson S. Guedes wrote:
2010/2/27 Tom Lane :
Buildfarm member caracara has been failing the last few days because of
this:
LOG: could not bind socket for statistics collector: Cannot assign requested
address
LOG: disabling statistics collector for lack of working socket
That code hasn't
Greg Stark wrote:
> On Mon, Mar 1, 2010 at 5:50 PM, Josh Berkus wrote:
> > I don't think that defer_cleanup_age is a long-term solution. ?But we
> > need *a* solution which does not involve delaying 9.0.
>
> So I think the primary solution currently is to raise max_standby_age.
>
> However there
On Mon, 2010-03-01 at 16:12 -0400, pgsql-hackers-ow...@postgresql.org
wrote:
> . . .
> However there is a concern with max_standby_age. If you set it to,
> say, 300s. Then run a 300s query on the slave which causes the slave
> to fall 299s behind. Now you start a new query on the slave -- it gets
On Sun, 2010-02-28 at 16:56 +0100, Joachim Wieland wrote:
> Now let's take a look at both scenarios from the administrators' point
> of view:
Well argued, agree with all of your points.
--
Simon Riggs www.2ndQuadrant.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgr
On Mon, 2010-03-01 at 14:43 -0500, Tom Lane wrote:
> Speaking of which, does the current HS+SR code have a
> provision to force the standby to stop tracking WAL and come up live,
> even when there's more WAL available?
Yes, trigger file.
--
Simon Riggs www.2ndQuadrant.com
--
Sent v
On Mon, 2010-03-01 at 12:04 -0800, Josh Berkus wrote:
> does anyone dispute his analysis? Simon?
No dispute. I think I've discussed this before.
--
Simon Riggs www.2ndQuadrant.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscr
Bruce Momjian wrote:
Right now you can't choose "master bloat", but you can choose the other
two. I think that is acceptable for 9.0, assuming the other two don't
have the problems that Tom foresees.
I was wrong. You can choose "master bloat" with
vacuum_defer_cleanup_age, but only crude
On 3/2/10 10:30 AM, Bruce Momjian wrote:
> Right now you can't choose "master bloat", but you can choose the other
> two. I think that is acceptable for 9.0, assuming the other two don't
> have the problems that Tom foresees.
Actually, if vacuum_defer_cleanup_age can be used, "master bloat" is an
Bruce Momjian wrote:
> > 'max_standby_delay = -1' is really only a reasonable idea if you are
> > absolutely certain all queries are going to be short, which we can't
> > dismiss as an unfounded use case so it has value. I would expect you
> > have to also combine it with a matching reasonable
Greg Smith wrote:
> > I assumed they would set max_standby_delay = -1 and be happy.
> >
>
> The admin in this situation might be happy until the first time the
> primary fails and a failover is forced, at which point there is an
> unbounded amount of recovery data to apply that was stuck wait
Hiroshi Inoue wrote:
> I need someone with WIN32 experience to review and test this patch.
> >>> I don't understand why cache_locale_time() works on Windows. It sets
> >>> the LC_CTYPE but does not do any encoding coversion.
> >> Doesn't strftime_win32 do the conversion?
> >
> > Oh, I now se
Tom Lane wrote:
BTW, now that I look at red_bat's failure, it seems that the MSVC build
scripts try to run the contrib/xml2 test even when xml2 hasn't been
built for lack of libxml. This doesn't explain mastodon's problem
but maybe a second look is needed at all the conditionals around that.
BTW, now that I look at red_bat's failure, it seems that the MSVC build
scripts try to run the contrib/xml2 test even when xml2 hasn't been
built for lack of libxml. This doesn't explain mastodon's problem
but maybe a second look is needed at all the conditionals around that.
Andrew Dunstan writes:
> Tom Lane wrote:
>> Also, mastodon is still failing the xml2 test, not sure why. Looks to
>> be a build problem, but why is (for instance) baiji unaffected?
> Baiji built before I put in the patch, so it didn't have USE_LIBXSLT
> enabled.
But mastodon is failing entirel
Tom Lane wrote:
Andrew Dunstan writes:
Tom Lane wrote:
BTW, it looks like the MSVC build scripts don't bother to make sure that
USE_LIBXSLT is defined (or not) correctly --- at least I can't see any
reference to that symbol in the Windows-specific files. This is now
necessary to avo
Andrew Dunstan writes:
> Tom Lane wrote:
>> BTW, it looks like the MSVC build scripts don't bother to make sure that
>> USE_LIBXSLT is defined (or not) correctly --- at least I can't see any
>> reference to that symbol in the Windows-specific files. This is now
>> necessary to avoid disabling the
Bruce Momjian wrote:
Hiroshi Inoue wrote:
Bruce Momjian wrote:
Bruce Momjian wrote:
Hiroshi Inoue wrote:
Bruce Momjian wrote:
Hiroshi Inoue wrote:
Bruce Momjian wrote:
Where are we on this issue?
Oops I forgot it completely.
I have a little improved version and would post it tonight.
Ah,
On Mar 1, 2010, at 4:35 PM, Tom Lane wrote:
> Theo Schlossnagle writes:
>> I'm writing some extension and I have a hot code path that has a lot of
>> double (C type) data and needs to output NUMERIC tuple data. The current
>> methods I can find in the code to convert sprintf the double to a b
On Tue, Mar 2, 2010 at 8:54 PM, Heikki Linnakangas
wrote:
> This still suffers from ambiguity around a shutdown checkpoint that
> changes the TLI. On the page the shutdown checkpoint is on, what is the
> TLI in the page header? The TLI before the checkpoint record, I presume.
> Now consider a reco
Oleg Bartunov wrote:
just to inform, that building of postgres-A4.tex-pdf (8.4) crushed on my
Ubuntu 9.10 machine. No problem with CVS HEAD.
Alvaro and I are both having the opposite problem on Ubuntu 9.04: 8.4
works fine, but CVS HEAD dumps core:
http://archives.postgresql.org/message-id/2
On Mon, Mar 1, 2010 at 11:11 PM, Chris Browne wrote:
> Nobody really notices the carnage on the highways, because,
> stochastically, there are such a large number of events, both positive
> and negative (e.g. - millions of people making it home safely, and a
> tiny number that don't) that it's dif
Simon Riggs wrote:
On Tue, 2010-03-02 at 13:13 +, Greg Stark wrote:
Why do we disallow turning off archive_mode anyways?
Because it is needed for safety and nobody has got around to coding the
idea of turning it on/off during normal running, which is possible, with
appropriate care
On Tue, 2010-03-02 at 13:13 +, Greg Stark wrote:
> On Tue, Mar 2, 2010 at 9:48 AM, Simon Riggs wrote:
> >> > Setting archive_mode to a command that does nothing but return true,
> >> > e.g. /bin/true,
> >>
> >> "return true" seems ambiguous for me. How about writing clearly
> >> "return a zer
On Tue, Mar 2, 2010 at 9:48 AM, Simon Riggs wrote:
>> > Setting archive_mode to a command that does nothing but return true, e.g.
>> > /bin/true,
>>
>> "return true" seems ambiguous for me. How about writing clearly
>> "return a zero exit status" instead?
>
> Docs are already quite clear on that
Hi there,
just to inform, that building of postgres-A4.tex-pdf (8.4) crushed on my
Ubuntu 9.10 machine. No problem with CVS HEAD.
openjade -D . -c /usr/share/sgml/docbook/stylesheet/dsssl/modular/catalog -d
./stylesheet.dsl -t tex -V tex-backend -i output-print -V texpdf-output -V
'%paper-typ
Tom Lane wrote:
BTW, it looks like the MSVC build scripts don't bother to make sure that
USE_LIBXSLT is defined (or not) correctly --- at least I can't see any
reference to that symbol in the Windows-specific files. This is now
necessary to avoid disabling the xslt functionality in contrib/xml
Thanks for the clarification!
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Fujii Masao wrote:
> On Fri, Feb 26, 2010 at 6:26 AM, Erik Rijkers wrote:
>> With this patch the standby compiles, tests, installs OK.
>> I wanted to check with you if the following is expected.
>
> Thanks for the test and bug report!
>
>> With standby (correctly) as follows :
>> LOG: redo star
scrawf...@pinpointresearch.com (Steve Crawford) writes:
> Marc G. Fournier wrote:
>>
>> Is there a higher then normal amount of earthquakes happening
>> recently? haiti, japan just had one for 6.9, there was apparently
>> one in illinos a few weeks back, one on the Russia/China/N.Korean
>> border a
tmp wrote:
> Consider a table and a query referring to only a subset of the columns
> in that table. How early in the query evaluation is the projection
> carried out?
>
> Are the columns to be selected filtered out as early as in the very
> access method that reads the table rows from the buffer,
Consider a table and a query referring to only a subset of the columns
in that table. How early in the query evaluation is the projection
carried out?
Are the columns to be selected filtered out as early as in the very
access method that reads the table rows from the buffer, or are the
projec
On Sun, 28 Feb 2010 23:02:39 -0500
Robert Haas wrote:
> On Sun, Feb 28, 2010 at 8:43 AM, Ivan Sergio Borgonovo
> wrote:
> > I've no idea what to do next other than asking if someone can
> > give a look to the code and check my comprehension of what a
> > tsquery should be in memory.
> Have you
On mån, 2010-03-01 at 16:29 -0500, Tom Lane wrote:
> Peter Eisentraut writes:
> > SQL standard:
>
> > ::=
> > NO SQL
> > | CONTAINS SQL
> > | READS SQL DATA
> > | MODIFIES SQL DATA
>
> Huh. I understand three of those, but what is the use of CONTAINS SQL?
My reading is that CONTAINS SQL allow
On mån, 2010-03-01 at 15:30 -0500, Jaime Casanova wrote:
> so IMMUTABLE = DETERMINISTIC NO SQL,
> STABLE = DETERMINISTIC READS SQL DATA
> VOLATILE = NOT DETERMINISTIC MODIFIES SQL DATA
It might be tempting to create such a mapping, but there could be a
number of pitfalls, especially if you define
On Tue, 2010-03-02 at 15:20 +0900, Fujii Masao wrote:
> On Fri, Feb 26, 2010 at 2:47 AM, Bruce Momjian wrote:
> > Postgres 9.0 will be the first release to mention /bin/true as a way of
> > turning off archiving in extraordinary circumstances:
> >
> >
> > http://developer.postgresql.org/pg
Albe Laurenz wrote:
> As demonstrated here:
> http://archives.postgresql.org/pgsql-general/2010-02/msg01057.php
>
> it can happen that you end up with a corrupt database
> if you use PITR to recover past a hardware failure.
>
> It seems that unique constraints are not verified during
> WAL replay
We should probably also check and prohibit including directories as files.
On Tuesday, March 2, 2010, Tom Lane wrote:
> In the meantime, it seems like we ought to take two defensive steps:
--
greg
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
>
>
> I think you have to take up a simpler project as a first project. This
> is a major overhaul of transaction information and it depends on
> understanding how a lot of different areas work -- all of which are
> very complex tricky areas to understand.
>
>
>
Greg,
I just feel the fast
As demonstrated here:
http://archives.postgresql.org/pgsql-general/2010-02/msg01057.php
it can happen that you end up with a corrupt database
if you use PITR to recover past a hardware failure.
It seems that unique constraints are not verified during
WAL replay.
Is that intentional or an oversig
On Tue, 2 Mar 2010 15:20:36 +0900, Fujii Masao
wrote:
>> Setting archive_mode to a command that does nothing but return true,
>> e.g. /bin/true,
>
> "return true" seems ambiguous for me. How about writing clearly
> "return a zero exit status" instead?
For the record. I hate the fact that I ever
73 matches
Mail list logo
