Brar Piening wrote:
I use rss to follow up on patches that I'm interested in and it's the
second time I was wonering where my patch has gone in the commitfest
app due to $Topic.
Just after pushing the send button my RSS-feed got updated and contained
the relevant information.
Sorry for the
I use rss to follow up on patches that I'm interested in and it's the
second time I was wonering where my patch has gone in the commitfest app
due to $Topic.
Is this a known limitation?
If yes: Is there a way to change this?
If yes: Can/shall I help?
If yes: Where should I start?
Regards,
Br
Sorry.
I was not previously able to answer fujii's all comments.
This is the remaining answers.
> + LWLockAcquire(WALInsertLock, LW_EXCLUSIVE);
> + XLogCtl->Insert.fullPageWrites = fullPageWrites;
> + LWLockRelease(WALInsertLock);
>
> I don't think WALInsertLock needs to be hold her
> > > ERROR: full_page_writes on master is set invalid at least once since
> > > latest checkpoint
> > >
> > > I think this error should be rewritten as
> > > ERROR: full_page_writes on master has been off at some point since
> > > latest checkpoint
> > >
> > > We should be using 'off' instead of
On Wed, Oct 12, 2011 at 15:33, Alex Hunsaker wrote:
> On Wed, Oct 12, 2011 at 15:00, Tom Lane wrote:
>> The core of the problem seems to be that if SvROK(sv) then
>> the code assumes that it must be intended to convert that to an array or
>> composite, no matter whether the declared result type
Hello, the work is finished.
Version 4 of the patch is attached to this message.
- Add rough description of the algorithm as comment to
pg_utf8_increment() and pg_eucjp_increment().
- Fixed a bug of pg_utf8_increment() found while
working. pg_(utf8|eucjp)_increment are retested on whole
Simon,
I haven't see a response from you on a proposed way to keep backwards
compatibility with recovery.conf as a trigger file, while also
eliminating its trigger status as an unmanagable misfeature. As far as
I can tell, that's the one area where we *cannot* maintain backwards
compatibility.
-
On Wed, Oct 12, 2011 at 2:49 PM, Robert Haas wrote:
> So, I think the critical question for this patch is "do we want
> this?".
Yep. Or put another way, are the gains worth having another system
view we'll have to maintain forever?
> Tom didn't like it,
In [1], Tom seemed to be mainly angling f
On Wed, Oct 12, 2011 at 10:29 PM, Robert Haas wrote:
> On Wed, Oct 12, 2011 at 5:45 AM, Fujii Masao wrote:
>> In 9.2dev and 9.1, when walreceiver detects an error while sending data to
>> WAL stream, it always emits ERROR even if there are data available in the
>> receive buffer. This might lead
On Wed, Oct 12, 2011 at 17:53, David E. Wheeler wrote:
> On Sep 15, 2011, at 3:04 PM, Alex Hunsaker wrote:
>
>> Close, seems I was wrong about the typemap ExtUtils::ParseXS does not
>> install a new one so we still need to point to the one in privlib.
>> Also xsubpp is not executable so the test s
On Sep 15, 2011, at 3:04 PM, Alex Hunsaker wrote:
> Close, seems I was wrong about the typemap ExtUtils::ParseXS does not
> install a new one so we still need to point to the one in privlib.
> Also xsubpp is not executable so the test should be -r or something.
>
> Also don't think we should chan
Phil Sorber writes:
> Then there is a separate section of code that is called as a separate
> function 'dumpUserConfig()' that does other role attributes like
> 'ALTER ROLE bob SET role TO charlie'. These are the ALTER's that can
> have dependencies on other roles.
Right. Phrased that way, this
I wrote:
> Hmm. I'm afraid that's going to break something, because I had had it
> like that originally and changed it in commit
> 988620dd8c16d77f88ede167b22056176324. However, I'm not quite sure
> *what* it will break, because it seems like in general extension
> dependencies ought to act p
On Wed, Oct 12, 2011 at 15:00, Tom Lane wrote:
> "David E. Wheeler" writes:
>> On Oct 12, 2011, at 9:15 AM, Tom Lane wrote:
>>> Well, the real question is why a function declared to return VOID cares
>>> at all about what the last command in its body is. If this has changed
>>> since previous ve
Bruce Momjian wrote:
> Mark wrote:
> > >There's some potentially useful information here:
> > >http://www.postgresql.org/docs/9.0/interactive/textsearch-controls.html#TEXTSEARCH-RANKING
> >
> > Thanks for reply. I was reading the documentation of PostgreSQL, but there
> > it is not written the nam
On Wed, Oct 12, 2011 at 1:44 PM, Florian Pflug wrote:
> On Oct11, 2011, at 23:35 , Simon Riggs wrote:
>> On Tue, Oct 11, 2011 at 10:30 PM, Florian Pflug wrote:
>>
>>> That experience has taught me that backwards compatibility, while very
>>> important in a lot of cases, has the potential to do ju
Robert Haas writes:
> On Mon, Oct 10, 2011 at 2:52 PM, Tom Lane wrote:
>> The underlying issue here is whether objects dependent on an extension
>> member should have direct dependencies on the extension too, and if not,
>> how do we prevent that? The recordDependencyOnCurrentExtension calls
>>
> In that case you do "pg_dumpall -r" first and then pg_dump your
> individual database. I thought you were looking for something that
> would dump only roles referenced in the particular database, which
> is why it sounded like an intermediate case.
>
> I know that the division of labor between
Tom Lane writes:
> regression=# \i ~/postgres/share/extension/cube--1.0.sql
> Use "CREATE EXTENSION cube" to load this file.
> regression=#
Great work, thank you!
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
--
Sent via pgsql-hackers mailing list
On Mon, Oct 10, 2011 at 2:52 PM, Tom Lane wrote:
> Robert Haas writes:
>> But there's a bigger problem: it seems to me that we have an
>> inconsistency between what happens when you create an extension from
>> scratch and when you upgrade it from unpackaged. Both pg_buffercache
>> and pg_stat_st
"David E. Wheeler" writes:
> On Oct 12, 2011, at 9:15 AM, Tom Lane wrote:
>> Well, the real question is why a function declared to return VOID cares
>> at all about what the last command in its body is. If this has changed
>> since previous versions then I think it's a bug and we should fix it,
>
Tom Lane wrote:
> Bruce Momjian writes:
> > Tom Lane wrote:
> >> Now having said that, there seems to be a pgindent bug here too, in that
> >> it's throwing a space into
> >>
> >> Buffer
> >> RelationGetBufferForTuple(Relation relation, Size len,
> >> Buffer otherBuffer, int options,
> >> struct
Andrew Dunstan wrote:
> Now we could certainly make this quite a bit slicker. Apart from
> anything else, we should change the indent source code tarball so it
> unpacks into its own directory. Having it unpack into the current
Yes, done.
> directory is ugly and unfriendly. And we should get r
Alvaro Herrera wrote:
> Excerpts from Tom Lane's message of lun abr 25 20:48:42 -0300 2011:
> > Andrew Dunstan writes:
>
> > > Well, that way you'll have a handful of -Ttypdef parameters for each
> > > invocation of indent instead of a gazillion of them. No more command
> > > line length issues
On Wed, Oct 12, 2011 at 3:48 PM, Robert Haas wrote:
> On Wed, Oct 12, 2011 at 2:27 PM, Phil Sorber wrote:
>> I am going to remove that patch from the commit fest because we all
>> agree that it does not solve the problem satisfactorily. I would like
>> to re-iterate a few points, and submit a new
Josh Berkus writes:
> On 10/11/11 9:43 PM, Tom Lane wrote:
>> I don't find this terribly convincing. I can see the rationales for two
>> endpoint cases: (1) restore these objects into exactly the same
>> ownership/permissions environment that existed before, and (2) restore
>> these objects with
On Wed, Oct 12, 2011 at 2:27 PM, Phil Sorber wrote:
> I am going to remove that patch from the commit fest because we all
> agree that it does not solve the problem satisfactorily. I would like
> to re-iterate a few points, and submit a new patch.
>
> First off, there are two distinct problems her
On 10/12/2011 03:16 PM, Josh Berkus wrote:
On 10/11/11 9:43 PM, Tom Lane wrote:
I don't find this terribly convincing. I can see the rationales for two
endpoint cases: (1) restore these objects into exactly the same
ownership/permissions environment that existed before, and (2) restore
these
On 10/12/2011 12:43 AM, Tom Lane wrote:
Josh Berkus writes:
The reason I want to have the dependant roles created as part of a
database dump is so that we can ship around dump files as a single file,
and restore them with a single command. This is considerably simpler
than the current requir
On Thu, Sep 29, 2011 at 4:52 PM, Kohei KaiGai wrote:
> I noticed that the previous revision does not provide any way to inform
> the modules name of foreign server, even if foreign table was created,
> on the OAT_POST_CREATE hook.
> So, I modified the invocation at heap_create_with_catalog to deli
On 10/11/11 9:43 PM, Tom Lane wrote:
> I don't find this terribly convincing. I can see the rationales for two
> endpoint cases: (1) restore these objects into exactly the same
> ownership/permissions environment that existed before, and (2) restore
> these objects with the absolute minimum of own
On Mon, Oct 10, 2011 at 11:54 AM, Robert Haas wrote:
> On Thu, Aug 4, 2011 at 2:04 PM, Robert Haas wrote:
>> On Thu, Aug 4, 2011 at 1:53 PM, Phil Sorber wrote:
>>> Ok, here is the patch that just moves the ALTER/SET pieces to the end.
>>> Can we get this included in the next commit fest?
>>
>> Y
Andrew Dunstan writes:
> On 10/12/2011 02:21 PM, Magnus Hagander wrote:
>> I guess the failure scenario is if someone has an extension from 9.1.2
>> and tries to load it into 9.1.1 or earlier, in which case they will
>> get a syntax error or somehing when trying to run the CREATE EXTENSION
>> comm
On Sun, Sep 11, 2011 at 10:11 AM, Josh Kupershmidt wrote:
> On Sat, Sep 10, 2011 at 7:47 PM, Thom Brown wrote:
>> Just tested this out on current master. I tried this on every object
>> capable of having a comment, and the view reports all of them with the
>> correct details. Doc changes look f
On 10/12/2011 02:21 PM, Magnus Hagander wrote:
On Wed, Oct 12, 2011 at 19:36, Tom Lane wrote:
regression=# \i ~/postgres/share/extension/cube--1.0.sql
Use "CREATE EXTENSION cube" to load this file.
regression=#
which is about as good as one could hope for.
Looks great to me.
Yes, me too.
On Wed, Oct 12, 2011 at 03:16:54PM +0100, Greg Stark wrote:
> On Wed, Oct 12, 2011 at 2:52 PM, Tom Lane wrote:
> > I think it's overkill, and possibly unpleasantly unstable as well.
> > For the initial attack on this we should just have VACUUM and ANALYZE
> > count the number of all-visible blocks
Magnus Hagander writes:
> On Wed, Oct 12, 2011 at 19:36, Tom Lane wrote:
>> PFA, a sample patch for this --- I've only bothered to change one script
>> file here, but will of course do the rest if there are no further
>> objections.
> I guess the failure scenario is if someone has an extension f
On Wed, Oct 12, 2011 at 19:36, Tom Lane wrote:
> Magnus Hagander writes:
>> On Wed, Oct 12, 2011 at 17:40, Tom Lane wrote:
>>> The only thing the \echo approach will cost us is a few more lines of C
>>> code in execute_extension_script(), and I think it's more than worth
>>> that given the evide
Magnus Hagander wrote:
> > I looked over this issue and I don't thinking having pg_ctl restart fall
> > back to 'start' is a good solution. ?I am concerned about cases where we
> > start a different server without shutting down the old server, for some
> > reason. ?When they say 'restart', I think
Magnus Hagander writes:
> On Wed, Oct 12, 2011 at 17:40, Tom Lane wrote:
>> The only thing the \echo approach will cost us is a few more lines of C
>> code in execute_extension_script(), and I think it's more than worth
>> that given the evident scope of the problem.
> +1.
PFA, a sample patch f
On Tue, Oct 11, 2011 at 23:35, Bruce Momjian wrote:
> Robert Haas wrote:
>> On Wed, Mar 23, 2011 at 1:48 AM, Fujii Masao wrote:
>> > On Sat, Mar 19, 2011 at 10:20 AM, Robert Haas
>> > wrote:
>> >> On Fri, Mar 18, 2011 at 1:19 PM, Erik Rijkers wrote:
>> >>> This is OK and expected. ?But then it
I wrote:
>> I was also toying with the notion of pushing the slot fill-in into the
>> AM, so that the AM API is to return a filled TupleSlot not an
>> IndexTuple. This would not save any cycles AFAICT --- at least in
>> btree, we still have to make a palloc'd copy of the IndexTuple so that
>> we c
On Wed, Oct 12, 2011 at 17:40, Tom Lane wrote:
> Heikki Linnakangas writes:
>> On 12.10.2011 18:20, Tom Lane wrote:
>>> Well, it can't be a comment, but what about a real psql command?
>>> See my suggestion of using \echo.
>
>> Frankly I think a comment is sufficient. We can make it more complica
On Wed, Oct 12, 2011 at 11:59 AM, Tom Lane wrote:
> Robert Haas writes:
>> I'm not concerned about an index scan vs. a sequential scan here. I'm
>> concerned about it being impossible for the DBA to get an index-only
>> scan when s/he wants it very badly. The current (stupid) formula
>> handles
On Oct 12, 2011, at 9:15 AM, Tom Lane wrote:
> Well, the real question is why a function declared to return VOID cares
> at all about what the last command in its body is. If this has changed
> since previous versions then I think it's a bug and we should fix it,
> not just change the example.
I
"David E. Wheeler"
writes:
> On Oct 12, 2011, at 2:16 AM, Amit Khandekar wrote:
>> CREATE OR REPLACE FUNCTION myfuncs() RETURNS void AS $$
>> $_SHARED{myquote} = sub {
>> my $arg = shift;
>> $arg =~ s/(['\\])/\\$1/g;
>> return "'$arg'";
>> };
>> $$ LANGUAGE plperl;
>>
>> SELECT myfuncs(); /* in
On Oct 12, 2011, at 2:16 AM, Amit Khandekar wrote:
> CREATE OR REPLACE FUNCTION myfuncs() RETURNS void AS $$
>$_SHARED{myquote} = sub {
>my $arg = shift;
>$arg =~ s/(['\\])/\\$1/g;
>return "'$arg'";
>};
> $$ LANGUAGE plperl;
>
> SELECT myfuncs(); /* initializes the
Robert Haas writes:
> I'm not concerned about an index scan vs. a sequential scan here. I'm
> concerned about it being impossible for the DBA to get an index-only
> scan when s/he wants it very badly. The current (stupid) formula
> handles this case just about perfectly - it will prefer a smalle
On Wed, Oct 12, 2011 at 10:37 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Oct 12, 2011 at 9:52 AM, Tom Lane wrote:
>>> What bothers me considerably more is the issue about how specific
>>> queries might see an all-visible fraction that's very substantially
>>> different from the table's
Heikki Linnakangas writes:
> On 12.10.2011 18:20, Tom Lane wrote:
>> Well, it can't be a comment, but what about a real psql command?
>> See my suggestion of using \echo.
> Frankly I think a comment is sufficient. We can make it more complicated
> later if people are still confused.
The thing i
On 12.10.2011 18:20, Tom Lane wrote:
Heikki Linnakangas writes:
On 12.10.2011 17:33, Magnus Hagander wrote:
How about adding something like
-- \\psql_hates_this
-- rest of comment
and then at least have new versions of psql find that and stop
processing the file with a more useful error at th
On Wed, Oct 12, 2011 at 11:24 AM, Heikki Linnakangas
wrote:
>>> Overengineering IMHO. Besides, if a psql poison comment like that
>>> exists, then we'd have to be careful not to emit one elsewhere. Think
>>> pg_dump, if someone puts that comment in a function body...
>>
>> Well, it can't be a comm
Aidan Van Dyk writes:
> The elephant in the room is that the index-only-scan really doesn't
> save a *whole* lot if the heap pages are already in shared buffers.
> But it matters a *lot* when they heap pages are not in shared buffers
> (both ways, saving IO, or causing lots of random IO)
> Can we
On Wed, Oct 12, 2011 at 4:26 PM, Kevin Grittner
wrote:
>> But it matters a *lot* when they heap pages are not in shared
>> buffers
>
> Yeah, obviously it matters more if you actually need to add a random
> disk read.
To be fair the indexes are also random I/O. So the case that really
matters is w
Aidan Van Dyk wrote:
> The elephant in the room is that the index-only-scan really
> doesn't save a *whole* lot if the heap pages are already in shared
> buffers.
It's not hard to create a simple test case where it's about three
times slower to go to cached heap pages than to use the values fr
On 10/12/2011 11:15 AM, Tom Lane wrote:
\echo Use "CREATE EXTENSION foo" to load this file. \quit
+1 for this.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgs
Heikki Linnakangas writes:
> On 12.10.2011 17:33, Magnus Hagander wrote:
>> How about adding something like
>> -- \\psql_hates_this
>> -- rest of comment
>>
>> and then at least have new versions of psql find that and stop
>> processing the file with a more useful error at that point? Or maybe
>>
Greg Stark writes:
> On Wed, Oct 12, 2011 at 3:29 PM, Tom Lane wrote:
>> The problem is precisely that the pages a query is going to read are
>> likely to *not* be a random sample, but to be correlated with
>> recently-dirtied pages.
> Sure, but I was suggesting aiming for the nth percentile rat
Aidan Van Dyk writes:
> On Wed, Oct 12, 2011 at 10:50 AM, Tom Lane wrote:
>> Hmm ...
>> \echo You should use CREATE EXTENSION foo to load this file!
> Decorate them with a marker like:
>\extension
> And make the CREATE EXTENSION skip (or verify) it?
> It will make psql stop on the \extensi
On Wed, Oct 12, 2011 at 10:50 AM, Tom Lane wrote:
> Andrew Dunstan writes:
>> *shrug* ok. Another thought I had was to have the file raise an error
>> and have that filtered out by the extension mechanism. But I'm not sure
>> if it's worth the trouble.
>
> Hmm ...
>
> \echo You should use CREATE
On 12.10.2011 17:33, Magnus Hagander wrote:
How about adding something like
-- \\psql_hates_this
-- rest of comment
and then at least have new versions of psql find that and stop
processing the file with a more useful error at that point? Or maybe
that's overengineering..
Overengineering IMHO.
On Wed, Oct 12, 2011 at 3:29 PM, Tom Lane wrote:
>>> What I suggest as a first cut for that is: simply derate the visibility
>>> fraction as the fraction
>>> of the table expected to be scanned gets smaller.
>
>> I think there's a statistically more rigorous way of accomplishing the
>> same thing
On Wed, Oct 12, 2011 at 10:37 AM, Tom Lane wrote:
>> - Suppose the table has a million rows and we're going to read 100 of
>> them, or 0.01%. Now it might appear that a covering index has a
>> negligible advantage over a non-covering index, but in fact I think we
>> still want to err on the side
Andrew Dunstan writes:
> *shrug* ok. Another thought I had was to have the file raise an error
> and have that filtered out by the extension mechanism. But I'm not sure
> if it's worth the trouble.
Hmm ...
\echo You should use CREATE EXTENSION foo to load this file!
and teach CREATE EXTENSION
Robert Haas writes:
> On Wed, Oct 12, 2011 at 9:52 AM, Tom Lane wrote:
>> What bothers me considerably more is the issue about how specific
>> queries might see an all-visible fraction that's very substantially
>> different from the table's overall ratio,
> - Suppose VACUUM processes the table a
On Wed, Oct 12, 2011 at 16:31, Andrew Dunstan wrote:
>
>
> On 10/12/2011 10:12 AM, Tom Lane wrote:
>>
>> Robert Haas writes:
>>>
>>> We could do that, but I think Heikki's idea of adding a comment would
>>> help a lot.
>>
>> +1. Simple, easy, should help significantly.
>>
>> Also, I disagree wit
On 10/12/2011 10:12 AM, Tom Lane wrote:
Robert Haas writes:
We could do that, but I think Heikki's idea of adding a comment would
help a lot.
+1. Simple, easy, should help significantly.
Also, I disagree with the position that the files "aren't SQL files".
Sure they are. You'd want them
Greg Stark writes:
> Assuming you're in a steady-state situation the amount of all-visible
> blocks will fluctuate from a high just after vacuum to a low just
> before the next vacuum. There are other ways a block can be marked
> all-visible but for the most part I would expect the fraction to go
On Wed, Oct 12, 2011 at 9:52 AM, Tom Lane wrote:
> What bothers me considerably more is the issue about how specific
> queries might see an all-visible fraction that's very substantially
> different from the table's overall ratio, especially in examples such as
> historical-data tables where most
On Wed, Oct 12, 2011 at 2:52 PM, Tom Lane wrote:
> I think it's overkill, and possibly unpleasantly unstable as well.
> For the initial attack on this we should just have VACUUM and ANALYZE
> count the number of all-visible blocks and store that in pg_class along
> with the tuple-count statistics.
Robert Haas writes:
> We could do that, but I think Heikki's idea of adding a comment would
> help a lot.
+1. Simple, easy, should help significantly.
Also, I disagree with the position that the files "aren't SQL files".
Sure they are. You'd want them treated as SQL by your editor, for
exampl
Robert Haas writes:
> On Wed, Oct 12, 2011 at 2:50 AM, Jeff Davis wrote:
>> On Tue, 2011-10-11 at 13:22 -0400, Robert Haas wrote:
>>> The real issue is that the costing estimates need to be accurate, and
>>> that's where the rubber hits the road.
>> Can you send stats messages to keep track when
On Wed, Oct 12, 2011 at 4:42 AM, Magnus Hagander wrote:
>> 9.1 has been out for only a couple of months, and we've seen a lot of people
>> trying to do that already. In hindsight, we probably should've chosen a
>> different filename extension for those files, to make it clear that you
>> can't jus
On Wed, Oct 12, 2011 at 2:50 AM, Jeff Davis wrote:
> On Tue, 2011-10-11 at 13:22 -0400, Robert Haas wrote:
>> The real issue is that the costing estimates need to be accurate, and
>> that's where the rubber hits the road. Otherwise, even if we pick the
>> right way to scan the table, we may do si
On Wed, Oct 12, 2011 at 5:45 AM, Fujii Masao wrote:
> In 9.2dev and 9.1, when walreceiver detects an error while sending data to
> WAL stream, it always emits ERROR even if there are data available in the
> receive buffer. This might lead to loss of transactions because such
> remaining data are n
On Wed, Oct 12, 2011 at 8:44 AM, Florian Pflug wrote:
> With such a switch, every application that relies on true serializability for
> correctness would be prone to silent data corruption should the switch ever
> get set to "off" accidentally.
Agreed.
> Without such a switch, OTOH, all that wil
On 10/12/2011 04:39 AM, Heikki Linnakangas wrote:
On 12.10.2011 10:58, Stefan Kaltenbrunner wrote:
On 10/12/2011 09:53 AM, Martin Pitt wrote:
Hello all,
In https://launchpad.net/bugs/835502 it was reported that the 9.1.1
contrib *.sql files contain the token "MODULE_PATHNAME", which is
unkno
2011/10/12 Robert Haas :
> On Wed, Oct 12, 2011 at 8:07 AM, Kohei KaiGai wrote:
>> I'm currently trying to revise my patches according to your suggestions,
>> but I'm facing a trouble about error messages when user tries to drop
>> a non-exists object.
>>
>> Because the ObjectProperty array has an
On Wed, Oct 12, 2011 at 8:07 AM, Kohei KaiGai wrote:
> I'm currently trying to revise my patches according to your suggestions,
> but I'm facing a trouble about error messages when user tries to drop
> a non-exists object.
>
> Because the ObjectProperty array has an entry for each catalogs, it is
On Oct11, 2011, at 23:35 , Simon Riggs wrote:
> On Tue, Oct 11, 2011 at 10:30 PM, Florian Pflug wrote:
>
>> That experience has taught me that backwards compatibility, while very
>> important in a lot of cases, has the potential to do just as much harm
>> if overdone.
>
> Agreed. Does my suggest
Robert,
I'm currently trying to revise my patches according to your suggestions,
but I'm facing a trouble about error messages when user tries to drop
a non-exists object.
Because the ObjectProperty array has an entry for each catalogs, it is
unavailable to hold the name of object type (such as "
Hi,
In 9.2dev and 9.1, when walreceiver detects an error while sending data to
WAL stream, it always emits ERROR even if there are data available in the
receive buffer. This might lead to loss of transactions because such
remaining data are not received by walreceiver :(
To prevent transaction lo
Hi,
An example in the PG documentation gives an error:
http://www.postgresql.org/docs/9.1/interactive/plperl-global.html
CREATE OR REPLACE FUNCTION myfuncs() RETURNS void AS $$
$_SHARED{myquote} = sub {
my $arg = shift;
$arg =~ s/(['\\])/\\$1/g;
return "'$arg'";
}
On Wed, Oct 12, 2011 at 10:39, Heikki Linnakangas
wrote:
> On 12.10.2011 10:58, Stefan Kaltenbrunner wrote:
>>
>> On 10/12/2011 09:53 AM, Martin Pitt wrote:
>>>
>>> Hello all,
>>>
>>> In https://launchpad.net/bugs/835502 it was reported that the 9.1.1
>>> contrib *.sql files contain the token "MOD
On Wed, Oct 12, 2011 at 8:50 AM, Peter Eisentraut wrote:
> On tis, 2011-10-11 at 21:50 +0100, Simon Riggs wrote:
>> I'm keen to ensure people enjoy the possibility of upgrading to the
>> latest release. The continual need to retest applications mean that
>> very few users upgrade quickly or with a
On 12.10.2011 10:58, Stefan Kaltenbrunner wrote:
On 10/12/2011 09:53 AM, Martin Pitt wrote:
Hello all,
In https://launchpad.net/bugs/835502 it was reported that the 9.1.1
contrib *.sql files contain the token "MODULE_PATHNAME", which is
unknown:
psql test< /usr/share/postgresql/9.1/extensi
On Wed, Oct 12, 2011 at 6:34 AM, Heikki Linnakangas
wrote:
> On 11.10.2011 23:21, Simon Riggs wrote:
>>
>> If the normal default_transaction_isolation = read committed and all
>> transactions that require serializable are explicitly marked in the
>> application then there is no way to turn off SSI
2011/10/12 Jun Ishiduka :
> > ERROR: full_page_writes on master is set invalid at least once since
> > latest checkpoint
> >
> > I think this error should be rewritten as
> > ERROR: full_page_writes on master has been off at some point since
> > latest checkpoint
> >
> > We should be using 'off' in
On tis, 2011-10-11 at 21:50 +0100, Simon Riggs wrote:
> I'm keen to ensure people enjoy the possibility of upgrading to the
> latest release. The continual need to retest applications mean that
> very few users upgrade quickly or with anywhere near the frequency
> with which we put out new releases
> > Some testing notes
> > --
> > select pg_start_backup('x');
> > ERROR: full_page_writes on master is set invalid at least once since
> > latest checkpoint
> >
> > I think this error should be rewritten as
> > ERROR: full_page_writes on master has been off at some po
2011/10/11 Tom Lane :
> Pavel Stehule writes:
>> 2011/10/11 Robert Haas :
>>> On Tue, Oct 11, 2011 at 4:40 AM, Pavel Stehule
>>> wrote:
What do you think about this idea?
>
> It's a bad one.
>
>>> Well, a ROW can contain values of different types; an ARRAY can't.
>
>> yes, I know - but it s
91 matches
Mail list logo
