On 9/22/11 6:59 PM, "Euler Taveira de Oliveira" wrote:
>> If needed, I could do that, if I had the exact procedure... Currently,
>> during the start of the backup I take the following information:
>>
> Just show us the output of pg_start_backup and part of the standby log with
> the following me
On 23.09.2011 11:02, Linas Virbalas wrote:
On 9/22/11 6:59 PM, "Euler Taveira de Oliveira" wrote:
If needed, I could do that, if I had the exact procedure... Currently,
during the start of the backup I take the following information:
Just show us the output of pg_start_backup and part of the
On Sep23, 2011, at 10:41 , Heikki Linnakangas wrote:
> On 23.09.2011 11:02, Linas Virbalas wrote:
>> On 9/22/11 6:59 PM, "Euler Taveira de Oliveira" wrote:
>>
If needed, I could do that, if I had the exact procedure... Currently,
during the start of the backup I take the following infor
On 23.09.2011 11:48, Florian Pflug wrote:
On Sep23, 2011, at 10:41 , Heikki Linnakangas wrote:
On 23.09.2011 11:02, Linas Virbalas wrote:
On 9/22/11 6:59 PM, "Euler Taveira de Oliveira" wrote:
If needed, I could do that, if I had the exact procedure... Currently,
during the start of the bac
Hi, I think I have comprehended roughly around the constructs and
the concept underlying.
At Thu, 22 Sep 2011 12:35:56 -0400, Tom Lane wrote in
<23159.1316709...@sss.pgh.pa.us>
tgl> Sure, if the "increment the top byte" strategy proves to not accomplish
tgl> that effectively. But I'd prefer not
On Wed, Aug 31, 2011 at 11:59, Srinivas Aji wrote:
>
> The following bug has been logged online:
>
> Bug reference: 6189
> Logged by: Srinivas Aji
> Email address: srinivas@emc.com
> PostgreSQL version: 9.0.4
> Operating system: Linux
> Description: libpq: sslmode=r
On Fri, Sep 23, 2011 at 12:26 AM, Pavel Stehule wrote:
> I fixed crash that described Tom. Do you know about other?
No, I just don't see a new version of the patch.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing lis
2011/9/23 Robert Haas :
> On Fri, Sep 23, 2011 at 12:26 AM, Pavel Stehule
> wrote:
>> I fixed crash that described Tom. Do you know about other?
>
> No, I just don't see a new version of the patch.
>
sorry - my mistake - I sent it only to Tom
Regards
Pavel
> --
> Robert Haas
> EnterpriseDB:
Hello list,
I have a use case where an extension dependency can be satisfied by one
of five other extensions. Currently I'm unable to express that in the
extension control file, since the elements from 'requires' are currently
searched on exact name match. The attached patch changes this behav
On 23.09.2011 14:56, Yeb Havinga wrote:
I have a use case where an extension dependency can be satisfied by one
of five other extensions. Currently I'm unable to express that in the
extension control file, since the elements from 'requires' are currently
searched on exact name match. The attached
From: "Magnus Hagander"
To: "Srinivas Aji"
Cc: "PostgreSQL-development"
Sent: Friday, September 23, 2011 7:28:09 AM
Subject: [HACKERS] Re: [BUGS] BUG #6189: libpq: sslmode=require verifies server
certificate if root.crt is present
On Wed, Aug 31, 2011 at 11:59, Srinivas Aji wrote:
>
>
On Fri, Sep 23, 2011 at 14:35, Lou Picciano wrote:
>
> On Wed, Aug 31, 2011 at 11:59, Srinivas Aji wrote:
>>
>> The following bug has been logged online:
>>
>> Bug reference: 6189
>> Logged by: Srinivas Aji
>> Email address: srinivas@emc.com
>> PostgreSQL version: 9.0.4
>>
On Thu, Sep 22, 2011 at 10:36 AM, Tom Lane wrote:
> Anyway, I won't stand in the way of the patch as long as it's modified
> to limit the number of values considered for any one character position
> to something reasonably small.
I think that limit in both the old and new code is 1, except that t
On Fri, Sep 23, 2011 at 5:16 AM, Kyotaro HORIGUCHI
wrote:
> Can I have another chance to show the another version of the
> patch according to the above?
You can always post a new version of any patch.
I think what you need to focus on is cleaning up the coding style to
match PG project standards
On 9/23/11 12:05 PM, "Heikki Linnakangas"
wrote:
>>> It looks to me that pg_clog/0001 exists, but it shorter than recovery
>>> expects. Which shouldn't happen, of course, because the start-backup
>>> checkpoint should flush all the clog that's needed by recovery to disk
>>> before the backup proc
On Fri, Sep 23, 2011 at 8:38 AM, Magnus Hagander wrote:
> On Fri, Sep 23, 2011 at 14:35, Lou Picciano wrote:
>> On Wed, Aug 31, 2011 at 11:59, Srinivas Aji wrote:
>>>
>>> The following bug has been logged online:
>>>
>>> Bug reference: 6189
>>> Logged by: Srinivas Aji
>>> Email add
Robert Haas writes:
> On Thu, Sep 22, 2011 at 10:36 AM, Tom Lane wrote:
>> Anyway, I won't stand in the way of the patch as long as it's modified
>> to limit the number of values considered for any one character position
>> to something reasonably small.
> I think that limit in both the old and
On Fri, Sep 23, 2011 at 8:47 AM, Linas Virbalas
wrote:
> But on the standby its size is the old one (thus, it seems, that the size
> changed after the rsync transfer and before the pg_stop_backup() was
> called):
Now that seems pretty weird - I don't think that file should ever shrink.
Are you s
Magnus Hagander writes:
> I looked at this again, and I'm pretty sure we did this intentionally.
Yeah, we did.
> Or should we just update the documentation to mention how this works?
+1 for doc change only. I think the behavior was thought through
carefully, and the wording of the docs maybe n
From: "Magnus Hagander"
To: "Lou Picciano"
Cc: "PostgreSQL-development" , "Srinivas Aji"
Sent: Friday, September 23, 2011 8:38:00 AM
Subject: Re: [HACKERS] Re: [BUGS] BUG #6189: libpq: sslmode=require verifies
server certificate if root.crt is present
On Fri, Sep 23, 2011 at 14:35, Lou P
On Fri, Sep 23, 2011 at 8:51 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Sep 22, 2011 at 10:36 AM, Tom Lane wrote:
>>> Anyway, I won't stand in the way of the patch as long as it's modified
>>> to limit the number of values considered for any one character position
>>> to something reas
On Thu, Sep 22, 2011 at 12:45 PM, Fujii Masao wrote:
> Agreed. Attached is the updated version of the patch. It adds two options
> --replication and --no-replication. If neither specified, neither REPLICATION
> nor NOREPLICATION is specified in CREATE ROLE, i.e., in this case,
> replication privil
On 2011-09-23 14:19, Heikki Linnakangas wrote:
On 23.09.2011 14:56, Yeb Havinga wrote:
I have a use case where an extension dependency can be satisfied by one
of five other extensions. Currently I'm unable to express that in the
extension control file, since the elements from 'requires' are curr
On Thu, Sep 15, 2011 at 4:52 AM, Fujii Masao wrote:
> Thanks for the review!
Koyotaro Horiguchi -
Are you going to re-review the latest version of this patch?
Thanks,
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing
On Fri, Sep 23, 2011 at 14:49, Robert Haas wrote:
> On Fri, Sep 23, 2011 at 8:38 AM, Magnus Hagander wrote:
>> On Fri, Sep 23, 2011 at 14:35, Lou Picciano wrote:
>>> On Wed, Aug 31, 2011 at 11:59, Srinivas Aji wrote:
The following bug has been logged online:
Bug reference:
On Wed, Sep 21, 2011 at 12:19 PM, Andres Freund wrote:
> /*
> * We also disallow data-modifying WITH in a cursor. (This could be
> * allowed, but the semantics of when the updates occur might be
> * surprising.)
> */
> if (result->hasModifyingCTE)
>
2011/9/23 Robert Haas :
> On Thu, Sep 22, 2011 at 12:45 PM, Fujii Masao wrote:
>> Agreed. Attached is the updated version of the patch. It adds two options
>> --replication and --no-replication. If neither specified, neither REPLICATION
>> nor NOREPLICATION is specified in CREATE ROLE, i.e., in th
2011/9/23 Cédric Villemain :
> 2011/9/23 Robert Haas :
>> On Thu, Sep 22, 2011 at 12:45 PM, Fujii Masao wrote:
>>> Agreed. Attached is the updated version of the patch. It adds two options
>>> --replication and --no-replication. If neither specified, neither
>>> REPLICATION
>>> nor NOREPLICATION
Excerpts from Magnus Hagander's message of vie sep 23 10:39:46 -0300 2011:
> On Fri, Sep 23, 2011 at 14:49, Robert Haas wrote:
> > On Fri, Sep 23, 2011 at 8:38 AM, Magnus Hagander
> > wrote:
> >> On Fri, Sep 23, 2011 at 14:35, Lou Picciano
> >> wrote:
> >>> On Wed, Aug 31, 2011 at 11:59, Srin
[ moving to -hacker s]
On Thu, Sep 22, 2011 at 9:26 PM, Thom Brown wrote:
> On 22 September 2011 17:38, Josh Berkus wrote:
>>
>>> So are there any plans to allow swappable drive/volatile storage
>>> unlogged tables?
>>
>> Be our guest. ;-)
>
> Oh it can't be that difficult. On first glance it
On Fri, Sep 23, 2011 at 15:55, Alvaro Herrera
wrote:
>
> Excerpts from Magnus Hagander's message of vie sep 23 10:39:46 -0300 2011:
>> On Fri, Sep 23, 2011 at 14:49, Robert Haas wrote:
>> > On Fri, Sep 23, 2011 at 8:38 AM, Magnus Hagander
>> > wrote:
>> >> On Fri, Sep 23, 2011 at 14:35, Lou Pic
2011/8/16 Anssi Kääriäinen :
> On 08/14/2011 12:31 AM, Heikki Linnakangas wrote:
>>>
>>> The same idea could of course be used to calculate the effective cache
>>> hit ratio for each table. Cache hit ratio would have the problem of feedback
>>> loops, though.
>>
>> Yeah, I'm not excited about makin
On 23 September 2011 15:12, Robert Haas wrote:
> [ moving to -hacker s]
>
> On Thu, Sep 22, 2011 at 9:26 PM, Thom Brown wrote:
>> On 22 September 2011 17:38, Josh Berkus wrote:
>>>
So are there any plans to allow swappable drive/volatile storage
unlogged tables?
>>>
>>> Be our guest.
On Tue, Aug 16, 2011 at 11:24 AM, Anssi Kääriäinen
wrote:
> There is the question if one should be allowed to tune the *_page_costs at
> all. If I am not missing something, it is possible to detect the correct
> values programmatically and they do not change if you do not change the
> hardware. Ca
Excerpts from Magnus Hagander's message of vie sep 23 11:31:37 -0300 2011:
>
> On Fri, Sep 23, 2011 at 15:55, Alvaro Herrera
> wrote:
> > This seems strange to me. Why not have a second option to let the user
> > indicate the desired SSL verification?
> >
> > sslmode=disable/allow/prefer/requi
On Fri, Sep 9, 2011 at 11:28 PM, Peter Geoghegan wrote:
> It's very difficult or impossible to anticipate how effective the tool
> will be in practice, but when you consider that it works and does not
> produce false positives for the first 3 real-world cases tested, it
> seems reasonable to assum
On Friday 23 Sep 2011 15:42:48 Robert Haas wrote:
> On Wed, Sep 21, 2011 at 12:19 PM, Andres Freund wrote:
> >/*
> > * We also disallow data-modifying WITH in a cursor. (This could
> > be * allowed, but the semantics of when the updates occur might be *
> > surprising.)
> >
On Fri, Sep 23, 2011 at 10:37 AM, Thom Brown wrote:
> Couldn't this come under tablespace changes then? After all the
> use-case stated would require a separate tablespace, and you could do
> something like:
>
> CREATE VOLATILE TABLESPACE drive_made_of_wax_left_in_the_sun LOCATION
> '/mnt/ramdisk
On Fri, Sep 23, 2011 at 10:54 AM, Robert Haas wrote:
> CREATE TABLESPACE now_you_see_me_now_you_dont LOCATION
> '/mnt/highly_reliable_san' VOLATILE LOCATION '/mnt/ramdisk';
>
> All forks of temporary relations, and all non-_init forks of
> non-temporary relations, could be stored in the VOLATILE L
On Fri, Sep 23, 2011 at 10:53 AM, Andres Freund wrote:
> One could argue that its a easier to implement it using a wCTE because the
> query will be simply materialize the query upfront.
> That makes handling the case where somebody fetches 3 tuples from a query
> updating 10 easier.
>
> Thats a bi
On Thu, Sep 22, 2011 at 10:45 PM, Jeff Davis wrote:
> + for (i = 0; i < num_items; ++i)
> + /* do something with q->items[i] */
> +
> +This code turns out to be unsafe, because the writer might increment
> +q->num_items before it finishes storing the new item into the
> appropriate slot.
>> But on the standby its size is the old one (thus, it seems, that the size
>> changed after the rsync transfer and before the pg_stop_backup() was
>> called):
> Now that seems pretty weird - I don't think that file should ever shrink.
It seems, I was not clear in my last example. The pg_clog fi
On 23 September 2011 15:56, Robert Haas wrote:
> On Fri, Sep 23, 2011 at 10:54 AM, Robert Haas wrote:
>> CREATE TABLESPACE now_you_see_me_now_you_dont LOCATION
>> '/mnt/highly_reliable_san' VOLATILE LOCATION '/mnt/ramdisk';
>>
>> All forks of temporary relations, and all non-_init forks of
>> non
On tis, 2011-09-20 at 16:38 -0400, Robert Haas wrote:
> For now, I think we're best off not changing the terminology, and
> confining the remit of this patch to (a) turning all of the existing
> recovery.conf parameters into GUCs and (b) replacing recovery.conf
> with a sentinel file a sentinel fil
On Fri, Sep 23, 2011 at 4:41 AM, Heikki Linnakangas
wrote:
>> Unfortunately, it's impossible, because the error message "Could not read
>> from file "pg_clog/0001" at offset 32768: Success" is shown (and startup
>> aborted) before the turn for "redo starts at" message arrives.
>
> It looks to me
Excerpts from Linas Virbalas's message of vie sep 23 09:47:20 -0300 2011:
> On 9/23/11 12:05 PM, "Heikki Linnakangas"
> wrote:
> But on the standby its size is the old one (thus, it seems, that the size
> changed after the rsync transfer and before the pg_stop_backup() was
> called):
>
> ls -l
On Sep 23, 2011 5:59 PM, "Alvaro Herrera"
wrote:
>
>
> Excerpts from Linas Virbalas's message of vie sep 23 09:47:20 -0300 2011:
> > On 9/23/11 12:05 PM, "Heikki Linnakangas"
> > wrote:
>
> > But on the standby its size is the old one (thus, it seems, that the
size
> > changed after the rsync tra
Hi,
On Wednesday 21 Sep 2011 16:44:30 Linas Virbalas wrote:
> 2011-09-21 13:41:05 CEST DETAIL: Could not read from file "pg_clog/0001"
> at offset 32768: Success.
Any chance you can attach gdb to the startup process and provide a backtrace
from the place where this message is printed?
Greetings
On Tue, Sep 20, 2011 at 5:23 PM, Tom Lane wrote:
> Simon Riggs writes:
>> I sympathise with this view, to an extent.
>
>> If people want to put all parameters in one file, they can do so. So +1 to
>> that.
>
>> Should they be forced to adopt that new capability by us deliberately
>> breaking the
On 09/20/2011 09:23 AM, Tom Lane wrote:
Simon Riggs writes:
I sympathise with this view, to an extent.
If we do an automatic include of recovery.conf first, then follow by
reading postgresql,conf then we will preserve the old as well as
allowing the new.
I don't buy this argument at all
On Tue, Aug 30, 2011 at 6:38 AM, Pavan Deolasee
wrote:
> Yeah. If we don't know the status of the vacuum that collected the
> line pointer and marked it vacuum-dead, the next vacuum will pick it
> up again and stamp it with its own generation number.
I'm still not really comfortable with the hand
> I'm OK with the proposed behavior change and I agree that it's
> probably what people want, but I am awfully suspicious that those
> extra casts are going to break something you haven't thought about.
> It might be worth posting a rough version first just to see if I (or
> someone else) can brea
On 23.09.2011 19:03, Magnus Hagander wrote:
On Sep 23, 2011 5:59 PM, "Alvaro Herrera"
wrote:
Excerpts from Linas Virbalas's message of vie sep 23 09:47:20 -0300 2011:
On 9/23/11 12:05 PM, "Heikki Linnakangas"
wrote:
But on the standby its size is the old one (thus, it seems, that the
si
On Fri, Sep 23, 2011 at 11:43 AM, Aidan Van Dyk wrote:
> On Fri, Sep 23, 2011 at 4:41 AM, Heikki Linnakangas
> wrote:
>
>>> Unfortunately, it's impossible, because the error message "Could not read
>>> from file "pg_clog/0001" at offset 32768: Success" is shown (and startup
>>> aborted) before th
On Sep23, 2011, at 18:03 , Magnus Hagander wrote:
> On Sep 23, 2011 5:59 PM, "Alvaro Herrera" wrote:
> > Sounds like rsync is caching the file size at the start of the run, and
> > then copying that many bytes, ignoring the growth that occurred after it
> > started.
>
> That pretty much matches w
On Sep23, 2011, at 18:45 , Robert Haas wrote:
> Ah. I think you are right - Heikki made the same point. Maybe some
> of the stuff that happens just after this comment:
>
>/*
> * Initialize for Hot Standby, if enabled. We won't let backends in
> * yet, not until we've reac
Simon,
> There are many. Tools I can name include pgpool, 2warm, PITRtools, but
> there are also various tools from Sun, an IBM reseller I have
> forgotten the name of, OmniTI and various other backup software
> providers. Those are just the ones I can recall quickly. We've
> encouraged people to
On 23.09.2011 19:49, Florian Pflug wrote:
On Sep23, 2011, at 18:45 , Robert Haas wrote:
Ah. I think you are right - Heikki made the same point. Maybe some
of the stuff that happens just after this comment:
/*
* Initialize for Hot Standby, if enabled. We won't let backends in
On Fri, Sep 23, 2011 at 12:37 PM, Josh Berkus wrote:
>> I'm OK with the proposed behavior change and I agree that it's
>> probably what people want, but I am awfully suspicious that those
>> extra casts are going to break something you haven't thought about.
>> It might be worth posting a rough ve
On Fri, Sep 23, 2011 at 12:51 PM, Josh Berkus wrote:
> I'm happy to make upgrades easier, but I want a path which eventually
> ends in recovery.conf going away. It's a bad API, confuses our users,
> and is difficult to support and maintain.
I agree.
GUC = Grand Unified Configuration, but recove
One idea:
col like 'foo%' could be translated to col >= 'foo' and col <= foo || 'zzz' ,
where 'z' is the largest possible character. This should be good enough for
calculating stats.
How to find such a character, i do not know.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.
On Thu, Sep 1, 2011 at 12:18 PM, Josh Berkus wrote:
> On 8/31/11 12:15 PM, Merlin Moncure wrote:
>> An out of process, autonomous transaction type implementation should
>> probably not sit under stored procedures for a number of reasons --
>> mainly that it's going to expose too many implementatio
On Fri, Sep 23, 2011 at 11:36 AM, Thom Brown wrote:
> On 23 September 2011 15:56, Robert Haas wrote:
>> On Fri, Sep 23, 2011 at 10:54 AM, Robert Haas wrote:
>>> CREATE TABLESPACE now_you_see_me_now_you_dont LOCATION
>>> '/mnt/highly_reliable_san' VOLATILE LOCATION '/mnt/ramdisk';
>>>
>>> All for
On Fri, Sep 23, 2011 at 12:58 PM, Heikki Linnakangas
wrote:
> There are pretty clear rules on what state clog can be in. When you launch
> postmaster in a standby:
>
> * Any clog preceding the nextXid from the checkpoint record we start
> recovery from, must either be valid, or the clog file must
On Mon, Sep 19, 2011 at 4:36 PM, Dan McGee wrote:
> [ patch ]
I suppose it's Tom who really needs to comment on this, but I'm not
too enthusiastic about this approach. Duplicating the Linux kernel
calculation into our code means that we could drift if the formula
changes again.
I like Tom's pre
On 23 September 2011 15:46, Robert Haas wrote:
> I'm not opposed to adding something like this, but I think it needs to
> either be tied into the actual running of the script, or have a lot
> more documentation than it does now, or both. I am possibly stupid,
> but I can't understand from reading
On Mon, Sep 12, 2011 at 5:45 AM, Kohei KaiGai wrote:
> The attached patch is a portion that we splitted off when we added
> pg_shseclabel system catalog.
>
> It enables the control/sepgsql to assign security label on pg_database
> objects that are utilized as a basis to compute a default security
On Sep23, 2011, at 17:46 , Peter Eisentraut wrote:
> On tis, 2011-09-20 at 16:38 -0400, Robert Haas wrote:
>> For now, I think we're best off not changing the terminology, and
>> confining the remit of this patch to (a) turning all of the existing
>> recovery.conf parameters into GUCs and (b) repla
On Thu, Sep 22, 2011 at 11:31 AM, Robert Haas wrote:
> On Thu, Sep 22, 2011 at 11:25 AM, Thom Brown wrote:
>> s/visca-versa/vice-versa/
>> s/laods/loads/
>
> Fixed. v4 attached.
Since it seems like people are fairly happy with this now, I've gone
ahead and committed this version. I suspect the
On Mon, Sep 12, 2011 at 3:31 PM, Kohei KaiGai wrote:
> I updated the patches of fix-leaky-view problem, according to the
> previous discussion.
> The "NOLEAKY" option was replaced by "LEAKPROOF" option, and several
> regression
> test cases were added. Rest of stuffs are unchanged.
You have a le
Josh,
>> There are many. Tools I can name include pgpool, 2warm, PITRtools, but
>> there are also various tools from Sun, an IBM reseller I have
>> forgotten the name of, OmniTI and various other backup software
>> providers. Those are just the ones I can recall quickly. We've
>> encouraged people
> I'm not sure what you mean by "not deal with" but part of pgpool-II's
> functionality assumes that we can easily generate recovery.conf. If
> reconf.conf is integrated into postgresql.conf, we need to edit
> postgresql.conf, which is a little bit harder than generating
> recovery.conf, I think.
72 matches
Mail list logo
