2012/6/5 Tom Lane :
> Florian Pflug writes:
>> On Jun4, 2012, at 18:38 , Kohei KaiGai wrote:
>>> 2012/6/4 Florian Pflug :
Without something like RLSBYPASS, the DBA needs to have intimate
knowledge about the different RLS policies to e.g. guarantee that his
backups aren't missing cru
On Fri, May 25, 2012 at 7:56 PM, Fujii Masao wrote:
> On Thu, May 24, 2012 at 4:52 AM, Magnus Hagander wrote:
>> On Wed, May 23, 2012 at 8:11 PM, Fujii Masao wrote:
>>> On Tue, May 22, 2012 at 11:04 PM, Robert Haas wrote:
On Mon, May 14, 2012 at 2:24 PM, Fujii Masao wrote:
> On Fri, M
On Jun5, 2012, at 10:22 , Kohei KaiGai wrote:
> 2012/6/5 Tom Lane :
>> I suspect that KaiGai-san's objection basically comes down to not
>> wanting to have what amounts to a backdoor in RLS policies. However,
>> what Florian is saying is that you have to have a backdoor anyway,
>> unless you'd lik
2012/6/5 Florian Pflug :
> On Jun5, 2012, at 10:22 , Kohei KaiGai wrote:
>> 2012/6/5 Tom Lane :
>>> I suspect that KaiGai-san's objection basically comes down to not
>>> wanting to have what amounts to a backdoor in RLS policies. However,
>>> what Florian is saying is that you have to have a backd
On Tue, Jun 5, 2012 at 1:01 AM, Tom Lane wrote:
> Jim Nasby writes:
>> On 5/27/12 2:54 PM, Euler Taveira wrote:
>>> On 27-05-2012 10:45, Fujii Masao wrote:
OK, let me propose another approach: add pg_size_pretty(int).
>
>>> I wouldn't like to add another function but if it solves both proble
On Jun5, 2012, at 11:43 , Kohei KaiGai wrote:
> 2012/6/5 Florian Pflug :
>> What's to be gained by that? Once there's *any* way to bypass a RLS
>> policy, you'll have to deal with the plan invalidation issues you
>> mentioned anyway. ISTM that complexity-wide, you don't save much by not
>> having R
Right now, pg_receivexlog sets:
replymsg->write = InvalidXLogRecPtr;
replymsg->flush = InvalidXLogRecPtr;
replymsg->apply = InvalidXLogRecPtr;
when it sends it's status updates.
I'm thinking it sohuld set replymsg->write = bl
2012/6/5 Florian Pflug :
> On Jun5, 2012, at 11:43 , Kohei KaiGai wrote:
>> 2012/6/5 Florian Pflug :
>>> What's to be gained by that? Once there's *any* way to bypass a RLS
>>> policy, you'll have to deal with the plan invalidation issues you
>>> mentioned anyway. ISTM that complexity-wide, you don
Magnus Hagander writes:
> On Tue, Jun 5, 2012 at 1:01 AM, Tom Lane wrote:
>> Assuming that's how 9.2 ships, we might as well wait to see if there
>> are any real complaints from the field before we decide whether any
>> changing is needed.
> We could add it to the catalog without forcing an init
I got this last night in a perfectly standard build of HEAD:
*** /home/tgl/pgsql/src/test/regress/expected/sanity_check.out Thu Jan 12
14:06:14 2012
--- /home/tgl/pgsql/src/test/regress/results/sanity_check.out Mon Jun 4
20:28:39 2012
***
*** 1,4
--- 1,5
VACUUM;
+ WAR
On Tue, Jun 5, 2012 at 5:32 PM, Magnus Hagander wrote:
> It contains a number of unrelated changes of %m -> %s - what's the
> motivation for those?
%m in fprintf() is glibc extension according to man page, so it's not portable
and should not be used, I think.
We discussed this before and reached
On Tue, Jun 5, 2012 at 3:36 PM, Fujii Masao wrote:
> On Tue, Jun 5, 2012 at 5:32 PM, Magnus Hagander wrote:
>> It contains a number of unrelated changes of %m -> %s - what's the
>> motivation for those?
>
> %m in fprintf() is glibc extension according to man page, so it's not portable
> and shoul
In reference to:
http://www.postgresql.org/docs/devel/static/continuous-archiving.html
I would like to see that page changed to list pg_basebackup as the
"default" way of doing base backups, and then list the "manual way" as
an option if you need more flexibility.
The reason being that for the ma
Magnus Hagander writes:
> On Tue, Jun 5, 2012 at 3:36 PM, Fujii Masao wrote:
>> We discussed this before and reached consensus not to use %m :)
>> http://archives.postgresql.org/pgsql-hackers/2011-01/msg01674.php
> :-) there goes my memory.
> That said, we're using %m in a fairly large number o
On Tue, Jun 5, 2012 at 8:01 AM, Tom Lane wrote:
> Jim Nasby writes:
>> On 5/27/12 2:54 PM, Euler Taveira wrote:
>>> On 27-05-2012 10:45, Fujii Masao wrote:
OK, let me propose another approach: add pg_size_pretty(int).
>
>>> I wouldn't like to add another function but if it solves both proble
On 5 June 2012 14:43, Magnus Hagander wrote:
> In reference to:
> http://www.postgresql.org/docs/devel/static/continuous-archiving.html
>
> I would like to see that page changed to list pg_basebackup as the
> "default" way of doing base backups, and then list the "manual way" as
> an option if you
On Tuesday, June 05, 2012 03:32:08 PM Tom Lane wrote:
> I got this last night in a perfectly standard build of HEAD:
>
> *** /home/tgl/pgsql/src/test/regress/expected/sanity_check.outThu Jan
> 12
> 14:06:14 2012 ---
> /home/tgl/pgsql/src/test/regress/results/sanity_check.out Mon Jun
Is everyone ready for me to run pgindent? We are nearing the first
commit-fest (June 15) and will have to branch the git tree soon.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
Andres Freund writes:
> On Tuesday, June 05, 2012 03:32:08 PM Tom Lane wrote:
>> I got this last night in a perfectly standard build of HEAD:
>> + WARNING: page is not marked all-visible but visibility map bit is set in
>> relation "pg_db_role_setting" page 0 --
> I have seen that twice just yes
Bruce Momjian writes:
> Is everyone ready for me to run pgindent? We are nearing the first
> commit-fest (June 15) and will have to branch the git tree soon.
Also, we should do the pgindent run well before the commitfest, so that
authors of pending patches have time to rebase their patches in ca
On Tue, Jun 05, 2012 at 10:21:14AM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > Is everyone ready for me to run pgindent? We are nearing the first
> > commit-fest (June 15) and will have to branch the git tree soon.
>
> Also, we should do the pgindent run well before the commitfest, so tha
On Tue, Jun 5, 2012 at 10:39 PM, Magnus Hagander wrote:
> On Tue, Jun 5, 2012 at 3:36 PM, Fujii Masao wrote:
>> On Tue, Jun 5, 2012 at 5:32 PM, Magnus Hagander wrote:
>>> You also removed the "safeguard" of always sleeping at least 1 second
>>> - should we keep some level of safeguard there, eve
On Tue, Jun 5, 2012 at 9:53 PM, Magnus Hagander wrote:
> Right now, pg_receivexlog sets:
> replymsg->write = InvalidXLogRecPtr;
> replymsg->flush = InvalidXLogRecPtr;
> replymsg->apply = InvalidXLogRecPtr;
>
> when it sends it's
On Tue, Jun 5, 2012 at 4:28 PM, Fujii Masao wrote:
> On Tue, Jun 5, 2012 at 10:39 PM, Magnus Hagander wrote:
>> On Tue, Jun 5, 2012 at 3:36 PM, Fujii Masao wrote:
>>> On Tue, Jun 5, 2012 at 5:32 PM, Magnus Hagander wrote:
You also removed the "safeguard" of always sleeping at least 1 secon
On Tue, Jun 5, 2012 at 4:42 PM, Fujii Masao wrote:
> On Tue, Jun 5, 2012 at 9:53 PM, Magnus Hagander wrote:
>> Right now, pg_receivexlog sets:
>> replymsg->write = InvalidXLogRecPtr;
>> replymsg->flush = InvalidXLogRecPtr;
>> re
Magnus Hagander wrote:
> In reference to:
>
http://www.postgresql.org/docs/devel/static/continuous-archiving.html
>
> I would like to see that page changed to list pg_basebackup as the
> "default" way of doing base backups, and then list the "manual
> way" as an option if you need more flexibilit
On Jun5, 2012, at 15:07 , Kohei KaiGai wrote:
> 2012/6/5 Florian Pflug :
>> On Jun5, 2012, at 11:43 , Kohei KaiGai wrote:
>>> I think it does not require to add a mechanism to invalidate
>>> prepared-statement, because all the checks are applied on
>>> executor stage. And these functions can be sta
Tom Lane wrote:
http://archives.postgresql.org/pgsql-hackers/2012-01/msg01241.php
> OK, here's an updated version of the patch.
I was on vacation after PGCon and just got back to the office
yesterday, so I have just now been able to check on the status of
our testing of this after being asked
2012/6/5 Florian Pflug :
> On Jun5, 2012, at 15:07 , Kohei KaiGai wrote:
>> 2012/6/5 Florian Pflug :
>>> On Jun5, 2012, at 11:43 , Kohei KaiGai wrote:
I think it does not require to add a mechanism to invalidate
prepared-statement, because all the checks are applied on
executor stage
On 24 May 2012 19:45, Robert Haas wrote:
> On Wed, May 23, 2012 at 2:28 PM, Fujii Masao wrote:
>> On Sat, Dec 31, 2011 at 10:34 PM, Simon Riggs wrote:
>>> Send new protocol keepalive messages to standby servers.
>>> Allows streaming replication users to calculate transfer latency
>>> and apply d
On 23 March 2012 14:03, Fujii Masao wrote:
> On Thu, Mar 22, 2012 at 12:56 AM, Robert Haas wrote:
>> On Wed, Feb 29, 2012 at 5:48 AM, Fujii Masao wrote:
>>> Hi,
>>>
>>> In streaming replication, after failover, new master might have lots
>>> of un-applied
>>> WAL files with old timeline ID. They
Simon Riggs writes:
> 1. Functions - it's fairly easy to add some functions. Initially, we
> can add them as a contrib module, then if an initdb is forced
> elsewhere we can include them in the main server.
While I dislike the idea of a forced initdb at this point, adding a
contrib module that we
On 3 June 2012 19:07, Jeff Janes wrote:
> On Thu, May 31, 2012 at 5:04 AM, Simon Riggs wrote:
>> On 30 May 2012 12:10, Heikki Linnakangas
>> wrote:
>>
>>> Hmm, we do this in smgrDoPendingDeletes:
>>>
>>> for (i = 0; i <= MAX_FORKNUM; i++)
>>> {
>>> smgrdounlink(srel, i, false);
>>> }
>>>
On 5 June 2012 22:18, Tom Lane wrote:
> Simon Riggs writes:
>> 1. Functions - it's fairly easy to add some functions. Initially, we
...
> How badly do we really need these functions right now?
We need a better way of taking these decisions than just black/white
yes/no. It makes the decision more
Simon Riggs writes:
> Can't we have a trial branch where quarantined patches can be placed
> on trial for inclusion in main release?
[ shrug... ] You're welcome to publish a personal repo somewhere with
such things. But even if we did that in the master repo, it would have
approximately nothing
On Jun5, 2012, at 22:33 , Kohei KaiGai wrote:
> 2012/6/5 Florian Pflug :
>> I can live with any behaviour, as long as it doesn't depends on details
>> of the query plan. My vote would be for always using the role which was
>> active at statement creation time (i.e. at PREPARE/DECLARE time) for
>> R
On 5 June 2012 23:55, Tom Lane wrote:
> Simon Riggs writes:
>> Can't we have a trial branch where quarantined patches can be placed
>> on trial for inclusion in main release?
>
> [ shrug... ] You're welcome to publish a personal repo somewhere with
> such things. But even if we did that in the
Hello list,
I have been playing with the URI connection strings in the bleeding
edge 9.2 and noticed an inconsistency with the old connection string
behavior:
$ psql 'host=/var/run/postgresql dbname=postgres arbitrary=property'
psql: invalid connection option "arbitrary"
(psql exits with an erro
Daniel Farina writes:
> I have been playing with the URI connection strings in the bleeding
> edge 9.2 and noticed an inconsistency with the old connection string
> behavior:
> $ psql 'host=/var/run/postgresql dbname=postgres arbitrary=property'
> psql: invalid connection option "arbitrary"
> vs
On Tue, Jun 5, 2012 at 6:43 PM, Tom Lane wrote:
> Daniel Farina writes:
>> I have been playing with the URI connection strings in the bleeding
>> edge 9.2 and noticed an inconsistency with the old connection string
>> behavior:
>
>> $ psql 'host=/var/run/postgresql dbname=postgres arbitrary=prope
Hi All,
I am playing around with 9.2Beta1 and the smlar extension that was presented
at pgcon. Looks like a lot of great work has gone into both - so thanks to
everyone for all the great work.
I did run into an issue while creating a GIST index using the _text_sml_ops.
I am getting "ERROR: fai
Daniel Farina writes:
> On Tue, Jun 5, 2012 at 6:43 PM, Tom Lane wrote:
>> We already have a mechanism (PGOPTIONS, aka options=foo) for passing
>> through settings that will not be interpreted by libpq. I think that
>> stuff that is meant to be handled at the server end should be confined
>> to
"mark" writes:
> I am playing around with 9.2Beta1 and the smlar extension that was presented
> at pgcon. Looks like a lot of great work has gone into both - so thanks to
> everyone for all the great work.
> I did run into an issue while creating a GIST index using the _text_sml_ops.
> I am getti
On Tue, Jun 5, 2012 at 8:16 PM, Tom Lane wrote:
> The main point here
> IMO is that libpq should have some way of telling parameters-for-the-
> server from things that are meant to be its own parameters.
I agree with this.
>> If that is the case, is there a convention we can use to separate the
Daniel Farina writes:
> Would these hypothetical extension-pairs be using the "options" device
> at startup time, or something else (possibly brand new)?
I'd argue for just translating them into "options", at least in the
near term. If they use some new mechanism then they would only work
with n
On Tue, Jun 5, 2012 at 9:02 PM, Tom Lane wrote:
> Daniel Farina writes:
>> Would these hypothetical extension-pairs be using the "options" device
>> at startup time, or something else (possibly brand new)?
>
> I'd argue for just translating them into "options", at least in the
> near term. If th
On 5 June 2012 23:55, Tom Lane wrote:
>> Plus. if we have extensions, why does adding a function need to force
>> an initdb?? Why don't we use our own infrastructure?
>
> I thought I already pointed that out, but: we have *extensions*. What
> we don't have is a convenient method of dealing with
47 matches
Mail list logo
