Hello,
Il 15/03/12 05:03, Marco Nenciarini ha scritto:
please find attached v4 of the EACH Foreign Key patch (formerly known
also as Foreign Key Array).
Please find attached version v4b which replaces v4 and fixes a bug in
array_replace() and adds further regression tests on array_replace() and
on
the annoying side (and causes some disconcerting sounds to come from my
disk), especially when we _know_ it can be done in 2s.
Anyway, updated patch attached.
Regards,
Jeff Davis
initdb-fsync-20120314.patch.gz
Description: GNU Zip compressed data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On ons, 2012-03-14 at 17:36 -0400, Bruce Momjian wrote:
> Well, I have not had to make major adjustments to pg_upgrade since 9.0,
> meaning the code is almost complete unchanged and does not require
> additional testing for each major release. If we go down the road of
> dumping stats, we will nee
On Wed, Mar 14, 2012 at 12:06:20PM -0400, Robert Haas wrote:
> On Wed, Mar 14, 2012 at 10:22 AM, David Fetter wrote:
> >> I think that instead of inventing new grammar productions and a new
> >> node type for this, you should just reuse the existing productions for
> >> LIKE clauses and then rejec
On Wed, Mar 14, 2012 at 4:39 PM, Andrew Dunstan wrote:
> I've just started looking at the patch, and I'm curious to know why it
> didn't follow the pattern of parallel pg_restore which created a new worker
> for each table rather than passing messages to looping worker threads as
> this appears to
On Wed, Mar 14, 2012 at 2:02 PM, Robert Haas wrote:
> I think we should get rid of die_horribly(), and instead have arrange
> to always clean up AH via an on_exit_nicely hook.
Good. The only exit handler I've seen so far is
pgdump_cleanup_at_exit. If there's no other one, is it okay to remove
all
On Fri, Mar 9, 2012 at 9:16 PM, Joey Adams wrote:
> libpq has functions for escaping values in SQL commands
> (PQescapeStringConn, PQescapeByteaConn, and the new PQescapeLiteral),
> and it supports parameterizing queries with PQexecParams. But it does
> not (to my knowledge) have functions for es
On Wed, Mar 14, 2012 at 9:17 PM, Alvaro Herrera
wrote:
>> > Agreed. But speaking of that, why exactly do we fsync the multixact SLRU
>> > today?
>>
>> Good question. So far, I can't think of a reason. "nextMulti" is critical,
>> but we already fsync it with pg_control. We could delete the oth
On Wed, Mar 14, 2012 at 6:10 PM, Noah Misch wrote:
>> Well, post-release, the cat is out of the bag: we'll be stuck with
>> this whether the performance characteristics are acceptable or not.
>> That's why we'd better be as sure as possible before committing to
>> this implementation that there's
On Wed, Mar 14, 2012 at 9:44 PM, Tom Lane wrote:
> Well, let's please not make the same mistake again of assuming that
> there will never again be any other ideas in this space. IOW, let's
> find a way to shoehorn in an actual compression-method ID value of some
> sort. I don't particularly care
Robert Haas writes:
> On Wed, Mar 14, 2012 at 6:08 PM, Kevin Grittner
> wrote:
>> Doesn't it always start with a header of two int32 values where the
>> first must be smaller than the second? That seems like enough to
>> get traction for an identifiably different header for an alternative
>> com
On Thu, Mar 8, 2012 at 8:40 AM, Robert Haas wrote:
> On Wed, Feb 29, 2012 at 9:39 PM, Fujii Masao wrote:
>>> Do we have an updated patch? Fujii?
>>
>> No. I believe that the author Jim will submit the updated version.
>
> Jim, are you going to submit an updated version?
Hearing no response, I'
I looked into the problem complained of here:
http://archives.postgresql.org/pgsql-bugs/2012-03/msg00016.php
It's not at all specific to custom types; you can exhibit it with
this query in the regression database:
explain select * from
(select 1 as t, unique1 from tenk1 a
union all
select 2 a
On Wed, Mar 14, 2012 at 6:08 PM, Kevin Grittner
wrote:
> Tom Lane wrote:
>> Another not-exactly-trivial requirement is to figure out how to
>> not break on-disk compatibility when installing an alternative
>> compression scheme. In hindsight it might've been a good idea if
>> pglz_compress had w
On Wed, Mar 14, 2012 at 08:26:06PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > Does anyone know how bad the queries will be with only one target?
>
> Bad. That cycle seems like largely a waste of time. About the only
> thing it would do for you is ensure that relpages/reltuples are up to
Excerpts from Noah Misch's message of mié mar 14 19:10:00 -0300 2012:
>
> On Wed, Mar 14, 2012 at 01:23:14PM -0400, Robert Haas wrote:
> > On Tue, Mar 13, 2012 at 11:42 PM, Noah Misch wrote:
> > > More often than that; each 2-member mxid takes 4 bytes in an offsets file
> > > and
> > > 10 bytes
2012/3/14 Tom Lane
>
> Why would you confine it to verbose mode?
Because I did not want to change the current behavior of this psql
command... but...
For most people it won't
> matter, but for people who are using the feature, it seems like
> important information. Per the OP's complaint, it
Bruce Momjian writes:
> Does anyone know how bad the queries will be with only one target?
Bad. That cycle seems like largely a waste of time. About the only
thing it would do for you is ensure that relpages/reltuples are up to
date, which seems like something we could possibly arrange for duri
=?ISO-8859-1?Q?Fabr=EDzio_de_Royes_Mello?= writes:
> The attached patch put VALID UNTIL into attributes column in verbose mode
> like example above.
Why would you confine it to verbose mode? For most people it won't
matter, but for people who are using the feature, it seems like
important inform
On Tue, Mar 13, 2012 at 09:15:52PM -0400, Bruce Momjian wrote:
> On Tue, Mar 13, 2012 at 08:22:51PM -0400, Bruce Momjian wrote:
> > On Tue, Mar 13, 2012 at 05:33:29PM -0500, Kevin Grittner wrote:
> > > Bruce Momjian wrote:
> > >
> > > > What is the target=10 duration? I think 10 is as low as we
>> As you can see, this query generated 1255+1250 = 2505 times block read
>> either from the buffer or the disk. In my understanding the query
>> accesses an index tuple, which will need access to root page and
>> several number of meta pages (I mean index pages they are not either
>> root or leaf
2012/3/14 David Fetter
>
> I don't know how frequently people use VALID UNTIL, but I'm guessing
> it's not terribly often because yours is the first comment about how
> it's not exposed, so I'd tend toward putting it in attributes rather
> than a separate column.
>
>
The attached patch put VALID
On Wed, Mar 14, 2012 at 2:58 PM, Tom Lane wrote:
> Daniel Farina writes:
>> Given that, few I would say have had the traction that LZO and Snappy
>> have had, even though in many respects they are interchangeable in the
>> general trade-off spectrum. The question is: what burden of proof is
>> re
On Wed, Mar 14, 2012 at 5:21 PM, Peter Eisentraut wrote:
> On ons, 2012-03-14 at 17:16 -0400, Robert Haas wrote:
>> If a constraint is NOT ENFORCED, then the query planner presumably
>> won't rely on it for planning purposes
>
> Why do you presume that?
Well, as Tom alludes to, I'm guessing that
On Wed, Mar 14, 2012 at 01:23:14PM -0400, Robert Haas wrote:
> On Tue, Mar 13, 2012 at 11:42 PM, Noah Misch wrote:
> > More often than that; each 2-member mxid takes 4 bytes in an offsets file
> > and
> > 10 bytes in a members file. ?So, more like one fsync per ~580 mxids. ?Note
> > that we alrea
Tom Lane wrote:
> Another not-exactly-trivial requirement is to figure out how to
> not break on-disk compatibility when installing an alternative
> compression scheme. In hindsight it might've been a good idea if
> pglz_compress had wasted a little bit of space on some sort of
> version identi
Daniel Farina writes:
> Given that, few I would say have had the traction that LZO and Snappy
> have had, even though in many respects they are interchangeable in the
> general trade-off spectrum. The question is: what burden of proof is
> required to convince the project that Snappy does not have
Peter Eisentraut writes:
> On ons, 2012-03-14 at 17:16 -0400, Robert Haas wrote:
>> If a constraint is NOT ENFORCED, then the query planner presumably
>> won't rely on it for planning purposes
> Why do you presume that?
What does SQL:2011 say exactly about the semantics of NOT ENFORCED?
Is an i
On Wed, Mar 14, 2012 at 10:40:41PM +0200, Peter Eisentraut wrote:
> On tis, 2012-03-13 at 20:34 -0400, Bruce Momjian wrote:
> > I frankly am worried that if we copy over statistics even in ASCII
> > that don't match what the server expects, it might lead to a crash,
> > which has me back to wanting
Robert Haas writes:
>> Also, when calling the user's procedure from the same place in case of an
>> ANY command trigger or a specific one it's then possible to just hand
>> them over the exact same set of info (object id, name, schema name).
>
> Yes, I think that's an essential property of the sys
On ons, 2012-03-14 at 17:16 -0400, Robert Haas wrote:
> If a constraint is NOT ENFORCED, then the query planner presumably
> won't rely on it for planning purposes
Why do you presume that?
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscriptio
On Wed, Mar 14, 2012 at 5:14 PM, Peter Eisentraut wrote:
> On ons, 2012-03-14 at 16:44 -0400, Tom Lane wrote:
>> On reflection I don't see anything much wrong with the "if you lied
>> about the constraint it's your fault that things broke" position.
>> It seems quite comparable to the fact that we
On ons, 2012-03-14 at 16:44 -0400, Tom Lane wrote:
> On reflection I don't see anything much wrong with the "if you lied
> about the constraint it's your fault that things broke" position.
> It seems quite comparable to the fact that we take the user's
> assertions on faith as to the number and dat
On Wed, Mar 14, 2012 at 4:39 PM, Andrew Dunstan wrote:
> I've just started looking at the patch, and I'm curious to know why it
> didn't follow the pattern of parallel pg_restore which created a new worker
> for each table rather than passing messages to looping worker threads as
> this appears to
On Wed, Mar 14, 2012 at 2:03 PM, Merlin Moncure wrote:
> er, typo: I meant to say: "*non-gpl* lz based..." :-).
Given that, few I would say have had the traction that LZO and Snappy
have had, even though in many respects they are interchangeable in the
general trade-off spectrum. The question is
On Wed, Mar 14, 2012 at 3:43 PM, Andrew Dunstan wrote:
>
>
> On 03/14/2012 04:10 PM, Merlin Moncure wrote:
>>
>> there are plenty of on gpl lz based libraries out there (for example:
>> http://www.fastlz.org/) and always have been. they are all much
>> faster than zlib. the main issue is patents
Excerpts from Andrew Dunstan's message of mié mar 14 17:39:59 -0300 2012:
> pgpipe used to be used in pgstat.c, but that's no longer true in any
> live branch, so it's probably long dead. I'd be inclined to rip it out
> if possible rather than expand its use.
our pgpipe() function is interesti
On Wed, Mar 14, 2012 at 3:29 PM, Jeff Janes wrote:
> I think my analysis is pretty much a re-wording of yours, but I'd
> emphasize that getting the WALWriteLock is bad not just because they
> fight over the lock, but because someone else (probably background wal
> writer) is camping out on the loc
On Wed, Mar 14, 2012 at 04:43:55PM -0400, Andrew Dunstan wrote:
>
>
> On 03/14/2012 04:10 PM, Merlin Moncure wrote:
> >there are plenty of on gpl lz based libraries out there (for example:
> >http://www.fastlz.org/) and always have been. they are all much
> >faster than zlib. the main issue is
On Tue, Mar 13, 2012 at 11:18 PM, Robert Haas wrote:
> On Tue, Mar 13, 2012 at 6:44 PM, Josh Berkus wrote:
>>> That's a speedup of nearly a factor of two, so clearly fsync-related
>>> stalls are a big problem here, even with wal_buffers cranked up
>>> through the ceiling.
>>
>> H. Do you ha
On 03/14/2012 04:44 PM, Tom Lane wrote:
Peter Eisentraut writes:
On ons, 2012-03-14 at 10:27 -0400, Tom Lane wrote:
That opinion seems to me to connect to the recently-posted patch to
make contrib/file_fdw enforce NOT NULL constraints. Should we instead
have the position that constraints de
Peter Eisentraut writes:
> On ons, 2012-03-14 at 10:27 -0400, Tom Lane wrote:
>> That opinion seems to me to connect to the recently-posted patch to
>> make contrib/file_fdw enforce NOT NULL constraints. Should we instead
>> have the position that constraints declared for foreign tables are
>> st
On 03/14/2012 04:10 PM, Merlin Moncure wrote:
there are plenty of on gpl lz based libraries out there (for example:
http://www.fastlz.org/) and always have been. they are all much
faster than zlib. the main issue is patents...you have to be careful
even though all the lz77/78 patents seem to
On 03/13/2012 02:10 PM, Andrew Dunstan wrote:
On 03/13/2012 01:53 PM, Robert Haas wrote:
I tried this actually (patch attached) but then I wanted to test it
and couldn't find anything that used pgpipe() on Windows.
pg_basebackup/pg_basebackup.c is using it but it's in an #ifndef WIN32
and th
On tis, 2012-03-13 at 20:34 -0400, Bruce Momjian wrote:
> I frankly am worried that if we copy over statistics even in ASCII
> that don't match what the server expects, it might lead to a crash,
> which has me back to wanting to speed up vacuumdb.
Why can't we maintain a conversion routine for sta
On ons, 2012-03-14 at 10:27 -0400, Tom Lane wrote:
> That opinion seems to me to connect to the recently-posted patch to
> make contrib/file_fdw enforce NOT NULL constraints. Should we instead
> have the position that constraints declared for foreign tables are
> statements that we can take on fai
On ons, 2012-03-14 at 14:58 +0100, Dimitri Fontaine wrote:
> A colleague came to me to express his surprise about this quite simple
> use case:
>
> =# alter table toto add column user text;
> ERROR: syntax error at or near "user"
> LINE 1: alter table toto add column user text;
>
> Is ther
On Wed, Mar 14, 2012 at 1:06 PM, Daniel Farina wrote:
> For 9.3 at a minimum.
>
> The topic of LZO became mired in doubts about:
>
> * Potential Patents
> * The author's intention for the implementation to be GPL
>
> Since then, Google released "Snappy," also an LZ77-class
> implementation, and it
On Mon, Mar 12, 2012 at 7:16 AM, Robert Haas wrote:
> On Sun, Mar 11, 2012 at 11:51 PM, Fujii Masao wrote:
>> On Sun, Mar 11, 2012 at 12:55 PM, Robert Haas wrote:
>>> I've finally been able to run some more tests of the effect of
>>> adjusting wal_buffers to values higher than 16MB. I ran the t
Excerpts from Tatsuo Ishii's message of mar mar 13 23:29:44 -0300 2012:
> As you can see, this query generated 1255+1250 = 2505 times block read
> either from the buffer or the disk. In my understanding the query
> accesses an index tuple, which will need access to root page and
> several number
On Wed, Mar 14, 2012 at 11:06:16AM -0700, Daniel Farina wrote:
> For 9.3 at a minimum.
>
> The topic of LZO became mired in doubts about:
>
> * Potential Patents
> * The author's intention for the implementation to be GPL
>
> Since then, Google released "Snappy," also an LZ77-class
> implementat
For 9.3 at a minimum.
The topic of LZO became mired in doubts about:
* Potential Patents
* The author's intention for the implementation to be GPL
Since then, Google released "Snappy," also an LZ77-class
implementation, and it has been ported to C (recently, and with some
quirks, like no LICENSE
On Wed, Mar 14, 2012 at 12:34 AM, Joachim Wieland wrote:
>>> If a child terminates without leaving a message, the master will still
>>> detect it and just say "a worker process died unexpectedly" (this part
>>> was actually broken, but now it's fixed :-) )
>>
>> All that may be true, but I still d
On Tue, Mar 13, 2012 at 9:56 AM, Hans-Jürgen Schönig
wrote:
> Here's the cross-col patch against todays master branch.
Please add your patch here, so it doesn't get forgotten:
https://commitfest.postgresql.org/action/commitfest_view/open
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
On Tue, Mar 13, 2012 at 11:42 PM, Noah Misch wrote:
> More often than that; each 2-member mxid takes 4 bytes in an offsets file and
> 10 bytes in a members file. So, more like one fsync per ~580 mxids. Note
> that we already fsync the multixact SLRUs today, so any increase will arise
> from the
On Wed, Mar 14, 2012 at 12:00 PM, Tom Lane wrote:
> David Fetter writes:
>> On Wed, Mar 14, 2012 at 11:29:14AM -0400, Tom Lane wrote:
>>> The posted patch for file_fdw takes the approach of silently
>>> filtering out rows for which they're not true, which is not
>>> obviously the right thing eith
On 14/03/2012 16:47, David Fetter wrote:
> On Wed, Mar 14, 2012 at 11:29:14AM -0400, Tom Lane wrote:
>> David Fetter writes:
>>> On Wed, Mar 14, 2012 at 10:27:28AM -0400, Tom Lane wrote:
Hm. That opinion seems to me to connect to the recently-posted
patch to make contrib/file_fdw enforc
On Wed, Mar 14, 2012 at 10:22 AM, David Fetter wrote:
>> I think that instead of inventing new grammar productions and a new
>> node type for this, you should just reuse the existing productions for
>> LIKE clauses and then reject invalid options during parse analysis.
>
> OK. Should I first merg
David Fetter writes:
> On Wed, Mar 14, 2012 at 11:29:14AM -0400, Tom Lane wrote:
>> The posted patch for file_fdw takes the approach of silently
>> filtering out rows for which they're not true, which is not
>> obviously the right thing either --- quite aside from whether that's
>> a sane semantic
On Wed, Mar 14, 2012 at 11:29:14AM -0400, Tom Lane wrote:
> David Fetter writes:
> > On Wed, Mar 14, 2012 at 10:27:28AM -0400, Tom Lane wrote:
> >> Hm. That opinion seems to me to connect to the recently-posted
> >> patch to make contrib/file_fdw enforce NOT NULL constraints.
> >> Should we inste
2012/3/14 David Fetter
>
> I don't know how frequently people use VALID UNTIL, but I'm guessing
> it's not terribly often because yours is the first comment about how
> it's not exposed, so I'd tend toward putting it in attributes rather
> than a separate column.
>
>
If it's desired I can write a
David Fetter writes:
> On Wed, Mar 14, 2012 at 10:27:28AM -0400, Tom Lane wrote:
>> Hm. That opinion seems to me to connect to the recently-posted
>> patch to make contrib/file_fdw enforce NOT NULL constraints. Should
>> we instead have the position that constraints declared for foreign
>> table
David Fetter writes:
> I didn't do INHERITS because most FDWs won't ever have that concept,
> i.e. aren't PostgreSQL.
What's that have to do with it? Inheritance would be a local
association of tables, having nothing to do with what the remote end is.
IOW, if c inherits from p, that means to sca
Vlad Arkhipov writes:
> Could anyone please explain the behaviour of Postgres in the cases
> below?
I think it has something to do with anytextcat() being mistakenly marked
as volatile, thus preventing flattening of the subquery in the cases
where you don't explicitly coerce the integer to text.
On Wed, Mar 14, 2012 at 11:20:05AM -0300, Euler Taveira de Oliveira wrote:
> Hi,
>
> I have a hard time figuring out why my replication stopped with a message like
>
> FATAL: password authentication failed for user "foo"
>
> in the logs. I thought it was some pg_hba.conf change, a pgpass modifi
2012/3/14 Pavel Stehule :
> 2012/3/14 Dimitri Fontaine :
>> Hi,
>>
>> A colleague came to me to express his surprise about this quite simple
>> use case:
>>
>> =# alter table toto add column user text;
>> ERROR: syntax error at or near "user"
>> LINE 1: alter table toto add column user text;
>>
Tatsuo Ishii writes:
> I have created a 29GB test database by using standard pgbnech -i -s
> 2000. Then I executed:
That means 200 million accounts rows. With integer keys you could
expect to get 200 to 300 keys per index page. Taking the number as 200
for simplicity, we expect 1 million leaf
On 14-03-2012 10:58, Dimitri Fontaine wrote:
> Is there a reason for us not to add an HINT: "user" is a reserved
> keyword or something like that, other than nobody having been interested
> in doing the work?
>
AFAIK, there is no such warning message in the code. If you're volunteering to
do it, p
2012/3/14 Dimitri Fontaine :
> Hi,
>
> A colleague came to me to express his surprise about this quite simple
> use case:
>
> =# alter table toto add column user text;
> ERROR: syntax error at or near "user"
> LINE 1: alter table toto add column user text;
>
> Is there a reason for us not to ad
On Wed, Mar 14, 2012 at 10:27:28AM -0400, Tom Lane wrote:
> Robert Haas writes:
> > On Wed, Mar 14, 2012 at 8:28 AM, David Fetter wrote:
> >> Here's a WIP patch (lots of cut/paste, no docs, no tests), but it does
> >> work. �Still to do in addition: decide whether ALTER FOREIGN TABLE
> >> should
Robert Haas writes:
> On Wed, Mar 14, 2012 at 8:28 AM, David Fetter wrote:
>> Here's a WIP patch (lots of cut/paste, no docs, no tests), but it does
>> work. Still to do in addition: decide whether ALTER FOREIGN TABLE
>> should also handle LIKE.
> I think that instead of inventing new grammar p
Hi,
I have a hard time figuring out why my replication stopped with a message like
FATAL: password authentication failed for user "foo"
in the logs. I thought it was some pg_hba.conf change, a pgpass modification,
or NOLOGIN option, it wasn't. I was out of options when I remembered to check
if
On Wed, Mar 14, 2012 at 08:53:17AM -0400, Robert Haas wrote:
> On Wed, Mar 14, 2012 at 8:28 AM, David Fetter wrote:
> > On Tue, Mar 13, 2012 at 08:24:47AM -0700, David Fetter wrote:
> >> Folks,
> >>
> >> This is for 9.3, of course.
> >>
> >> I noticed that CREATE FOREIGN TABLE (LIKE some_table) do
Hi,
A colleague came to me to express his surprise about this quite simple
use case:
=# alter table toto add column user text;
ERROR: syntax error at or near "user"
LINE 1: alter table toto add column user text;
Is there a reason for us not to add an HINT: "user" is a reserved
keyword or
On Wed, Mar 14, 2012 at 4:27 AM, Dimitri Fontaine
wrote:
> Also, when calling the user's procedure from the same place in case of an
> ANY command trigger or a specific one it's then possible to just hand
> them over the exact same set of info (object id, name, schema name).
Yes, I think that's a
On Wed, Mar 14, 2012 at 8:28 AM, David Fetter wrote:
> On Tue, Mar 13, 2012 at 08:24:47AM -0700, David Fetter wrote:
>> Folks,
>>
>> This is for 9.3, of course.
>>
>> I noticed that CREATE FOREIGN TABLE (LIKE some_table) doesn't work. I
>> believe it should, as it would:
>>
>> - Remove a POLA vio
On Fri, Mar 9, 2012 at 5:24 AM, Fujii Masao wrote:
> For such system, so far I've been suggesting using pgstatindex, but it's good
> if pg_prewarm can do that.
Relevant to this, see commit 2e46bf67114586835f4a9908f1a1f08ee8ba83a8.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Ent
On Tue, Mar 13, 2012 at 08:24:47AM -0700, David Fetter wrote:
> Folks,
>
> This is for 9.3, of course.
>
> I noticed that CREATE FOREIGN TABLE (LIKE some_table) doesn't work. I
> believe it should, as it would:
>
> - Remove a POLA violation
> - Make data loading into an extant table even easier
Could anyone please explain the behaviour of Postgres in the cases
below? It evaluates an unused expression t.x || t.y in the first case
but doesn't do it in the second one. It's also strange that the last
explain throws an error.
postgres=# select version();
On Wednesday, March 14, 2012 05:23:03 AM Jeff Davis wrote:
> On Tue, 2012-03-13 at 09:42 +0100, Andres Freund wrote:
> > for recursively everything in dir:
> >posix_fadvise(fd, POSIX_FADV_DONTNEED);
> >
> > for recursively everything in dir:
> >fsync(fd);
>
> Wow, that made a huge differe
On Wed, Mar 14, 2012 at 2:29 AM, Tatsuo Ishii wrote:
> However I saw 1505 more accesses in total. My guess is this number
> mainly comes from index meta page access. So my guess is we need 3
> page accesses (to traverse b tree index tree) before reaching the leaf
> page in average. Am I correct o
Robert Haas writes:
> On Tue, Mar 13, 2012 at 5:06 PM, Andres Freund wrote:
>> Generally, uppon rereading, I have to say that I am not very happy with the
>> decision that ANY triggers are fired from other places than the specific
>> triggers. That seams to be a rather dangerous/confusing route t
Hi All,
Can i use keystone auth with PostgreSQL, it is very helpful when i am
using OpenStack as a cloud service and implement DBaaS.
--
ViVek Raghuwanshi
Mobile -+91-09595950504
Skype - vivek_raghuwanshi
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to
On 14.03.2012 01:53, Josh Berkus wrote:
1. The Free Space Map is not replicated between servers.
2. Thus, when we fail over to a replica, it starts with a blank FSM.
The FSM is included in the base backup, and it is updated when VACUUM
records are replayed.
It is also updated when insert/up
84 matches
Mail list logo
