On 05.06.2012 09:45, Alexander Korotkov wrote:
On Tue, Jun 5, 2012 at 2:00 AM, Alexander Korotkovwrote:
On Mon, May 28, 2012 at 1:46 AM, Alexander Korotkovwrote:
On Sat, May 26, 2012 at 12:33 AM, Heikki Linnakangas<
heikki.linnakan...@enterprisedb.com> wrote:
Alexander, do you still have t
On Tue, Jun 5, 2012 at 2:00 AM, Alexander Korotkov wrote:
> On Mon, May 28, 2012 at 1:46 AM, Alexander Korotkov
> wrote:
>
>> On Sat, May 26, 2012 at 12:33 AM, Heikki Linnakangas <
>> heikki.linnakan...@enterprisedb.com> wrote:
>>
>>> Alexander, do you still have the test environments and data ly
On Fri, Mar 23, 2012 at 11:03:27PM +0900, Fujii Masao wrote:
> > On Wed, Feb 29, 2012 at 5:48 AM, Fujii Masao wrote:
> >> In streaming replication, after failover, new master might have lots
> >> of un-applied
> >> WAL files with old timeline ID. They are the WAL files which were recycled
> >> as
Introduction:
=
A lot of progress has been made on the checksums issue, with Simon's
excellent work beginning to gain consensus:
http://archives.postgresql.org/message-id/CA
+u5nmkw_gbs6qq_y8-rjgl1v7mvw2hwbhartb8lojhnpfx...@mail.gmail.com
For the purposes of this p
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 crucial information, or that t
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 crucial information, or that the replication
>> system inde
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 problems... +1.
> FWIW, I would argue that the case of pg_siz
On Mon, May 28, 2012 at 1:46 AM, Alexander Korotkov wrote:
> On Sat, May 26, 2012 at 12:33 AM, Heikki Linnakangas <
> heikki.linnakan...@enterprisedb.com> wrote:
>
>> Alexander, do you still have the test environments and data lying around
>> that you used for GiST buffering testing last summer? C
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).
If we do this, all usability and performance problems will be solved.
I wouldn't like to add another function but if it solves both problems... +1.
F
On 5/26/12 10:16 PM, Pavel Stehule wrote:
My idea is secure to separator - because separator is just space and
new line and these symbols are escaped.
ISTM it'd be a really good idea to support something other than space, since
presumably that'd be trivial.
I'm not a fan of supporting the arr
On Sat, Jun 2, 2012 at 12:01 PM, Michael Nolan wrote:
> On 6/2/12, Tom Lane wrote:
>> Robert Haas writes:
>>> On the other hand, if we simply say "PostgreSQL computes the
>>> replication delay by subtracting the time at which the WAL was
>>> generated, as recorded on the master, from the time at
2012/6/4 Tom Lane :
> Kohei KaiGai writes:
>> Here is two problems around RLSBYPASS. The first is we have
>> no idea to handle invalidation of prepared-statement when current
>> user is switched, right now.
>
> How is that specifically the fault of RLSBYPASS? *Any* of the schemes
> you're proposi
Greg Sabino Mullane writes:
> We have a 8.3.18 system (yes, the same one from the previous
> thread, finally upgraded!) that gave us this error yesterday:
> ERROR: index "pg_class_oid_index" is not a btree
That means you got bogus data while reading the metapage.
I'm beginning to wonder about
Kohei KaiGai writes:
> Here is two problems around RLSBYPASS. The first is we have
> no idea to handle invalidation of prepared-statement when current
> user is switched, right now.
How is that specifically the fault of RLSBYPASS? *Any* of the schemes
you're proposing for inlined RLS checks will
On Mon, Jun 4, 2012 at 10:42 AM, Ants Aasma wrote:
> On Mon, Jun 4, 2012 at 6:38 PM, Merlin Moncure wrote:
>> On Mon, Jun 4, 2012 at 10:17 AM, Merlin Moncure wrote:
>>> What happens (in the very unlikely, but possible case?) if another
>>> backend races to the buffer you've pointed at with 'vict
2012/6/4 Florian Pflug :
> On Jun4, 2012, at 17:38 , Kohei KaiGai wrote:
>> I'm worry about future maintenance issues, once we have
>> RLSBYPASS permission or something user visible…
>
> I fear that without a generic way to disable RLS regardless which
> RLS policy function is in effect, we're crea
We have a 8.3.18 system (yes, the same one from the previous
thread, finally upgraded!) that gave us this error yesterday:
ERROR: index "pg_class_oid_index" is not a btree
It seems like this happened from just a normal SELECT query, and did
not occur again (and this is a very busy system) The
On Mon, Jun 4, 2012 at 6:53 PM, Magnus Hagander wrote:
> No, it's more a "there's no reason to do that". I don't think it
> should necessarily be an actual problem.
Ok, good to know.
> In your case the missing piece of information is why was there a
> timeline switch? pg_basebackup shouldn't cau
On Jun4, 2012, at 17:38 , Kohei KaiGai wrote:
> I'm worry about future maintenance issues, once we have
> RLSBYPASS permission or something user visible…
I fear that without a generic way to disable RLS regardless which
RLS policy function is in effect, we're creating a huge maintenance
issue for
On Mon, Jun 4, 2012 at 5:48 PM, Ants Aasma wrote:
> On Mon, Jun 4, 2012 at 6:20 PM, Fujii Masao wrote:
>> On Mon, Jun 4, 2012 at 11:25 PM, Ants Aasma wrote:
>>> On Thu, Sep 29, 2011 at 11:30 PM, Magnus Hagander
>>> wrote:
> it doesn't say that is not possible to use this for a standby
On Mon, Jun 4, 2012 at 6:20 PM, Fujii Masao wrote:
> On Mon, Jun 4, 2012 at 11:25 PM, Ants Aasma wrote:
>> On Thu, Sep 29, 2011 at 11:30 PM, Magnus Hagander
>> wrote:
it doesn't say that is not possible to use this for a standby
server... probably that's why i get the error i put a re
On Mon, Jun 4, 2012 at 6:38 PM, Merlin Moncure wrote:
> On Mon, Jun 4, 2012 at 10:17 AM, Merlin Moncure wrote:
>> What happens (in the very unlikely, but possible case?) if another
>> backend races to the buffer you've pointed at with 'victim'? It looks
>> like multiple backends share the clock
2012/6/4 Robert Haas :
> On Sat, Jun 2, 2012 at 12:58 AM, Kohei KaiGai wrote:
>> 2012/6/1 Robert Haas :
>>> On Thu, May 31, 2012 at 3:52 PM, Kohei KaiGai wrote:
It may be an option to separate the case into two; a situation to execute
the given query immediately just after optimization
On Mon, Jun 4, 2012 at 10:17 AM, Merlin Moncure wrote:
> What happens (in the very unlikely, but possible case?) if another
> backend races to the buffer you've pointed at with 'victim'? It looks
> like multiple backends share the clock sweep now, but don't you need
> to need an extra test to ens
On Mon, Jun 4, 2012 at 11:25 PM, Ants Aasma wrote:
> On Thu, Sep 29, 2011 at 11:30 PM, Magnus Hagander wrote:
>>> it doesn't say that is not possible to use this for a standby
>>> server... probably that's why i get the error i put a recovery.conf
>>> after pg_basebackup finished... maybe we can
On Mon, Jun 4, 2012 at 9:20 AM, Ants Aasma wrote:
> On Mon, Jun 4, 2012 at 5:12 PM, Robert Haas wrote:
>> Note sure about the rest of this patch, but this part is definitely bogus:
>>
>> +#if !defined(pg_atomic_fetch_and_set)
>> +#define pg_atomic_fetch_and_set(dst, src, value) \
>> + do {
On Sat, Jun 2, 2012 at 12:58 AM, Kohei KaiGai wrote:
> 2012/6/1 Robert Haas :
>> On Thu, May 31, 2012 at 3:52 PM, Kohei KaiGai wrote:
>>> It may be an option to separate the case into two; a situation to execute
>>> the given query immediately just after optimization and never reused,
>>> and oth
On Thu, Sep 29, 2011 at 11:30 PM, Magnus Hagander wrote:
>> it doesn't say that is not possible to use this for a standby
>> server... probably that's why i get the error i put a recovery.conf
>> after pg_basebackup finished... maybe we can say that more loudly?
>
> The idea is, if you use it wit
On Mon, Jun 4, 2012 at 5:12 PM, Robert Haas wrote:
> Note sure about the rest of this patch, but this part is definitely bogus:
>
> +#if !defined(pg_atomic_fetch_and_set)
> +#define pg_atomic_fetch_and_set(dst, src, value) \
> + do { S_LOCK(&dummy_spinlock); \
> + dst = src; \
> +
On Sat, Jun 02, 2012 at 05:10:03PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > On Fri, Jun 01, 2012 at 09:52:59AM -0400, Tom Lane wrote:
> >> It seems that pg_upgrade needs a check to make sure that the bootstrap
> >> superuser is named the same in old and new clusters.
>
> > The attached
On Fri, Jun 1, 2012 at 9:55 PM, Ants Aasma wrote:
> On Sat, Jun 2, 2012 at 1:48 AM, Merlin Moncure wrote:
>> Buffer pins aren't a cache: with a cache you are trying to mask a slow
>> operation (like a disk i/o) with a faster such that the amount of slow
>> operations are minimized. Buffer pins h
Hi all,
Recently I was writing an application to implement automated failover with
env: Two 2008 R2 servers, Network area storage, asynchronous replication,
WAL archive on primary enabled.
Is there any way to avoid starting standby server always from base backup in
automated failover. I see the d
On tis, 2012-05-29 at 22:31 +0200, Magnus Hagander wrote:
> Yeah, good arguments all around, i agree too :-) Next question is -
> suggestions for naming of said paramter?
--xlog-method=something? And/or -Xsomething, which would automatically
enable -x?
--
Sent via pgsql-hackers mailing list (p
33 matches
Mail list logo
