Fujii Masao wrote:
> In current SR, since a backup history file is not replicated,
> the standby always starts an archive recovery without a backup
> history file, and a wrong minRecoveryPoint might be used. This
> is not a problem for SR itself, but would cause trouble when
> SR cooperates with Ho
On Thu, Nov 26, 2009 at 11:15:46AM +0900, Itagaki Takahiro wrote:
> No interaction with existing features
> * SE-PgSQL injects security-context-based access control, but there are
> no interaction between it and the existing role-based access control.
And there shouldn't be, I think. S
On ons, 2009-11-25 at 22:15 +0100, Magnus Hagander wrote:
> On Wed, Nov 25, 2009 at 22:07, Peter Eisentraut wrote:
> > On ons, 2009-11-25 at 16:27 +0100, Magnus Hagander wrote:
> >> Attached is a patch which adds a chapter to git in our documentation,
> >> around where we have several chapters abo
On Thu, 2009-11-26 at 00:35 -0500, Andrew Dunstan wrote:
> On Wed, November 25, 2009 3:56 pm, Jeff Davis wrote:
> >
> > I worry that we're getting further away from the original problem. Let's
> > allow functions to get the bytes of data from a COPY, like the original
> > proposal. I am not sure CO
David Christensen wrote:
> 1) is there a hard limit of the number of times the archive_command will
> attempt? I didn't see anything documented about this in the PITR or
> config docs, so I'm guessing the 10 failures I saw in the log were just
> coincidental.
There's no limit. It will try forever
On Thu, 2009-11-26 at 05:01 +0100, Pavel Stehule wrote:
> It working like:
>
> 1. EXECUTE SELECT 0 FROM generate_series(1,...);
> 2. STORE RESULT TO TABLE zero;
> 3. EXECUTE SELECT 1/i FROM zero;
> 4. STORE RESULT TO TABLE tmp;
>
> Problem is in seq execution. Result is stored to destination afte
On Wed, 2009-11-25 at 15:59 -0800, Jeff Davis wrote:
> > My operator-class-fu is insufficient to render judgment on this point.
> > I think the thing to do is look at a bunch of non-built-in opclasses
> > and check for POLA violations.
>
> Ok, I'll consider this more.
In cases where the operator
Hi,
In current SR, since a backup history file is not replicated,
the standby always starts an archive recovery without a backup
history file, and a wrong minRecoveryPoint might be used. This
is not a problem for SR itself, but would cause trouble when
SR cooperates with Hot Standby.
HS begins ac
On Wed, 25 Nov 2009, Tom Lane wrote:
Oleg Bartunov writes:
I tried to force query to use index by specifying high execution cost, but
without success, even seqscan cost doesn't changed. This is 8.4.1
I think you altered the wrong function. The function underlying
point <@ box is on_pb() not
Simon Riggs wrote:
> Recent change:
>
> An idle-in-transaction transaction can also hold a temporary file. Think
> of an open cursor, for example. Therefore, remove the distinction
> between CONFLICT_MODE_ERROR and CONFLICT_MODE_ERROR_IF_NOT_IDLE,
> idle-in-transaction backends need to be killed t
On Wed, Nov 25, 2009 at 9:35 PM, Andrew Dunstan wrote:
> On Wed, November 25, 2009 3:56 pm, Jeff Davis wrote:
>>
>> I worry that we're getting further away from the original problem. Let's
>> allow functions to get the bytes of data from a COPY, like the original
>> proposal. I am not sure COPY is
On Wed, November 25, 2009 3:56 pm, Jeff Davis wrote:
>
> I worry that we're getting further away from the original problem. Let's
> allow functions to get the bytes of data from a COPY, like the original
> proposal. I am not sure COPY is the best mechanism to move records
> around when INSERT ... S
Florian G. Pflug wrote:
I do, however, suspect that ALTER TABLE is plagued by similar
problems. Currently, during the rewrite phase of ALTER TABLE,
find_composite_type_dependencies is used to verify that the table's
row type (or any type directly or indirectly depending on that type)
is not us
Roger Leigh writes:
> The following patch adds in an nl_langinfo(CODESET) check in
> addition to the existing client encoding check.
I think the consensus is pretty clear that we should just set the
default linestyle to ascii and not try to be cute with it. (I had
already committed a patch to th
Itagaki Takahiro wrote:
> KaiGai Kohei wrote:
>> -- keep it smaller, and step-by-step enhancement
>
> I'd prefer "smaller concept" rather than "smaller patch".
Its difference is unclear for me.
In this CF, I separated most of separatable concepts to reduce
size of the patch, as follows:
- No
"Kevin Grittner" writes:
> I ran across the subject issue and spent some time puzzling over it.
> ...
> I'm not sure whether Tom's comment that "There is zero hope of
> making that work." referred to the idea that we could close deleted
> WAL files or to something else. Is a fix feasible?
The re
2009/11/25 Jeff Davis :
> On Wed, 2009-11-25 at 11:32 +0100, Pavel Stehule wrote:
>> 1.
>> postgres=# select count(*) from generate_series(1,100);
>> count
>> ─
>> 100
>> (1 row)
>>
>> Time: 930,720 ms
>>
>> 2.
>> postgres=# select count(*) from (select generate_series(1,100)
"Kevin Grittner" wrote:
> I guess it is a stretch to imagine that a database would have
> enough read-only connections to exhaust resources by holding open
> one deleted WAL file each; unless they have, say, 200 such
> connections and they're cutting things so close that a wasted 3.2GB
> of disk
On Nov 19, 2009 1:18am, Andrew Gierth wrote:
Right, but including more data in a single type is the wrong approach,
since it complicates the semantics and interferes with normalization.
For example, if you have a type T which incorporates a timestamp and a
timezone, what semantics does the T =
> hernan> The support of timezones is really crippled
> hernan> now.
>
> Crippled how?
Well, among other things, no builtin date-timetype allows me to save
the timezone (or even the offset).
No type allows to treat this three datetimes as different values.
'2010-07-27 10:30 GMT+4' '2010-07-27 0
KaiGai Kohei wrote:
> -- keep it smaller, and step-by-step enhancement
I'd prefer "smaller concept" rather than "smaller patch".
I think the philosophy of SE-PgSQL itself is ok,
but there are some issues in the design and implementation:
No interaction with existing features
* SE-P
Oleg Bartunov writes:
> I tried to force query to use index by specifying high execution cost, but
> without success, even seqscan cost doesn't changed. This is 8.4.1
I think you altered the wrong function. The function underlying
point <@ box is on_pb() not pt_contained_box ... in fact, I don't
Andres Freund writes:
> On Wednesday 25 November 2009 23:01:35 Tom Lane wrote:
>> I think that's really essential, not optional. The proposed patch will
>> transfer the application name from one backend to another without any
>> encoding conversion. If it contains non-ASCII characters that will
On Wed, Nov 25, 2009 at 07:46:11PM +0100, Pavel Stehule wrote:
> 2009/11/25 Tom Lane :
> > Pavel Stehule writes:
> >> I was surprised with rounding relative not big value. Is it
> >> correct?
> >
> > You do realize float4 has only 6 decimal digits of precision?
> >
>
> To today I though so float4
Jeff Davis writes:
> On Wed, 2009-11-25 at 09:02 -0500, Robert Haas wrote:
>> I disagree wholeheartedly. :-) My ideal error message is something like:
>>
>> DETAIL: (a, b, c)=(1, 2, 3) conflicts with (a, b, c)=(4, 5, 6)
> Ok, fair enough. But how do you feel about:
> (a: 1, b: 2, c: 3)
> as
On Wednesday 25 November 2009 23:01:35 Tom Lane wrote:
> Dave Page writes:
> > On Wed, Nov 25, 2009 at 1:22 PM, Andres Freund wrote:
> >> One more question: Per my reading of the discussion (which very well
> >> might be flawed), wasnt the plan to limit the availale characters in the
> >> applica
On Wed, 2009-11-25 at 09:02 -0500, Robert Haas wrote:
> I disagree wholeheartedly. :-) My ideal error message is something like:
>
> DETAIL: (a, b, c)=(1, 2, 3) conflicts with (a, b, c)=(4, 5, 6)
>
> In particular, I think it's very important that we only emit the
> columns which are part of th
On Wed, Nov 25, 2009 at 11:30 AM, Tom Lane wrote:
> It seems like the easiest way to resolve this without weird corner
> cases is to say that we fire triggers belonging to the parent table.
> The individual partition child tables either shouldn't have triggers
> at all, or we should restrict the c
On Wed, 2009-11-25 at 11:30 -0500, Tom Lane wrote:
> It seems like the easiest way to resolve this without weird corner
> cases is to say that we fire triggers belonging to the parent table.
> The individual partition child tables either shouldn't have triggers
> at all, or we should restrict the c
On Wed, 2009-11-25 at 08:39 -0500, Emmanuel Cecchet wrote:
> Hannu Krosing wrote:
> > On Tue, 2009-11-24 at 10:08 -0500, Emmanuel Cecchet wrote:
> >
> >> Itagaki Takahiro wrote:
> >>
> >>> I just edited a wiki page for this discussion.
> >>> I hope it can be a help.
> >>> http://wiki.postgr
I ran across the subject issue and spent some time puzzling over it.
It seemed strange that the only backends which were holding open
deleted WAL files were ones where the connection was established
with a login which has no write permissions. Eventually, I vaguely
recalled there was such an issue
Hi there,
I tried to force query to use index by specifying high execution cost, but
without success, even seqscan cost doesn't changed. This is 8.4.1
=# explain select count(*) from spots where coordinates <@
'(0,0),(0.1,0.1)'::box;
QUERY PLAN
Dave Page writes:
> On Wed, Nov 25, 2009 at 1:22 PM, Andres Freund wrote:
>> One more question: Per my reading of the discussion (which very well might be
>> flawed), wasnt the plan to limit the availale characters in the application
>> name to ascii?
> That was suggested, but I thought the even
On Wed, Nov 25, 2009 at 22:07, Peter Eisentraut wrote:
> On ons, 2009-11-25 at 16:27 +0100, Magnus Hagander wrote:
>> Attached is a patch which adds a chapter to git in our documentation,
>> around where we have several chapters about cvs today. It also removes
>> a few very out of date comments a
Last night we had the standby server in a PITR setup seemingly
spontaneously believe it had recovered completely and startup a new
timeline; I'm running this information by you guys to see if what had
happened is considered a bug, or if there is a simple explanation.
So some questions here:
On Wed, Nov 25, 2009 at 09:39:32AM -0500, Tom Lane wrote:
> Peter Eisentraut writes:
> > On tis, 2009-11-24 at 14:19 -0500, Tom Lane wrote:
> >> I think you're being overoptimistic to assume that that's going to
> >> eliminate the issue. It might patch things for Oleg's particular
> >> configurat
On ons, 2009-11-25 at 16:27 +0100, Magnus Hagander wrote:
> Attached is a patch which adds a chapter to git in our documentation,
> around where we have several chapters about cvs today. It also removes
> a few very out of date comments about cvs
I think this whole chapter could be removed and the
On Wed, 2009-11-25 at 11:32 +0100, Pavel Stehule wrote:
> 1.
> postgres=# select count(*) from generate_series(1,100);
> count
> ─
> 100
> (1 row)
>
> Time: 930,720 ms
>
> 2.
> postgres=# select count(*) from (select generate_series(1,100)) x;
> count
> ─
> 1
collateindex.pl is stored in /usr/share/sgml/docbook/. Attached fix
modify docbook.m4 to find correct path.
It would be nice also backported the fix back at least to 8.2.
Thanks Zdenek
diff -r 2d87758e836b config/docbook.m4
--- a/config/docbook.m4 Sun Nov 22 22:06:30 2009 +
+++ b/conf
Argh hit the wrong reply button...
-- Forwarded message --
From: Alex Hunsaker
Date: Wed, Nov 25, 2009 at 10:20
Subject: Re: [HACKERS] Writeable CTE patch
To: Marko Tiikkaja
On Mon, Nov 23, 2009 at 14:33, Marko Tiikkaja
wrote:
> Hi,
>
> Sorry for the delay, I've been very bus
2009/11/25 Tom Lane :
> Pavel Stehule writes:
>> I was surprised with rounding relative not big value. Is it correct?
>
> You do realize float4 has only 6 decimal digits of precision?
>
To today I though so float4 is more practical :).
I am smarter now
Pavel
> regards, to
Pavel Stehule writes:
> I was surprised with rounding relative not big value. Is it correct?
You do realize float4 has only 6 decimal digits of precision?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your sub
Jeff Davis writes:
> On Wed, 2009-11-25 at 09:23 +0100, Pavel Stehule wrote:
>>> If SRFs use a tuplestore in that situation, it sounds like that should
>>> be fixed. Why do we need to provide alternate syntax involving COPY?
>>
>> It isn't problem of SRF function design. It allow both mode - row
Hello
I was surprised with rounding relative not big value. Is it correct?
postgres=# select 499188.546875::real;
float4
499189
(1 row)
regards
Pavel Stehule
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postg
Andres Freund wrote:
> On Saturday 14 November 2009 15:33:00 Kevin Grittner wrote:
>> Andres Freund wrote:
>> > I had a bug there and it was not found by the regression tests.
>> > Perhaps I should take a stab and add at least some more...
>>
>> Sounds like a good idea.
> Hm. There actually
On Tue, Nov 24, 2009 at 10:39 PM, Pavel Stehule wrote:
> yes - it is two features - and should be solved independently
There are some common problems though. I was thinking about this with
some mind towards my existing mental model of thinking of specifying
some parameters up-front and getting a
Hi
I'm currently investigating how much work it'd be to implement arrays of
domains since I have a client who might be interested in sponsoring that
work.
The comments around the code handling ALTER DOMAIN ADD CONSTRAINT are
pretty clear about the lack of proper locking in that code - altering a
It seems like the easiest way to resolve this without weird corner
cases is to say that we fire triggers belonging to the parent table.
The individual partition child tables either shouldn't have triggers
at all, or we should restrict the cases in which those are considered
applicable.
As an examp
Simon Riggs writes:
> An idle-in-transaction transaction can also hold a temporary file. Think
> of an open cursor, for example. Therefore, remove the distinction
> between CONFLICT_MODE_ERROR and CONFLICT_MODE_ERROR_IF_NOT_IDLE,
> idle-in-transaction backends need to be killed too when a tablespa
Andrew Dunstan wrote:
On Wed, November 25, 2009 10:04 am, Tom Lane wrote:
I'm now pretty well convinced that this patch is *not* worth the amount
of pain it will cause if it's invoked by default, no matter what
restrictions we try to place on that. We should just make the default
be linestyle=
Following on from my earlier draft plperl.c refactoring patch, here's a
new version that's complete (from my perspective at least).
I've started work on the enhancements to plperl I outlined on pg-general
(in the "Wishlist of PL/Perl Enhancements for 8.5" thread).
I have a working implementation o
Attached is a patch which adds a chapter to git in our documentation,
around where we have several chapters about cvs today. It also removes
a few very out of date comments about cvs (really, nobody has a 28k8
modem and does cvs over it today. Even your cellphone is orders of
magnitude faster than
On Wed, November 25, 2009 10:04 am, Tom Lane wrote:
> I'm now pretty well convinced that this patch is *not* worth the amount
> of pain it will cause if it's invoked by default, no matter what
> restrictions we try to place on that. We should just make the default
> be linestyle=ascii, period.
>
Magnus Hagander writes:
> On Wed, Nov 25, 2009 at 15:41, Tom Lane wrote:
>> Magnus Hagander writes:
>>> FWIW, this patch also *completely* breaks the default windows
>>> installs, which will have the database in UTF-8 but there is *never*
>>> any UTF-8 support on the console (only UTF-16).
>>
>
On Wed, Nov 25, 2009 at 15:41, Tom Lane wrote:
> Magnus Hagander writes:
>> FWIW, this patch also *completely* breaks the default windows
>> installs, which will have the database in UTF-8 but there is *never*
>> any UTF-8 support on the console (only UTF-16).
>
> Hmm ... so how do we work with u
Magnus Hagander writes:
> FWIW, this patch also *completely* breaks the default windows
> installs, which will have the database in UTF-8 but there is *never*
> any UTF-8 support on the console (only UTF-16).
Hmm ... so how do we work with utf-8 data in the database? That
should be the same case
Peter Eisentraut writes:
> On tis, 2009-11-24 at 14:19 -0500, Tom Lane wrote:
>> I think you're being overoptimistic to assume that that's going to
>> eliminate the issue. It might patch things for Oleg's particular
>> configuration; but the real problem IMO is that people are depending
>> on ~/.
On Wed, Nov 25, 2009 at 9:21 AM, Emmanuel Cecchet wrote:
> Robert Haas wrote:
>> On Wed, Nov 25, 2009 at 5:03 AM, Hannu Krosing
>> wrote:
>>>
>>> I'd propose that triggers on both parent table and selected child are
>>> executed.
>>
>> I was thinking we should make the partitioning decision FIRST
Robert Haas wrote:
On Wed, Nov 25, 2009 at 5:03 AM, Hannu Krosing wrote:
I'd propose that triggers on both parent table and selected child are
executed.
I was thinking we should make the partitioning decision FIRST, before
any triggers are fired, and then fire only those triggers rele
On Wed, Nov 25, 2009 at 5:03 AM, Hannu Krosing wrote:
> I'd propose that triggers on both parent table and selected child are
> executed.
I was thinking we should make the partitioning decision FIRST, before
any triggers are fired, and then fire only those triggers relevant to
the selected partit
2009/11/24 KaiGai Kohei :
> BTW, I plan the following steps for the row-level security.
> | * A facility to put "security label OID" within the tuple header.
> | * System column support to print out the security context.
> | (This system column shall be writable to relabel)
> | * Pure-SQL row-lev
On Wed, Nov 25, 2009 at 3:23 AM, Jeff Davis wrote:
>> I was thinking maybe you call BuildIndexValueDescription twice and
>> make the error message say something like
>> conflicts with .
>
> Do you really think that's a better error message, or are you just
> trying to re-use similar code?
>
> Let
Recent change:
An idle-in-transaction transaction can also hold a temporary file. Think
of an open cursor, for example. Therefore, remove the distinction
between CONFLICT_MODE_ERROR and CONFLICT_MODE_ERROR_IF_NOT_IDLE,
idle-in-transaction backends need to be killed too when a tablespace is
droppe
Hannu Krosing wrote:
On Tue, 2009-11-24 at 10:08 -0500, Emmanuel Cecchet wrote:
Itagaki Takahiro wrote:
I just edited a wiki page for this discussion.
I hope it can be a help.
http://wiki.postgresql.org/wiki/Table_partitioning
I guess the problem of handling user triggers is
On Tue, Nov 24, 2009 at 22:35, Tom Lane wrote:
> Oleg Bartunov writes:
>> what's benefit of using linestyle=unicode ? I like old ASCII style
>> for console.
>
> Well, I have to grant that it looks pretty spiffy on a unicode-enabled
> display. Whether that's enough reason to risk breaking things
On Wednesday 25 November 2009 14:28:14 Dave Page wrote:
> On Wed, Nov 25, 2009 at 1:22 PM, Andres Freund wrote:
> > Hi,
> >
> > On Thursday 22 October 2009 15:07:13 Dave Page wrote:
> >> Updated patch attached. Per discussion, this:
> >>
> >> - Changes the envvar name to PGAPPNAME
> >> - Removes s
On Wed, Nov 25, 2009 at 1:22 PM, Andres Freund wrote:
> Hi,
>
> On Thursday 22 October 2009 15:07:13 Dave Page wrote:
>> Updated patch attached. Per discussion, this:
>>
>> - Changes the envvar name to PGAPPNAME
>> - Removes support for setting application_name in the startup packet,
>> and instea
Hi,
On Thursday 22 October 2009 15:07:13 Dave Page wrote:
> Updated patch attached. Per discussion, this:
>
> - Changes the envvar name to PGAPPNAME
> - Removes support for setting application_name in the startup packet,
> and instead sends an explicit SET command as part of the connection
> setu
On Saturday 14 November 2009 15:33:00 Kevin Grittner wrote:
> Andres Freund wrote:
>
> On Saturday 14 November 2009 01:03:33 Kevin Grittner wrote:
> >> It is in context format, applies cleanly, and passes "make check".
> >
> > Unfortunately the latter is not saying much - I had a bug there and
>
On tis, 2009-11-24 at 14:19 -0500, Tom Lane wrote:
> I think you're being overoptimistic to assume that that's going to
> eliminate the issue. It might patch things for Oleg's particular
> configuration; but the real problem IMO is that people are depending
> on ~/.psqlrc to set encoding/locale re
On ons, 2009-11-25 at 00:14 +, Roger Leigh wrote:
> For the specific case here, where the locale is KOI8-R, we can
> determine at runtime that this isn't a UTF-8 locale and stay
> using ASCII. I'll be happy to send a patch in to correct this
> specific case.
There is already a proposed patch
On tis, 2009-11-24 at 14:19 -0500, Tom Lane wrote:
> I wonder whether the most prudent solution wouldn't be to prevent
> default use of linestyle=unicode if ~/.psqlrc hasn't been read.
More generally, it would probably be safer if we used linestyle=unicode
only if the client encoding has been set
On Wed, 2009-11-25 at 13:00 +0200, Heikki Linnakangas wrote:
> I've put up a wiki page with the issues I see with the patch as it
> stands. They're roughly categorized by seriousness.
>
> http://wiki.postgresql.org/wiki/Hot_Standby_TODO
>
> New issues can and probably will still pop up, let's add
Hi,
I know it's documented that CREATE TABLE ... AS SELECT ...
and SELECT ... INTO TEMP ... returns "0" as number of
affected tuples via PQcmdTuples().
Why?
How much work would it be to pass this info up?
The question arose because in ECPG, such statements
like the above returns 0 in sqlca.sqler
I've put up a wiki page with the issues I see with the patch as it
stands. They're roughly categorized by seriousness.
http://wiki.postgresql.org/wiki/Hot_Standby_TODO
New issues can and probably will still pop up, let's add them to the
list as they're found so that we know what still needs to be
2009/11/25 Jeff Davis :
> On Wed, 2009-11-25 at 09:23 +0100, Pavel Stehule wrote:
>> > If SRFs use a tuplestore in that situation, it sounds like that should
>> > be fixed. Why do we need to provide alternate syntax involving COPY?
>>
>> It isn't problem of SRF function design. It allow both mode -
On Tue, 2009-11-24 at 21:13 -0800, Jeff Davis wrote:
> On Tue, 2009-11-24 at 23:44 -0500, Tom Lane wrote:
> > If you do that, then there is no possibility of ever using this feature
> > except with C-coded functions, which seems to me to remove most of
> > whatever use-case there was.
>
> It fits
On Tue, 2009-11-24 at 10:08 -0500, Emmanuel Cecchet wrote:
> Itagaki Takahiro wrote:
> > I just edited a wiki page for this discussion.
> > I hope it can be a help.
> > http://wiki.postgresql.org/wiki/Table_partitioning
> >
> I guess the problem of handling user triggers is still open.
> If we a
2009/11/24 Tom Lane :
> Magnus Hagander writes:
>> ISTM that it should be as simple as the attached patch. Seems to work
>> for me :-) But I'm no autoconf guru, so maybe I missed something?
>
> This patch sort of begs the question "what about enable-thread-safety-force?"
> That looks even more lik
Itagaki Takahiro wrote:
KaiGai Kohei wrote:
Internal structures
http://wiki.postgresql.org/wiki/SEPostgreSQL_Architecture#Interaction_between_pg_security_system_catalog
In SELinux model, massive number of objects shares a limited number of
security context (e.g more than 100 tables
On Wed, 2009-11-25 at 09:23 +0100, Pavel Stehule wrote:
> > If SRFs use a tuplestore in that situation, it sounds like that should
> > be fixed. Why do we need to provide alternate syntax involving COPY?
>
> It isn't problem of SRF function design. It allow both mode - row and
> tuplestor.
select
KaiGai Kohei wrote:
> >>> Internal structures
> http://wiki.postgresql.org/wiki/SEPostgreSQL_Architecture#Interaction_between_pg_security_system_catalog
>
> In SELinux model, massive number of objects shares a limited number of
> security context (e.g more than 100 tables may have a s
2009/11/25 Jeff Davis :
> On Wed, 2009-11-25 at 07:36 +0100, Pavel Stehule wrote:
>> > Moving records from a function to a table can be done with:
>> > INSERT INTO mytable SELECT * FROM myfunc();
>> > And that already works fine.
>>
>> It works, but COPY FROM myfunc() should be significantly faste
83 matches
Mail list logo
