On Wed, Sep 10, 2014 at 5:46 AM, Mark Kirkwood <
mark.kirkw...@catalyst.net.nz> wrote:
>
> On 05/09/14 23:50, Amit Kapila wrote:
>>
>> On Fri, Sep 5, 2014 at 8:42 AM, Mark Kirkwood
>> > FWIW below are some test results on the 60 core beast with this patch
>> applied to 9.4. I'll need to do more ru
On Tue, Sep 9, 2014 at 12:16 AM, Robert Haas wrote:
> On Fri, Sep 5, 2014 at 9:19 AM, Amit Kapila
wrote:
> > On Fri, Sep 5, 2014 at 5:17 PM, Amit Kapila
wrote:
> >> Apart from above, I think for this patch, cat version bump is required
> >> as I have modified system catalog. However I have not
On Wed, Sep 10, 2014 at 2:18 AM, Robert Haas wrote:
>
> On Tue, Sep 9, 2014 at 1:18 PM, Petr Jelinek wrote:
> >> I think that's completely wrong. As the patch series demonstrates,
> >> it's not limited to propagating ErrorResponse and NoticeResponse. It
> >> can also propagate NotifyResponse an
On Mon, Sep 8, 2014 at 8:50 PM, Michael Paquier
wrote:
> On Wed, Sep 3, 2014 at 11:40 PM, Robert Haas wrote:
>> On Sun, Aug 31, 2014 at 9:45 AM, Magnus Hagander wrote:
>>> Do we really want those Asserts? There is not a single Assert in
>>> bin/pg_basebackup today - as is the case for most thing
On Tue, Sep 9, 2014 at 3:46 AM, Robert Haas wrote:
> On Fri, Sep 5, 2014 at 9:19 AM, Amit Kapila wrote:
>> One regression failed on linux due to spacing issue which is
>> fixed in attached patch.
I just read the latest patch by curiosity, wouldn't it make more sense
to split the patch into two di
On Wed, Sep 10, 2014 at 12:15 PM, Etsuro Fujita
wrote:
> (2014/09/09 22:17), Fujii Masao wrote:
>>
>> On Tue, Sep 9, 2014 at 1:28 AM, Jeff Janes wrote:
>>>
>>> I get some compiler warnings on v2 of this patch:
>>>
>>> reloptions.c:219: warning: excess elements in struct initializer
>>> reloptions
(2014/09/09 22:17), Fujii Masao wrote:
On Tue, Sep 9, 2014 at 1:28 AM, Jeff Janes wrote:
I get some compiler warnings on v2 of this patch:
reloptions.c:219: warning: excess elements in struct initializer
reloptions.c:219: warning: (near initialization for 'intRelOpts[15]')
Attached is the u
(2014/09/09 18:57), Heikki Linnakangas wrote:
On 09/03/2014 06:39 PM, Robert Haas wrote:
Now some people might argue that we have that anyway, but the fact is
that a lot of people are using inheritance today, even with all its
flaws, and they wouldn't be if there were a long laundry list of
limi
On Tue, Sep 9, 2014 at 4:05 PM, Bruce Momjian wrote:
>> > Yes, I did think about that, but it seems like a behavior change.
>> > However, it is tempting to avoid future bug reports about this.
>>
>> When this came up in March, Tom and I agreed that this wasn't something
>> we wanted to slip into 9
On 05/09/14 23:50, Amit Kapila wrote:
On Fri, Sep 5, 2014 at 8:42 AM, Mark Kirkwood
mailto:mark.kirkw...@catalyst.net.nz>>
wrote:
>
> On 04/09/14 14:42, Amit Kapila wrote:
>>
>> On Thu, Sep 4, 2014 at 8:00 AM, Mark Kirkwood
mailto:mark.kirkw...@catalyst.net.nz>>
>> wrote:
>>>
>>>
>>>
>>>
Hmm. Sorry, I misunderstood the specification.
> You approach that coloring tokens seems right, but you have
> broken the parse logic by adding your code.
>
> Other than the mistakes others pointed, I found that
>
> - non-SQL-ident like tokens are ignored by their token style,
> quoted or not,
Thom Brown writes:
> I find this in pgbench.c:
> #ifdef FD_SETSIZE
> #define MAXCLIENTS (FD_SETSIZE - 10)
> #else
> #define MAXCLIENTS 1024
> #endif
FD_SETSIZE is supposed to be defined, according to the POSIX spec:
The header shall define the following symbolic constant,
whi
On 9.9.2014 16:09, Robert Haas wrote:
> On Mon, Sep 8, 2014 at 5:53 PM, Tomas Vondra wrote:
>> So I only posted the separate patch for those who want to do a review,
>> and then a "complete patch" with both parts combined. But it sure may be
>> a bit confusing.
>
> Let's do this: post each new ve
Hi,
I noticed when trying to set pgbench's client count to a high number, I had
to reduce it, and I found the maximum I can get away with is 1014. Any
higher and I get:
invalid number of clients: 1015
I find this in pgbench.c:
#ifdef FD_SETSIZE
#define MAXCLIENTS (FD_SETSIZE - 10)
#else
#
On 2014-09-09 22:22:45 +0200, Andres Freund wrote:
> I plan to push this soon.
Done.
Thanks for the patch!
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql
On 09/09/14 22:48, Robert Haas wrote:
On Tue, Sep 9, 2014 at 1:18 PM, Petr Jelinek wrote:
I think that's completely wrong. As the patch series demonstrates,
it's not limited to propagating ErrorResponse and NoticeResponse. It
can also propagate NotifyResponse and RowDescription and DataRow an
On 2014-09-09 17:54:03 -0400, Robert Haas wrote:
> So, that's committed, then.
Yay, finally.
> I think we should pick something that uses
> spinlocks and is likely to fail spectacularly if we haven't got this
> totally right yet, and de-volatilize it. And then watch to see what
> turns red in th
On Tue, Sep 9, 2014 at 5:32 PM, Andres Freund wrote:
> On 2014-09-09 17:30:44 -0400, Robert Haas wrote:
>> On Tue, Sep 9, 2014 at 5:09 PM, Andres Freund wrote:
>> > On 2014-09-09 13:52:40 -0400, Robert Haas wrote:
>> >> I had forgotten that it needed an update. Thanks for the reminder.
>> >> H
On 2014-09-09 17:30:44 -0400, Robert Haas wrote:
> On Tue, Sep 9, 2014 at 5:09 PM, Andres Freund wrote:
> > On 2014-09-09 13:52:40 -0400, Robert Haas wrote:
> >> I had forgotten that it needed an update. Thanks for the reminder.
> >> Here's v2.
> >
> > I've attached a incremental patch fixing m
On Tue, Sep 9, 2014 at 5:09 PM, Andres Freund wrote:
> On 2014-09-09 13:52:40 -0400, Robert Haas wrote:
>> I had forgotten that it needed an update. Thanks for the reminder. Here's
>> v2.
>
> I've attached a incremental patch fixing minor gripes. Other than that I
> think you can go ahead with
On Fri, Sep 5, 2014 at 10:45 PM, Peter Geoghegan wrote:
> While I gave serious consideration to your idea of having a dedicated
> abbreviation comparator, and not duplicating sortsupport state when
> abbreviated keys are used (going so far as to almost fully implement
> the idea), I ultimately dec
On 2014-09-09 13:52:40 -0400, Robert Haas wrote:
> I had forgotten that it needed an update. Thanks for the reminder. Here's
> v2.
I've attached a incremental patch fixing minor gripes. Other than that I
think you can go ahead with this once the buildfarm accepts the sparc
fixes (man, those mac
On Thu, Sep 4, 2014 at 5:46 PM, Peter Geoghegan wrote:
> On Thu, Sep 4, 2014 at 2:18 PM, Robert Haas wrote:
>> Eh, maybe? I'm not sure why the case where we're using abbreviated
>> keys should be different than the case we're not. In either case this
>> is a straightforward trade-off: if we do
On Tue, Sep 9, 2014 at 1:18 PM, Petr Jelinek wrote:
>> I think that's completely wrong. As the patch series demonstrates,
>> it's not limited to propagating ErrorResponse and NoticeResponse. It
>> can also propagate NotifyResponse and RowDescription and DataRow and
>> anything else that comes al
Hi,
Given we already have three topics for --help and I can see others I
went with my --help= proposal.
On 2014-08-28 13:20:07 +0200, Andres Freund wrote:
> Some stuff I changed:
> * I rephrased the sgml changes
> * s/Printing options/Display options/. Or maybe "Display influencing
> variables"
Petr Jelinek writes:
> On 07/09/14 21:09, Andres Freund wrote:
>> On 2014-09-07 15:05:35 -0400, Tom Lane wrote:
>>> I think the main remaining issue is that we don't have consensus on
>>> the function name AFAICT. I'm okay with using width_bucket(), as
>>> is done in the latest patch, but there w
On Tue, Sep 9, 2014 at 8:07 AM, didier wrote:
>> Well, I'd like to hear someone from the field complaining that
>> pg_receivexlog is thrashing the cache and thus reducing the performance of
>> some other process. Or a least a synthetic test case that demonstrates that
>> happening.
> It's not with
On Mon, Sep 8, 2014 at 7:10 PM, Andres Freund wrote:
>> This has been pending for almost two months now and, at your request,
>> my patch to make spinlocks act as compiler barriers is waiting behind
>> it. Can we please get this moving again soon, or can I commit that
>> patch and you can fix thi
On 09/09/14 18:49, Robert Haas wrote:
On Tue, Sep 9, 2014 at 12:33 PM, Petr Jelinek wrote:
I am also not sure that I like the pq_redirect_to_shm_mq being directly
exposed for use in bgworker, what I would like is to have elog interface to
which you tell that you want errors sent to shm_mq handl
Hi,
I worked bit on this patch to make it closer to committable state.
There are several bugs fixed, including ones mentioned by Jamie (writing
WAL during recovery).
Also support for pg_resetxlog/pg_upgrade has been implemented by Andres.
I added simple regression test and regression contrib
On Tue, Sep 9, 2014 at 12:33 PM, Petr Jelinek wrote:
> I am not sure if what Andres proposed is the right solution, but I do agree
> here that the hook definitely isn't.
Well, that doesn't get me very far. Andres never responded to my
previous comments about why I did it that way, and you're not
On Tue, Sep 9, 2014 at 12:03 PM, Robert Haas wrote:
> On Mon, Sep 8, 2014 at 6:20 PM, David G Johnston
> wrote:
> > On Mon, Sep 8, 2014 at 11:45 AM, Robert Haas [via PostgreSQL] <[hidden
> > email]> wrote:
> >>
> >> On Thu, Sep 4, 2014 at 6:38 PM, David Johnston
> >> <[hidden email]> wrote:
> >>
Hi,
I recently wanted several times to have slave server prepared at certain
point in time to reduce the time it takes for it to replay remaining
WALs (say I have pg_basebackup -x on busy db for example).
Currently the way to do it is to have pause_at_recovery_target true
(default) and wait un
> "Tom" == Tom Lane writes:
>>> Honestly, ChainAggregate is _trivial_ compared to trying to make the
>>> GroupAggregate code deal with multiple inputs, or trying to make some
>>> new sort of plumbing node to feed input to those sorts. (You'd think
>>> that it should be possible to use th
On 29/07/14 18:51, Robert Haas wrote:
On Mon, Jul 28, 2014 at 1:50 PM, Andres Freund wrote:
What I'm thinking of is providing an actual API for the writes instead
of hooking into the socket API in a couple places. I.e. have something
like
typedef struct DestIO DestIO;
struct DestIO
{
voi
On Tue, Sep 9, 2014 at 2:57 AM, Heikki Linnakangas
wrote:
> I agree. If we are to support UPDATE .. ORDER BY .. LIMIT, it should work
> with inheritance. So the path forward is (using Marko's phrasing upthread):
>
>1) We put the LIMIT inside ModifyTable like this patch does. This
> doesn't
On Tue, Sep 9, 2014 at 12:01 PM, Andrew Gierth
wrote:
>> "Robert" == Robert Haas writes:
>
> Robert> Sure, showing the sort and aggregation steps is fine. But I
> Robert> don't see what advantage we get out of showing them like
> Robert> this:
>
> Robert> Aggregate
> Robert> -> Sort
>
On 2014-08-28 13:54:28 +0200, Andres Freund wrote:
> On 2014-08-28 13:20:07 +0200, Andres Freund wrote:
> > I've attached a incremental patch.
>
> Apparently I didn't attach the patch, as so much a file containing the
> name of the patchfile...
Which you obviously didn't integrate. And didn't com
Robert Haas writes:
> On Tue, Sep 9, 2014 at 12:01 PM, Andrew Gierth
> wrote:
>> Honestly, ChainAggregate is _trivial_ compared to trying to make the
>> GroupAggregate code deal with multiple inputs, or trying to make some
>> new sort of plumbing node to feed input to those sorts. (You'd think
>
On Mon, Sep 8, 2014 at 6:20 PM, David G Johnston
wrote:
> On Mon, Sep 8, 2014 at 11:45 AM, Robert Haas [via PostgreSQL] <[hidden
> email]> wrote:
>>
>> On Thu, Sep 4, 2014 at 6:38 PM, David Johnston
>> <[hidden email]> wrote:
>>
>> > One of the trade-offs I mentioned...its more style than anything
On 09/08/2014 05:27 PM, Bianca Santana Espichicoquez wrote:
Hello, I've a problem, we're using sugarcrm, and we have a database
postgresql, but not in the default port, so, when I try to connect
after I put the port in the db_port parameter, but seems like he not
recognized, because still poin
> "Robert" == Robert Haas writes:
Robert> Sure, showing the sort and aggregation steps is fine. But I
Robert> don't see what advantage we get out of showing them like
Robert> this:
Robert> Aggregate
Robert> -> Sort
Robert>-> ChainAggregate
Robert> -> Sort
Robert>
On Tue, Sep 9, 2014 at 11:07 AM, Fabien COELHO wrote:
>> The fact that you're agonizing about which modulo to add is a sign that
>> the language is too impoverished to let you do anything non-trivial.
>
> I'm not agonizing about which modulo to use:-) I know I do not want the
> C/SQL version which
On 8/30/14 12:43 PM, Ali Akbar wrote:
> While looking into this report
> http://www.postgresql.org/message-id/cf48ccfb.65a9d%tim.k...@gmail.com I
> noticed that we don't accept empty values as xml "content" values, even
> though this should apparently be allowed by the spec. Attach
2014-09-09 7:55 GMT+02:00 Craig Ringer :
> On 09/09/2014 05:20 AM, Robert Haas wrote:
> >
> > I previously proposed RAISE ASSERT ... WHERE, which seems like a nice
> > variant of what we've already got, but perhaps this whole discussion
> > merely illustrates that it's hard to get more than 1 vote
Hello, I've a problem, we're using sugarcrm, and we have a database
postgresql, but not in the default port, so, when I try to connect after I
put the port in the db_port parameter, but seems like he not recognized,
because still pointing to the other instance of the database that have the
5432 por
2014-09-09 16:01 GMT+02:00 Robert Haas :
> On Thu, Aug 21, 2014 at 11:01 AM, Andrew Gierth
> wrote:
> >> "Heikki" == Heikki Linnakangas writes:
> > Heikki> Uh, that's ugly. The EXPLAIN out I mean; as an implementation
> > Heikki> detail chaining the nodes might be reasonable. But the above
On Tue, Sep 9, 2014 at 11:19 AM, Pavel Stehule wrote:
> 2014-09-09 16:01 GMT+02:00 Robert Haas :
>> On Thu, Aug 21, 2014 at 11:01 AM, Andrew Gierth
>> wrote:
>> >> "Heikki" == Heikki Linnakangas writes:
>> > Heikki> Uh, that's ugly. The EXPLAIN out I mean; as an implementation
>> > Heikki>
Hello Robert,
Writing a simple expression parser for pgbench using flex and bison
would not be an inordinately difficult problem.
Sure. Note that there is not only the parsing but also the evaluating to
think of, which mean a data structure to represent the expressions which
would be more c
Alvaro,
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> Thanks. One more tweak --- the whole reason for fiddling with this is
> to ensure that event triggers support this operation. Therefore this
> node should be handled by ProcessUtilitySlow, not
> standard_ProcessUtility, as in the attac
On Sat, Sep 6, 2014 at 09:30:06AM -0400, Bruce Momjian wrote:
> On Fri, Sep 5, 2014 at 07:35:42PM -0400, Bruce Momjian wrote:
> > On Sat, Sep 6, 2014 at 12:26:55AM +0100, Greg Stark wrote:
> > > On Wed, Sep 3, 2014 at 3:59 AM, Bruce Momjian wrote:
> > > > I have developed the attached patch whi
On Tue, Sep 9, 2014 at 11:08:05AM -0300, Arthur Silva wrote:
> I'm continuously studying Postgres codebase. Hopefully I'll be able to make
> some contributions in the future.
>
> For now I'm intrigued about the extensive use of memory alignment. I'm sure
> there's some legacy and some architectur
On Wed, Aug 6, 2014 at 3:22 PM, Fabien COELHO wrote:
>> Maybe we ought to break down and support a real expression syntax.
>> Sounds like that would be better all around.
>
> Adding operators is more or less orthogonal with providing a new expression
> syntax. I'm not sure that there is currently
On Sun, Sep 7, 2014 at 7:07 PM, Shigeru HANADA wrote:
>> I think it's probably good to give an FDW the option of producing a
>> ForeignJoinPath for any join against a ForeignPath *or
>> ForeignJoinPath* for the same FDW. It's perhaps unlikely that an FDW
>> can perform a join efficiently between
Etsuro Fujita wrote:
> I agree with you on that point. So, I've updated the patch to have the
> explicit flag, as you proposed. Attached is the updated version of the
> patch. In this version, I've also revised code and its comments a bit.
Thank you, I have set the patch to "Ready for Committer
On Mon, Sep 8, 2014 at 5:53 PM, Tomas Vondra wrote:
> So I only posted the separate patch for those who want to do a review,
> and then a "complete patch" with both parts combined. But it sure may be
> a bit confusing.
Let's do this: post each new version of the patches only on this
thread, as a
I'm continuously studying Postgres codebase. Hopefully I'll be able to make
some contributions in the future.
For now I'm intrigued about the extensive use of memory alignment. I'm sure
there's some legacy and some architecture that requires it reasoning behind
it.
That aside, since it wastes spa
On Thu, Aug 21, 2014 at 11:01 AM, Andrew Gierth
wrote:
>> "Heikki" == Heikki Linnakangas writes:
> Heikki> Uh, that's ugly. The EXPLAIN out I mean; as an implementation
> Heikki> detail chaining the nodes might be reasonable. But the above
> Heikki> gets unreadable if you have more than a
On Tue, Sep 9, 2014 at 9:07 PM, didier wrote:
> Hi
>
>> Well, I'd like to hear someone from the field complaining that
>> pg_receivexlog is thrashing the cache and thus reducing the performance of
>> some other process. Or a least a synthetic test case that demonstrates that
>> happening.
> It's n
On Tue, Sep 9, 2014 at 1:28 AM, Jeff Janes wrote:
> On Sun, Aug 17, 2014 at 7:46 PM, Fujii Masao wrote:
>>
>>
>> Thanks for reviewing the patch! ISTM that I failed to make the patch from
>> my git repository... Attached is the rebased version.
>
>
>
> I get some compiler warnings on v2 of this pa
Hello Heikki,
I think we have to reconsider what we're reporting in 9.4, when --rate
is enabled, even though it's already very late in the release cycle.
It's a bad idea to change the definition of latency between 9.4 and 9.5,
so let's get it right in 9.4.
Indeed.
As per the attached patch.
Sorry for wrong suggestion. Setting in_quote is wrong there because it's
before the beginning quote. Although, advancing read pointer and replacing
c with the next value is still needed.
regards,
--
Kyotaro Horiguchi
NTT Open Source Software Center
2014/09/09 20:49 "Kyotaro HORIGUCHI" :
> Hello,
Hi
> Well, I'd like to hear someone from the field complaining that
> pg_receivexlog is thrashing the cache and thus reducing the performance of
> some other process. Or a least a synthetic test case that demonstrates that
> happening.
It's not with pg_receivexlog but it's related.
On a small box
Hello, I will be the reviewer of this patch.
You approach that coloring tokens seems right, but you have
broken the parse logic by adding your code.
Other than the mistakes others pointed, I found that
- non-SQL-ident like tokens are ignored by their token style,
quoted or not, so the followin
On 09/08/2014 07:02 PM, Alvaro Herrera wrote:
Here's version 18. I have renamed it: These are now BRIN indexes.
I have fixed numerous race conditions and deadlocks. In particular I
fixed this problem you noted:
Heikki Linnakangas wrote:
Another race condition:
If a new tuple is inserted to
On 09/09/2014 01:49 PM, Heikki Linnakangas wrote:
I think we have to reconsider what we're reporting in 9.4, when --rate
is enabled, even though it's already very late in the release cycle.
It's a bad idea to change the definition of latency between 9.4 and 9.5,
so let's get it right in 9.4.
As
On 09/09/2014 01:46 PM, Marko Tiikkaja wrote:
On 9/9/14 12:37 PM, I wrote:
And no, these are not routine things so keep your "use
partitions" suggestions to yourselves.
My apologies. This was not directed at you personally, Heikki, and in
any case it was unnecessarily hostile.
No worries, i
On 09/05/2014 06:38 PM, Jan Wieck wrote:
On 09/05/2014 10:12 AM, Fabien COELHO wrote:
Note that despite pg appaling latency performance, in may stay well over
the 90% limit, or even 100%: when things are going well a lot of
transaction run in about ms, while when things are going bad transaction
On 9/9/14 12:37 PM, I wrote:
And no, these are not routine things so keep your "use
partitions" suggestions to yourselves.
My apologies. This was not directed at you personally, Heikki, and in
any case it was unnecessarily hostile.
.marko
--
Sent via pgsql-hackers mailing list (pgsql-hac
On 9/9/14 11:57 AM, Heikki Linnakangas wrote:
What's not clear to me is whether it make sense to do 1) without 2) ? Is
UPDATE .. LIMIT without support for an ORDER BY useful enough?
I'd say so; I could use it right now. I have to remove millions of
lines from a table, but I don't want the liv
Hi, I added and edited some comments.
> Sorry, It tha patch contains a silly bug. Please find the
> attatched one.
regards,
--
Kyotaro Horiguchi
NTT Open Source Software Center
>From eb91a7c91e1fd3b24bf5bff0eb885f1c3d274637 Mon Sep 17 00:00:00 2001
From: Kyotaro Horiguchi
Date: Fri, 5 Sep 2014
On Tue, Sep 9, 2014 at 3:11 AM, Thom Brown wrote:
> On 5 September 2014 14:19, Amit Kapila wrote:
>> On Fri, Sep 5, 2014 at 5:17 PM, Amit Kapila
wrote:
>> >
>> > Apart from above, I think for this patch, cat version bump is required
>> > as I have modified system catalog. However I have not don
On Tue, Sep 9, 2014 at 2:32 AM, Robert Haas wrote:
> On Mon, Sep 8, 2014 at 2:05 AM, Amit Kapila
wrote:
> >> Another point about error handling is that to execute the sql in
> >> function pg_background_worker_main(), it starts the transaction
> >> which I think doesn't get aborted if error occurs
On 09/03/2014 06:39 PM, Robert Haas wrote:
On Wed, Sep 3, 2014 at 11:02 AM, Marko Tiikkaja wrote:
On 9/3/14 4:46 PM, Robert Haas wrote:
Making it
suck more because you don't think it's as important as your feature
is, in my opinion, not cool.
I really can't see how that would make inheritanc
On 2014-09-04 08:18:37 -0400, Robert Haas wrote:
> On Tue, Aug 5, 2014 at 11:55 AM, Robert Haas wrote:
> > On Sun, Jul 6, 2014 at 3:12 PM, Andres Freund
> > wrote:
> >>> > If you want to do that, it's fine with me. What I would do is:
> >>> >
> >>> > - Back-patch the addition of the sparcv8+ st
On 9/9/14 10:54 AM, Heikki Linnakangas wrote:
So I think this (and the corresponding dearmor code too) should be
refactored to use a StringInfo that gets enlarged as needed, instead of
hoping to guess the size correctly beforehand. To ease review, might
make sense to do that as a separate patch o
On 08/15/2014 11:55 AM, Marko Tiikkaja wrote:
Hi,
On 8/8/14 3:18 PM, I wrote:
Currently there's no way to generate or extract armor headers from the
PGP armored format in pgcrypto. I've written a patch to add the
support.
Latest version of the patch here, having fixed some small coding issue
On 2014-09-09 07:54, Craig Ringer wrote:
On 09/05/2014 05:21 PM, Pavel Stehule wrote:
*shrug* Doing it in SQL would probably break more stuff. I'm trying to
contain the damage. And arguably, this is mostly only useful in PL/PgSQL.
I've wanted assertions in SQL enough that I often write tri
On 09/07/2014 05:58 AM, Peter Geoghegan wrote:
+ Lehman and Yao don't require read locks, but assume that in-memory
+ copies of tree pages are unshared. Postgres shares in-memory buffers
+ among backends. As a result, we do page-level read locking on btree
+ pages in order to guarantee that no
79 matches
Mail list logo
