Hi,
> >
> >> The following plpgsql function errors out with cvs head:
> >>
> >> CREATE function test_assign() returns void
> >> AS
> >> $$ declare x int;
> >> BEGIN
> >> x := 9E3/2;
> >> END
> >> $$ LANGUAGE 'plpgsql';
> >>
> >> postgres=# select test_assign();
> >> ERROR: invalid input syntax fo
> I think that setting aside a minimum percentage of work_mem may be a
> reasonable approach. For instance, setting aside 1% at even 1 MB
> work_mem would be 10 KB which is enough to store about 40 MCV tuples of
> the TPC-H database. Such a small percentage would be very unlikely (but
> still pos
On Mon, Dec 29, 2008 at 9:28 PM, Gregory Stark wrote:
> "Kevin Grittner" writes:
>> (3) A finer-grained approach would be to make no-effect updates to
>> rows to lock them if they are to be read for purposes of updating
>> something else in the transaction. This could have a high cost in
>> dis
"Kevin Grittner" writes:
> (3) A finer-grained approach would be to make no-effect updates to
> rows to lock them if they are to be read for purposes of updating
> something else in the transaction. This could have a high cost in
> disk access and table bloat. It has the advantage of providing
Magnus Hagander wrote:
Alex Hunsaker wrote:
On Sat, Dec 27, 2008 at 11:50, Andrew Chernow wrote:
Why does pqGetHomeDirectory have to succeed to use conn->sslrootcert. Maybe
this should be an OR of the two since sslrootcert is not dependent on
homedir?
around line 970 src/interfaces/libpq/fe-s
I'm still casting about to make sure I have my head around the issues
adequately to suggest a documentation update. Here's my current
understanding.
The below is intended to help define the nature and scope of the
issue, not be the sort of text that belongs in user documentation.
Assume transa
Attached is the latest parallel restore patch. I think this is getting
fairly close.
Includes help text, docco and some extra error checking.
cheers
andrew
parallel_restore_13.patch.gz
Description: GNU Zip compressed data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.o
Tom Lane Wrote:
> Actually, it's not ambiguous according to our interpretation of ORDER BY
> clauses: the first attempt is to match an output column name, so it's
> seizing on the first SELECT column (b.parentpart) as being the intended
> sort key for "parentpart", and similarly for "childpart".
Alex Hunsaker wrote:
> On Sat, Dec 27, 2008 at 11:50, Andrew Chernow wrote:
>> Why does pqGetHomeDirectory have to succeed to use conn->sslrootcert. Maybe
>> this should be an OR of the two since sslrootcert is not dependent on
>> homedir?
>>
>> around line 970 src/interfaces/libpq/fe-secure.c
>>
"David Rowley" writes:
> Also while testing I noticed that this query didn't error out when it should
> have: (Of course I only noticed because Sybase did)
> WITH RECURSIVE bom(parentpart,childpart,quantity,rn) AS (
> SELECT parentpart,childpart,quantity,ROW_NUMBER() OVER (ORDER BY
> parentpart
Gregory Stark wrote:
> Bruce Momjian writes:
>
>> Jonah H. Harris wrote:
>>> On Mon, Dec 29, 2008 at 11:47 AM, Tom Lane wrote:
But of course those are just as straightforward in autoconf. It's
the not-straightforward stuff that's going to be a PITA to translate.
>>> As much as I disli
Gregory Stark wrote:
We could use autoconf on win32 using cygwin utilities for things like sh and
awk. Just because we use those tools doesn't mean we have to use a cygwin
compiler or linker to actually do the build.
Making Cygwin a build time requirement for using MSVC is something we
s
Bruce Momjian writes:
> Jonah H. Harris wrote:
>> On Mon, Dec 29, 2008 at 11:47 AM, Tom Lane wrote:
>> > But of course those are just as straightforward in autoconf. It's
>> > the not-straightforward stuff that's going to be a PITA to translate.
>>
>> As much as I dislike autotools, I really d
On Thu, Dec 25, 2008 at 23:04, ITAGAKI Takahiro
wrote:
> Here is an updated version of contrib/pg_stat_statements patch.
Im going to do some more testing, give the typedef Chunk stuff another
look (you did fix the race/not protected by a spinlock you found
earlier right?) . And if all looks goo
Tom Lane Wrote:
> Well, this certainly demonstrates that the check I added to
> parseCheckAggregates is wrongly placed, but I'm not sure we really
> need to forbid the case. David's example query seems to give sane
> answers once the bug in begin_partition is fixed:
>
> parentpart | childpart |
On Sat, Dec 27, 2008 at 11:50, Andrew Chernow wrote:
> Why does pqGetHomeDirectory have to succeed to use conn->sslrootcert. Maybe
> this should be an OR of the two since sslrootcert is not dependent on
> homedir?
>
> around line 970 src/interfaces/libpq/fe-secure.c
>
> if (conn->sslrootcert || pq
Jonah H. Harris escribió:
> On Mon, Dec 29, 2008 at 11:47 AM, Tom Lane wrote:
> > But of course those are just as straightforward in autoconf. It's
> > the not-straightforward stuff that's going to be a PITA to translate.
>
> As much as I dislike autotools, I really despise CMake; it's a nasty
>
Jonah H. Harris wrote:
> On Mon, Dec 29, 2008 at 11:47 AM, Tom Lane wrote:
> > But of course those are just as straightforward in autoconf. It's
> > the not-straightforward stuff that's going to be a PITA to translate.
>
> As much as I dislike autotools, I really despise CMake; it's a nasty
> pi
On Mon, Dec 29, 2008 at 11:47 AM, Tom Lane wrote:
> But of course those are just as straightforward in autoconf. It's
> the not-straightforward stuff that's going to be a PITA to translate.
As much as I dislike autotools, I really despise CMake; it's a nasty
piece of work and I hope we don't swi
Dawid Kuroczko wrote:
> Hi!
>
> I think I've got a nice TODO item for psql client:
>
> When a client connects to a database which has unknown (newer)
> version it might be advisable to 'fallback' some commands to use
> INFORMATION_SCHEMA instead of system catalogs.
>
>
> For instance when conne
> On Sun, Dec 28, 2008 at 9:29 AM, Bernd Helmle wrote:
>
> i would say check for negative attnums and deny that view to be
> updateable because of SQL92 says in 11.19 syntax
> rule 6:
> """
> 6) If the is updatable, then the viewed table
> is
> an updatable table. Otherwise
On Mon, 2008-12-29 at 12:35 -0500, Tom Lane wrote:
> we could lock the rows. However, consider something like this:
>
> select x, lead(x) over() from table for update limit 1;
>
> Because of the LIMIT, we'd only lock the first-returned row ...
> but the values returned would also depend on
Tom Lane escribió:
> The core window-functions patch is now committed and ready for wider
> testing. However, there are a number of unfinished items, at least
> some of which I'd like to see addressed before 8.4 release. In rough
> order of importance:
[lots of discussion]
Perhaps I was a bit h
Fujii Masao wrote:
On Mon, Dec 29, 2008 at 6:08 PM, Heikki Linnakangas
wrote:
Fujii Masao wrote:
Attached is the self-contained patch to skip checkpoint at
pg_start_backup.
This is a part of Synch Rep patches, and was discussed in the following
thread.
http://archives.postgresql.org/message-i
"Hitoshi Harada" writes:
> 2008/12/30 Tom Lane :
>> Is this something you're interested in working on? I can tackle it
>> if you don't have time now.
> Sorry, over the new year days, I don't have time and will be remote.
> Maybe from 3th or 4th I can work on this, so if you have time during
> ti
2008/12/30 Tom Lane :
> Hah, I had missed that fine point. Okay, doc is wrong and I will fix.
>
> Given that, I think that a suitable minimum implementation should cover
> both the RANGE/ROWS distinction and the CURRENT ROW/UNBOUNDED FOLLOWING
> distinction, ie I would like 8.4 to support
>
>
"Hitoshi Harada" writes:
> 2008/12/30 Tom Lane :
>> What is the difference? AFAICS the RANGE and ROWS keywords ought to be
>> equivalent if you are not specifying "expression PRECEDING" or
>> "expression FOLLOWING".
> The difference is that RANGE ... CURRENT ROW contains all peers of the
> curre
2008/12/30 Tom Lane :
> Andrew Dunstan writes:
>> Tom Lane wrote:
>>> However, if we do that then for consistency we'd have to invent
>>> DROP WINDOW FUNCTION, ALTER WINDOW FUNCTION, RENAME WINDOW FUNCTION,
>>> COMMENT ON WINDOW FUNCTION, yadda yadda, and insist that you refer
>>> to a function pr
"Jaime Casanova" writes:
> i don't understand this window function stuff well yet, but AFAIU it
> is like an aggregate function that shows grouped values without
> grouping rows (ok, maybe a very laizy or novice definition) but if
> that is correct or near correct maybe we need to follow the same
2008/12/30 Jaime Casanova :
> On Mon, Dec 29, 2008 at 11:59 AM, Tom Lane wrote:
>> I wrote:
>>> * Support creation of user-defined window functions. I think this is
>>> a "must have" for 8.4 --- we are not in the habit of building
>>> nonextensible basic features. It doesn't seem that hard eithe
Andrew Dunstan writes:
> Tom Lane wrote:
>> However, if we do that then for consistency we'd have to invent
>> DROP WINDOW FUNCTION, ALTER WINDOW FUNCTION, RENAME WINDOW FUNCTION,
>> COMMENT ON WINDOW FUNCTION, yadda yadda, and insist that you refer
>> to a function properly (with or without WINDO
2008/12/30 Tom Lane :
> "Hitoshi Harada" writes:
>> And surveying sgml docs, I found this is not correct.
>
>> http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/doc/src/sgml/ref/select.sgml?r1=1.112&r2=1.113
>
>> + default framing behavior, which is equivalent to the framing clause
>> + ROWS
On Mon, Dec 29, 2008 at 11:39:16AM -0500, Tom Lane wrote:
> I just tried that and it seems you'd need to make another couple of
> changes --- the "fetch" test fails for instance, probably because
> something somewhere isn't recognizing a fetch command.
Actually this was a test that expected the bl
Hi,
On Mon, Dec 29, 2008 at 6:08 PM, Heikki Linnakangas
wrote:
> Fujii Masao wrote:
>>
>> Attached is the self-contained patch to skip checkpoint at
>> pg_start_backup.
>> This is a part of Synch Rep patches, and was discussed in the following
>> thread.
>>
>> http://archives.postgresql.org/messa
I wrote:
> * Investigate whether we should prohibit window functions in recursive
> terms; check whether any of the committed prohibitions are unnecessary.
I looked into these questions a bit. As for the first, there doesn't
appear to be a compelling implementation reason to forbid it, and I
can'
On Mon, Dec 29, 2008 at 11:59 AM, Tom Lane wrote:
> I wrote:
>> * Support creation of user-defined window functions. I think this is
>> a "must have" for 8.4 --- we are not in the habit of building
>> nonextensible basic features. It doesn't seem that hard either.
>> I think all we need do is to
On Mon, Dec 29, 2008 at 11:19:56AM -0500, Tom Lane wrote:
> Kurt Roeckx writes:
> > On Mon, Dec 29, 2008 at 09:25:47AM -0300, Alvaro Herrera wrote:
> >> I think a simplistic solution is to declare the variable volatile.
> >> Would you test that and report back?
>
> > Yes, making oldcontext volati
Sorry for top posting -- damn phone.
The standard defines all the *other* transaction isolations in terms
of phantom reads, dirty reads, and, uh one other phenomenon. But it
defines serializability literally, as the transactions having the same
effect as ift they were run serially. It expli
Tom Lane wrote:
However, if we do that then for consistency we'd have to invent
DROP WINDOW FUNCTION, ALTER WINDOW FUNCTION, RENAME WINDOW FUNCTION,
COMMENT ON WINDOW FUNCTION, yadda yadda, and insist that you refer
to a function properly (with or without WINDOW) in each one of these
commands.
2008/12/29 Tom Lane :
> I wrote:
>> * Support creation of user-defined window functions. I think this is
>> a "must have" for 8.4 --- we are not in the habit of building
>> nonextensible basic features. It doesn't seem that hard either.
>> I think all we need do is to allow "WINDOW" as an attribu
2008/12/29 Nikhil Sontakke :
> Hi,
>
> wrote:
>>
>> The following plpgsql function errors out with cvs head:
>>
>> CREATE function test_assign() returns void
>> AS
>> $$ declare x int;
>> BEGIN
>> x := 9E3/2;
>> END
>> $$ LANGUAGE 'plpgsql';
>>
>> postgres=# select test_assign();
>> ERROR: invali
I wrote:
> * Support creation of user-defined window functions. I think this is
> a "must have" for 8.4 --- we are not in the habit of building
> nonextensible basic features. It doesn't seem that hard either.
> I think all we need do is to allow "WINDOW" as an attribute keyword
> in CREATE FUNCT
"Dave Page" writes:
> On Mon, Dec 29, 2008 at 12:49 PM, Magnus Hagander wrote:
>> ... The point being that I think creating the
>> replacement parts for autoconf are a lot harder than creating them for
>> the make parts of the system.
> I did - in the wxWidgets case, the existing module had some
"Hitoshi Harada" writes:
> 2008/12/29 Tom Lane :
>> * Support creation of user-defined window functions. I think this is
>> a "must have" for 8.4 --- we are not in the habit of building
>> nonextensible basic features. It doesn't seem that hard either.
> The reason I and people decided window f
Michael Meskes writes:
> On Sun, Dec 28, 2008 at 03:21:16PM -0500, Tom Lane wrote:
>> It strikes me that it might be a good idea to change cat2_str to not
>> insert a space when obviously not necessary, perhaps along the lines
>> of
> Hey, good idea, will add this too.
I just tried that and it s
[Sorry, have essantially be offline since yesterday. My server didn't ocme up
again. Sight. ]
On Sun, Dec 28, 2008 at 03:21:16PM -0500, Tom Lane wrote:
> It hadn't occurred to me to try the ecpg tests before committing the
> window functions patch :-(. It looks like those grammar additions have
On Mon, Dec 29, 2008 at 12:49 PM, Magnus Hagander wrote:
> I did a similar thing for pgAdmin, and I found it pretty easy to do.
> However, I think Dave spent some time on doing the "plugins" for
> detecting wxWidgets and such. The point being that I think creating the
> replacement parts for autoc
Kurt Roeckx writes:
> On Mon, Dec 29, 2008 at 09:25:47AM -0300, Alvaro Herrera wrote:
>> I think a simplistic solution is to declare the variable volatile.
>> Would you test that and report back?
> Yes, making oldcontext volatile makes the test pass.
This is a gcc bug and you should report it.
Sorry, I found a unnecessary hook is not removed at ExecCallTriggerFunc().
Please see the revision r1370, instead.
[1/5]
http://sepgsql.googlecode.com/files/sepostgresql-sepgsql-8.4devel-3-r1370.patch
[2/5]
http://sepgsql.googlecode.com/files/sepostgresql-utils-8.4devel-3-r1370.patch
[3/5]
htt
*PLEASE* I'll cry again, loudly...
If somebody's doing this type of operation on the CVS replo, please warn
is (I'll consider this warning) *AND STOP RSYNC/ANONCVS ACCESS* around
the operation
*PLEASE PLEASE PLEASE*
Note that this change doesn't even "fix" the broken CVS history tags;
the R
>>> Peter Eisentraut wrote:
> Serializability is not defined in terms of what is visible, but what
the
> state of the database is.
A belated thought on this: It would be easy enough to add a
daily_receipt_total table to the example to capture the result of the
query, instead of assuming that it
>>> Peter Eisentraut wrote:
> On Tuesday 23 December 2008 16:51:03 Kevin Grittner wrote:
>> If you look at the serializable queries in the original post for
this
>> thread, it's not hard to see that this standard is not met. The
>> insert of receipt 3 appears to happen before the update of the
Hi,
wrote:
> The following plpgsql function errors out with cvs head:
>
> CREATE function test_assign() returns void
> AS
> $$ declare x int;
> BEGIN
> x := 9E3/2;
> END
> $$ LANGUAGE 'plpgsql';
>
> postgres=# select test_assign();
> ERROR: invalid input syntax for integer: "4500.00
I had originally sent this mail in April, but it appears to have been blocked
because the attachment was too large.
While we are in the process of dealing with CVS-Git conversion, we should also
apply this fixup to make the CVS repository more sane.
Could someone with write access to the reposi
Section 7.2.4 of the docs, third paragraph, currently reads:
> Currently, use of window functions always forces sorting, and so the query
> output will be ordered according to one or another of the window functions'
> PARTITION BY/ORDER
> BY clauses. It is not recommendable to rely on this, howe
On Mon, Dec 29, 2008 at 09:25:47AM -0300, Alvaro Herrera wrote:
>
> I think a simplistic solution is to declare the variable volatile.
> Would you test that and report back?
Yes, making oldcontext volatile makes the test pass.
It now fails at the ECPG-Check stage, but it seems that is a common
p
Hi!
I think I've got a nice TODO item for psql client:
When a client connects to a database which has unknown (newer)
version it might be advisable to 'fallback' some commands to use
INFORMATION_SCHEMA instead of system catalogs.
For instance when connected to 8.4dev server using 8.3 client,
af
On Wednesday 17 December 2008 17:17:26 Martin Pihlak wrote:
> It'd make more sense if we changed the name to pg_get_datasource ;)
>
> We could make the pg_get_remote_connection_info Postgres specific -- in
> this case it would be changed to return just the connect string text. NULL
> for the other
I updated patch set of SE-PostgreSQL and related stuff (r1368)
[1/5]
http://sepgsql.googlecode.com/files/sepostgresql-sepgsql-8.4devel-3-r1368.patch
[2/5]
http://sepgsql.googlecode.com/files/sepostgresql-utils-8.4devel-3-r1368.patch
[3/5]
http://sepgsql.googlecode.com/files/sepostgresql-policy-
Peter Eisentraut wrote:
> On Sunday 21 December 2008 00:59:27 Alvaro Herrera wrote:
>> Andrew Dunstan wrote:
>>> We (i.e. probably Magnus and I in the first instance) should think about
>>> creating a bit of a cookbook if we're going to persist with this build
>>> system.
>> Well, we were going to
On Saturday 20 December 2008 19:33:17 Tom Lane wrote:
> Peter wrote:
> > SQL/MED catalog manipulation facilities
> >
> > This doesn't do any remote or external things yet, but it gives modules
> > like plproxy and dblink a standardized and future-proof system for
> > managing their connection infor
Kurt Roeckx wrote:
> #3 0x006c8033 in MemoryContextAlloc (context=0x0, size=112)
> at mcxt.c:507
> #4 0x006abe82 in CopyErrorData () at elog.c:1082
> #5 0x2b41ea61a755 in PLy_spi_execute_plan (ob=,
> list=, limit=) at
> plpython.c:2587
It's calling CopyErrorData wi
On Tuesday 23 December 2008 16:51:03 Kevin Grittner wrote:
> If you look at the serializable queries in the original post for this
> thread, it's not hard to see that this standard is not met. The
> insert of receipt 3 appears to happen before the update of the control
> record, since it has the o
On Sunday 21 December 2008 00:59:27 Alvaro Herrera wrote:
> Andrew Dunstan wrote:
> > We (i.e. probably Magnus and I in the first instance) should think about
> > creating a bit of a cookbook if we're going to persist with this build
> > system.
>
> Well, we were going to try CMake, but we need som
Simon Riggs wrote:
On Tue, 2008-12-23 at 18:23 +0200, Heikki Linnakangas wrote:
(later) OldestXmin
When a hot standby server is running read-only queries,
indicates the
current OldestXmin on the standby. The primary can refrain from
vacuuming tuples still required by the slave using t
marcin mank wrote:
Perhaps we should listen to the people that have said they don't want
queries cancelled, even if the alternative is inconsistent answers.
I don't like that much. PostgreSQL has traditionally avoided that very
hard. It's hard to tell what kind of inconsistencies you'd get, as
On Mon, 2008-12-29 at 15:06 +0900, Fujii Masao wrote:
> This seems to have not been fixed yet in the latest patch.
>
> http://archives.postgresql.org/message-id/494ff631.90...@enterprisedb.com
> recovery-infra-separated-again-1.patch
I'll add it to my issues-reported list so we can check for re
On Sun, 28 Dec 2008 18:19:48 -0500 Tom Lane wrote:
> "Andreas 'ads' Scherbaum" writes:
> > the march 2008 commitfest added a patch[1] with extended information for
> > \l+. The may 2008 commitfest added a patch[2] which reformats the
> > permission output in \z. I like the new output in \z, but t
Fujii Masao wrote:
Attached is the self-contained patch to skip checkpoint at pg_start_backup.
This is a part of Synch Rep patches, and was discussed in the following
thread.
http://archives.postgresql.org/message-id/3f0b79eb0812240710j7e613f3atfd6b6fc274035...@mail.gmail.com
I'm not convinced
69 matches
Mail list logo
