2014-10-25 8:33 GMT+02:00 Pavel Stehule :
>
>
> 2014-10-25 8:19 GMT+02:00 Ali Akbar :
>
>> 2014-10-25 10:29 GMT+07:00 Ali Akbar :
>>
>>> I fixed small issue in regress tests and I enhanced tests for varlena
types and null values.
>>>
>>> Thanks.
>>>
>>> it is about 15% faster than original im
2014-10-25 8:19 GMT+02:00 Ali Akbar :
> 2014-10-25 10:29 GMT+07:00 Ali Akbar :
>
>> I fixed small issue in regress tests and I enhanced tests for varlena
>>> types and null values.
>>
>> Thanks.
>>
>> it is about 15% faster than original implementation.
>>
>> 15% faster than array_agg(scalar)? I h
2014-10-25 10:29 GMT+07:00 Ali Akbar :
> I fixed small issue in regress tests and I enhanced tests for varlena
>> types and null values.
>
> Thanks.
>
> it is about 15% faster than original implementation.
>
> 15% faster than array_agg(scalar)? I haven't verify the performance, but
> because the i
On Fri, Oct 24, 2014 at 4:05 PM, Andres Freund
wrote:
>
> On 2014-10-24 15:59:30 +0530, Amit Kapila wrote:
> > > > and w.r.t performance it can lead extra
> > > > function call, few checks and I think in some cases even can
> > > > acquire/release spinlock.
> > >
> > > I fail to see how that could
>
> I fixed small issue in regress tests and I enhanced tests for varlena
> types and null values.
Thanks.
it is about 15% faster than original implementation.
15% faster than array_agg(scalar)? I haven't verify the performance, but
because the internal array data and null bitmap is copied as-is
On Fri, Oct 24, 2014 at 7:37 PM, Jim Nasby wrote:
> ISTM that the multiple-databases-per-backend issue is the huge hang-up here.
> Maybe there's some way that could be hacked around if you're just
> re-jiggering a bunch of catalog stuff (assuming you lock users out of both
> databases while you're
Drew,
> IMHO this is nonintuitive, the intuitive behavior of a security_barrier
> view should be to forbid inserting rows that can’t appear in the view.
>
Isn't that what WITH CHECK OPTION is meant to accomplish?
-Adam
--
Adam Brightwell - adam.brightw...@crunchydatasolutions.com
Database E
Hi guys, I’m seeing some non-intuitive behavior with the new updateable
security barrier views in 9.4. Below is the behavior of 9.4b3:
> =# create table widget ( id integer);
> CREATE TABLE
> =# create view widget_sb WITH (security_barrier=true) AS SELECT * from widget
> where id = 22;
> CREATE
Tatsuo Ishii writes:
> I saw this comment in _outQuery() in outfuncs.c:
> WRITE_ENUM_FIELD(commandType, CmdType);
> WRITE_ENUM_FIELD(querySource, QuerySource);
> /* we intentionally do not print the queryId field */
> WRITE_BOOL_FIELD(canSetTag);
> What is the resoning be
Hi,
I saw this comment in _outQuery() in outfuncs.c:
WRITE_ENUM_FIELD(commandType, CmdType);
WRITE_ENUM_FIELD(querySource, QuerySource);
/* we intentionally do not print the queryId field */
WRITE_BOOL_FIELD(canSetTag);
What is the resoning behind the comment?
Be
The comment for the BackgroundWorkerSlot structure tripped me up reviewing
Robert's background worker patch; it made it clear that you need to use a
memory barrier before setting in_use, but normally you'd never need to worry
about that because RegisterDynamicBackgroundWorker() handles it for y
On 10/23/14, 6:23 PM, Alvaro Herrera wrote:
Brightwell, Adam wrote:
If we were to make it consistent and use the old wording, what do you
think about providing an "errhint" as well?
Perhaps for example in slotfuncs.c#pg_create_physical_replication_stot:
errmsg - "permission denied to create
Please don't top-post.
On 10/24/14, 3:40 AM, Borodin Vladimir wrote:
I have taken some backtraces (they are attached to the letter) of two processes
with such command:
pid=17981; while true; do date; gdb -batch -e back /usr/pgsql-9.4/bin/postgres
$pid; echo; echo; echo; echo; sleep 0.1; done
On Fri, Oct 24, 2014 at 4:39 PM, Petr Jelinek wrote:
> If you feel so strongly that it's wrong even though everybody else seems to
> prefer it and if you at the same time feel so strongly about people changing
> minds once you implement this, maybe the best way to convince us is to show
> us the i
On 25/10/14 00:48, Peter Geoghegan wrote:
You're conflating the user-visible syntax with the parse tree
representation in way that is utterly without foundation. I don't
have a position at this point on which parse-analysis representation
is preferable, but it's completely wrong-headed to say th
On 10/24/14, 1:28 PM, Robert Haas wrote:
On Fri, Oct 24, 2014 at 2:06 PM, Joshua D. Drake wrote:
One of the things we run into quite a bit is customers who are using
multiple databases when they should be using multiple schemas. I am sure
other consultants run into this as well. This gets even
On 24/10/14 23:07, Robert Haas wrote:
On Fri, Oct 24, 2014 at 4:53 PM, Jim Nasby wrote:
The only case I can think of would be actually connecting to a remote
database; in that case would we even want something as raw as this? I
suspect not, in which case I don't see an issue. On the other hand,
On 10/24/14, 4:03 PM, Robert Haas wrote:
On Fri, Oct 24, 2014 at 4:46 PM, Jim Nasby wrote:
On 10/24/14, 12:21 PM, Robert Haas wrote:
- What should we call dsm_unkeep_mapping, if not that?
Only option I can think of beyond unkeep would be
dsm_(un)register_keep_mapping. Dunno that it's worth i
On 24/10/14 23:03, Robert Haas wrote:
On Fri, Oct 24, 2014 at 4:46 PM, Jim Nasby wrote:
On 10/24/14, 12:21 PM, Robert Haas wrote:
- What should we call dsm_unkeep_mapping, if not that?
Only option I can think of beyond unkeep would be
dsm_(un)register_keep_mapping. Dunno that it's worth it.
On Fri, Oct 24, 2014 at 1:07 PM, Robert Haas wrote:
> The problem here isn't that I haven't read your emails. I have read
> them all, including that one. Moreover, this isn't the first time
> you've asserted that someone hasn't read one of your emails. So if
> we're going to say what we each th
On Oct24, 2014, at 22:50 , Kevin Grittner wrote:
> I need to spend some more time looking at it, and I have another
> couple things in front of this on my personal TODO list, but I
> think that if we had a row lock which was stronger than current
> SELECT FOR UPDATE behavior, and the delete of a p
On Fri, Oct 24, 2014 at 7:42 PM, Robert Haas wrote:
> [rhaas pgsql]$ patch -p1 < ~/Downloads/20141023_pg_recvlogical_fixes.patch
> patching file doc/src/sgml/ref/pg_recvlogical.sgml
> Hunk #1 succeeded at 270 with fuzz 1 (offset 165 lines).
> Hunk #2 FAILED at 282.
> Hunk #3 FAILED at 295.
> Hunk
On Fri, Oct 24, 2014 at 4:53 PM, Jim Nasby wrote:
> The only case I can think of would be actually connecting to a remote
> database; in that case would we even want something as raw as this? I
> suspect not, in which case I don't see an issue. On the other hand, if we
> ever think we might want t
On Fri, Oct 24, 2014 at 4:46 PM, Jim Nasby wrote:
> On 10/24/14, 12:21 PM, Robert Haas wrote:
>> - What should we call dsm_unkeep_mapping, if not that?
>
> Only option I can think of beyond unkeep would be
> dsm_(un)register_keep_mapping. Dunno that it's worth it.
Hmm, we could rename dsm_keep_ma
On 10/24/14, 3:26 PM, Robert Haas wrote:
On Fri, Oct 24, 2014 at 3:30 PM, Jim Nasby wrote:
On 10/24/14, 2:23 PM, Jim Nasby wrote:
On the serialization structure itself, should we be worried about a
mismatch between available GUCs on the sender vs the receiver? Presumably if
the sender outputs
Florian Pflug wrote:
> On Oct24, 2014, at 20:24 , Robert Haas wrote:
>> On Fri, Oct 24, 2014 at 2:12 PM, Florian Pflug wrote:
What about doing one scan using SnapshotAny and then testing each
returned row for visibility under both relevant snapshots? See
whether there is any tupl
On 10/24/14, 12:21 PM, Robert Haas wrote:
- What should we call dsm_unkeep_mapping, if not that?
Only option I can think of beyond unkeep would be
dsm_(un)register_keep_mapping. Dunno that it's worth it.
- Does anyone have a tangible suggestion for how to reduce the code
duplication in patch
On Fri, Oct 24, 2014 at 2:58 PM, Florian Pflug wrote:
> I believe the best way forward is to first find a solution for SERIALIZABLE
> transactions, and then check if it can be applied to REPEATABLE READ
> mode too. For SERIALIZABLE mode, it's at least clear what we're aiming
> for -- offering true
On Fri, Oct 24, 2014 at 3:30 PM, Jim Nasby wrote:
> On 10/24/14, 2:23 PM, Jim Nasby wrote:
>> On the serialization structure itself, should we be worried about a
>> mismatch between available GUCs on the sender vs the receiver? Presumably if
>> the sender outputs a GUC that the receiver doesn't kn
On Fri, Oct 24, 2014 at 3:23 PM, Jim Nasby wrote:
> Here's a review of patch 4.
Thanks!
> Perhaps it would be good to document the serialization format. I at least
> would have found it helpful, especially when reading
> estimate_variable_size(). I can take a stab at that if you'd rather not be
On Fri, Oct 24, 2014 at 3:01 PM, Peter Geoghegan wrote:
> This is the situation with unique index inference all over again. You
> don't like a function-like expression. Okay. It would be a lot more
> helpful if instead of just criticizing, you *also* looked at my
> reasons for not wanting to go wi
On 10/24/14, 2:23 PM, Jim Nasby wrote:
On the serialization structure itself, should we be worried about a mismatch
between available GUCs on the sender vs the receiver? Presumably if the sender
outputs a GUC that the receiver doesn't know about we'll get an error, but what
if the sender didn'
On 10/24/14, 12:21 PM, Robert Haas wrote:
On Fri, Oct 24, 2014 at 1:13 PM, Jim Nasby wrote:
It's a valid concern, but I think the way to handle it if needed is to limit
the number of connections a user can open. Or perhaps another option would
be to change the permissions on the related functio
On Fri, Oct 24, 2014 at 10:04 AM, Robert Haas wrote:
> On Thu, Oct 23, 2014 at 9:43 PM, Peter Geoghegan wrote:
>> * CONFLICTING() is renamed to EXCLUDED(). I know that some people
>> wanted me to go a different way with this. I think that there are very
>> good practical reasons not to [1], as we
On Oct24, 2014, at 20:24 , Robert Haas wrote:
> On Fri, Oct 24, 2014 at 2:12 PM, Florian Pflug wrote:
>>> What about doing one scan using SnapshotAny and then testing each
>>> returned row for visibility under both relevant snapshots? See
>>> whether there is any tuple for which they disagree.
>
Hi Ali
I checked a code. I am thinking so code organization is not good.
accumArrayResult is too long now. makeMdArrayResult will not work, when
arrays was joined (it is not consistent now). I don't like a usage of
state->is_array_accum in array_userfunc.c -- it is signal of wrong
wrapping.
next
On Fri, Oct 24, 2014 at 2:12 PM, Florian Pflug wrote:
>> What about doing one scan using SnapshotAny and then testing each
>> returned row for visibility under both relevant snapshots? See
>> whether there is any tuple for which they disagree.
>
> See my other mail - testing whether the snapshots
On Fri, Oct 24, 2014 at 2:06 PM, Joshua D. Drake wrote:
> One of the things we run into quite a bit is customers who are using
> multiple databases when they should be using multiple schemas. I am sure
> other consultants run into this as well. This gets even more difficult as
> uptime requirement
On Oct24, 2014, at 19:32 , Robert Haas wrote:
> On Fri, Oct 24, 2014 at 1:28 PM, Florian Pflug wrote:
>> The only other option I see would be so teach the executor to check
>> whether *any* snapshot between the transaction's snapshot and a current
>> snapshot would see a different set of rows. Si
Hello,
One of the things we run into quite a bit is customers who are using
multiple databases when they should be using multiple schemas. I am sure
other consultants run into this as well. This gets even more difficult
as uptime requirements have become all but 100%. So my question is, what
On Fri, Oct 24, 2014 at 9:05 AM, Heikki Linnakangas
wrote:
> So, this is what I came up with for master. Does anyone see a problem with
> it?
In the proposed commit message, you mis-spelled "significant" as "signicant".
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Pos
On Fri, Oct 17, 2014 at 8:10 PM, Stephen Frost wrote:
> * Peter Eisentraut (pete...@gmx.net) wrote:
>> On 10/16/14 9:45 AM, Stephen Frost wrote:
>> > Alright, coming back to this, I have to ask- how are matviews different
>> > from views from the SQL standard's perspective? I tried looking throug
On Thu, Oct 23, 2014 at 10:00 AM, Michael Paquier
wrote:
> pg_recvlogical is missing some "=" signs for a couple of option names where
> double-dash is used, like this one:
> --username user
> should be that:
> --username=user
>
> Attached is a patch correcting that.
For reasons that are not clea
On Fri, Oct 24, 2014 at 1:28 PM, Florian Pflug wrote:
> The only other option I see would be so teach the executor to check
> whether *any* snapshot between the transaction's snapshot and a current
> snapshot would see a different set of rows. Simply checking whether both
> the current snapshot an
On Fri, Oct 24, 2014 at 1:18 PM, Josh Berkus wrote:
> On 10/24/2014 10:04 AM, Robert Haas wrote:
>> As far as syntax goes, I thought the INSERT .. ON CONFLICT UPDATE
>> syntax proposed upthread was the best of any mentioned thus far. The
>> MERGE-based syntaxes proposed upthread were crazily verb
On Fri, Oct 24, 2014 at 1:13 PM, Jim Nasby wrote:
> It's a valid concern, but I think the way to handle it if needed is to limit
> the number of connections a user can open. Or perhaps another option would
> be to change the permissions on the related functions (do we check ACLs for
> internal fun
On Oct24, 2014, at 18:42 , Robert Haas wrote:
> I don't think you can count on being able to figure out all of the
> recent lockers by looking at xmax; it can get overwritten. For
> example, suppose transaction A locks the row and then commits. Then
> transaction B comes along and again locks th
On 10/24/2014 10:04 AM, Robert Haas wrote:
> As far as syntax goes, I thought the INSERT .. ON CONFLICT UPDATE
> syntax proposed upthread was the best of any mentioned thus far. The
> MERGE-based syntaxes proposed upthread were crazily verbose for no
> discernable benefit.
For those of us who hav
On 10/22/14, 7:49 PM, Joshua D. Drake wrote:
I lean toward a push into core because:
+1
3. I am not sure I buy into the super-user argument. Just because the
functionality is there, doesn't mean it has to be used.
It's a valid concern, but I think the way to handle it if needed is to limi
On Thu, Oct 23, 2014 at 9:43 PM, Peter Geoghegan wrote:
> * CONFLICTING() is renamed to EXCLUDED(). I know that some people
> wanted me to go a different way with this. I think that there are very
> good practical reasons not to [1], as well as good reasons related to
> design, but I still accept
On Thu, Oct 23, 2014 at 2:41 PM, Florian Pflug wrote:
> The only reason we need the crosscheck snapshot to do that is because
> children may have been added (and the change committed) *after* the
> transaction which removed the parent has taken its snapshot, but *before*
> that transaction locks t
On 10/24/2014 11:36 AM, Michael Paquier wrote:
On Thu, Sep 25, 2014 at 12:38 PM, Heikki Linnakangas <
hlinnakan...@vmware.com> wrote:
On 09/24/2014 05:48 PM, Abhijit Menon-Sen wrote:
Updated patches attached.
Thanks, applied some version of these.
This set of patches has been applied as
On Wed, Oct 22, 2014 at 3:06 AM, Andreas Karlsson wrote:
> I have been thinking about why we need to grab an AccessExclusiveLock on the
> table with the PK when we add a foreign key. Adding new tables with foreign
> keys to old ones is common so it would be really nice if the lock strength
> could
which would also be nice to fix..
Of course, agree. With rbtree usage instead of tidbitmap hash and semantic
knowledge about operators in GIN...
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sig
On Fri, Oct 24, 2014 at 10:10 AM, Andres Freund wrote:
> What I was thinking was that you'd append the messages to the layer one
> level deeper than the parent. Then we'd missed the invalidations when
> rolling back the intermediate xact. But since I was quite mistaken
> above, this isn't a proble
On 10/24/2014 05:40 PM, Andres Freund wrote:
On 2014-10-24 17:13:49 +0300, Heikki Linnakangas wrote:
Yeah. The padding bytes in TwoPhaseFileHeader were not initialized.
That's simple enough to fix, but when I run valgrind, I get a lot whole
bunch of similar messages. A few are from pgstat: the
On 2014-10-24 17:13:49 +0300, Heikki Linnakangas wrote:
> Yeah. The padding bytes in TwoPhaseFileHeader were not initialized.
>
> That's simple enough to fix, but when I run valgrind, I get a lot whole
> bunch of similar messages. A few are from pgstat: the padding bytes in the
> pgstat messages a
Michael Paquier writes:
> On Fri, Oct 24, 2014 at 3:39 PM, Tom Lane wrote:
>> Peter, Dave: maybe you have tweaked things to keep listen_addresses
>> empty and rely only on Unix-socket connections?
> Should be so. The target of this feature is development on OSX, right?
> And most of the time dev
On 10/24/2014 01:24 PM, furu...@pm.nttdata.co.jp wrote:
Sorry, I'm going around in the circle. But I'd like to say again, I
don't think this is good idea. It prevents asynchronous
pg_receivexlog from fsyncing WAL data and sending feedbacks more
frequently at all. They are useful, for example, whe
On 10/11/2014 10:20 PM, Bruce Momjian wrote:
Uh, was this fixed. I see a cleanup commit for this C file, but this
report is from June:
commit 07a4a93a0e35a778c77ffbbbc18de29e859e18f0
Author: Heikki Linnakangas
Date: Fri May 16 09:47:50 2014 +0300
On 2014-10-24 09:45:59 -0400, Robert Haas wrote:
> On Fri, Oct 24, 2014 at 9:17 AM, Andres Freund wrote:
> >> If
> >> that subtransaction abouts, AtEOSubXact_Inval() gets called again,
> >> sees that it has messages (that it inherited from the innermost
> >> subtransaction), and takes the exact sa
On Fri, Oct 24, 2014 at 3:39 PM, Tom Lane wrote:
> Peter, Dave: maybe you have tweaked things to keep listen_addresses
> empty and rely only on Unix-socket connections?
Should be so. The target of this feature is development on OSX, right?
And most of the time development would be done only on the
On Fri, Oct 24, 2014 at 1:42 AM, Craig Ringer wrote:
> On 10/23/2014 09:21 PM, Robert Haas wrote:
>> Agreed - I think if you want an error check here it should use elog()
>> or ereport(), not Assert().
>
> That's what I originally did, but it's too early for elog.
>
> I'm reluctant to just fprintf
On Wed, Oct 22, 2014 at 2:14 AM, edward745 wrote:
> One of the queries in ri_triggers.c has be a little baffled.
>
> For (relatively) obvious reasons, a FK insert triggers a SELECT 1 FROM
> pk_rel ... FOR KEY SHARE.
> For not-so-obvious reasons, a PK delete triggers a SELECT 1 FROM fk_rel ...
> FO
On Fri, Oct 24, 2014 at 9:17 AM, Andres Freund wrote:
>> If
>> that subtransaction abouts, AtEOSubXact_Inval() gets called again,
>> sees that it has messages (that it inherited from the innermost
>> subtransaction), and takes the exact same code-path that it would have
>> pre-patch.
>
> Consider
Michael Paquier writes:
> On Fri, Oct 24, 2014 at 8:26 AM, Dave Page wrote:
>> On Fri, Oct 24, 2014 at 7:18 AM, Peter Eisentraut wrote:
>>> On 10/21/14 1:16 PM, Tom Lane wrote:
If you do any Postgres development on OS X, you've probably gotten
seriously annoyed by the way that, every s
On Tue, Oct 21, 2014 at 10:16 AM, Tom Lane wrote:
> (Of course, I'm not for the feature w.r.t. SQL either. But breaking data
> compatibility is just adding an entire new dimension of trouble.
>
Another dimension of the trouble is breaking the operation of the
tools that parse SQL statements for
On Fri, Oct 24, 2014 at 3:05 PM, Heikki Linnakangas
wrote:
> On 10/23/2014 11:09 AM, Heikki Linnakangas wrote:
>>
>> At least for master, we should consider changing the way the archiving
>> works so that we only archive WAL that was generated in the same server.
>> I.e. we should never try to arc
On 10/22/2014 03:01 PM, Teodor Sigaev wrote:
Anyway GIN couldn't be used for ORDER BY clause.
which would also be nice to fix...
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hack
On 2014-10-23 12:04:40 -0400, Robert Haas wrote:
> On Tue, Oct 21, 2014 at 12:00 PM, Andres Freund
> wrote:
> > On 2014-10-09 15:01:19 -0400, Robert Haas wrote:
> >> /*
> >> @@ -960,18 +966,38 @@ AtEOXact_Inval(bool isCommit)
> > ...
> >> + /*
> >> + * We create invalida
On Wed, Oct 22, 2014 at 6:31 AM, Александр Глухов
wrote:
> Hello, I have a problem with PostgreSQL. I need to install PostgreSQL on
> ARMv5 with tcp/ip access, but I have no experience in it. I trying to do it
> in LTIB and now I need to create a postgresql.spec file. Could you help me
> in it?
T
On 10/22/2014 03:01 PM, Teodor Sigaev wrote:
Anyway GIN couldn't be used for ORDER BY clause.
which would also be nice to fix...
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hack
2014-10-24 13:58 GMT+02:00 Pavel Stehule :
>
>
> 2014-10-24 11:43 GMT+02:00 Ali Akbar :
>
>>
>> 2014-10-24 16:26 GMT+07:00 Pavel Stehule :
>>
>>> Hi
>>>
>>> some in last patch is wrong, I cannot to compile it:
>>>
>>> arrayfuncs.c: In function ‘accumArrayResult’:
>>> arrayfuncs.c:4603:9: error: ‘A
On 10/23/2014 11:09 AM, Heikki Linnakangas wrote:
At least for master, we should consider changing the way the archiving
works so that we only archive WAL that was generated in the same server.
I.e. we should never try to archive WAL files belonging to another timeline.
I just remembered that we
Michael Paquier wrote:
> That's not surprising, sometimes filterdiff misses the shot.
Really? Wow, that's bad news. I've been using it to submit patches
from time to time ...
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
Hi
I did some performance tests and it is interesting:
it is about 15% faster than original implementation.
Regards
Pavel
2014-10-24 13:58 GMT+02:00 Pavel Stehule :
>
>
> 2014-10-24 11:43 GMT+02:00 Ali Akbar :
>
>>
>> 2014-10-24 16:26 GMT+07:00 Pavel Stehule :
>>
>>> Hi
>>>
>>> some in las
2014-10-24 11:43 GMT+02:00 Ali Akbar :
>
> 2014-10-24 16:26 GMT+07:00 Pavel Stehule :
>
>> Hi
>>
>> some in last patch is wrong, I cannot to compile it:
>>
>> arrayfuncs.c: In function ‘accumArrayResult’:
>> arrayfuncs.c:4603:9: error: ‘ArrayBuildState’ has no member named ‘alen’
>>astate->ale
On Oct23, 2014, at 17:45 , Kevin Grittner wrote:
> Every way I look at it, inside a REPEATABLE READ or SERIALIZABLE
> transaction a check for child rows when validating a parent DELETE
> should consider both rows which exist according to the transaction
> snapshot and according to a "current" snap
On Fri, Oct 24, 2014 at 11:43 AM, Ali Akbar wrote:
>
> 2014-10-24 16:26 GMT+07:00 Pavel Stehule :
>
>> Hi
>>
>> some in last patch is wrong, I cannot to compile it:
>>
>> arrayfuncs.c: In function 'accumArrayResult':
>> arrayfuncs.c:4603:9: error: 'ArrayBuildState' has no member named 'alen'
>>
On 2014-10-24 15:59:30 +0530, Amit Kapila wrote:
> > > and w.r.t performance it can lead extra
> > > function call, few checks and I think in some cases even can
> > > acquire/release spinlock.
> >
> > I fail to see how that could be the case.
>
> Won't it happen incase first backend sets releaseO
On Wed, Oct 22, 2014 at 8:04 PM, Andres Freund
wrote:
> On 2014-10-21 19:56:05 +0530, Amit Kapila wrote:
> > On Wed, Oct 8, 2014 at 6:17 PM, Andres Freund
> > wrote:
> > spin_delay_count gives
> > how much delay has happened to acquire spinlock which when
> > combined with other stats gives the c
> >> Sorry, I'm going around in the circle. But I'd like to say again, I
> >> don't think this is good idea. It prevents asynchronous
> >> pg_receivexlog from fsyncing WAL data and sending feedbacks more
> >> frequently at all. They are useful, for example, when we want to
> >> monitor the write lo
On 2014-10-24 07:18:55 -0300, Alvaro Herrera wrote:
> Jeevan Chalke wrote:
>
> > Regarding Directory Error:
> > ===
> > I strongly against the proposal. This patch changing error message to
> > something like this:
> > "psql:blah:0: Input path is a directory. Use pg_restore to restore
> > director
Jeevan Chalke wrote:
> Regarding Directory Error:
> ===
> I strongly against the proposal. This patch changing error message to
> something like this:
> "psql:blah:0: Input path is a directory. Use pg_restore to restore
> directory-format database dumps."
>
> So even though I accidentally provide
Hi all
Following on from my recent patch about adding a hint to psql when you
try to use it to apply a custom-format dump:
http://www.postgresql.org/message-id/544096e0.5020...@2ndquadrant.com
I think we should do the same for the command line tools, like createdb,
createuser, etc.
I've seen th
Hello, I have a problem with PostgreSQL. I need to install PostgreSQL on ARMv5
with tcp/ip access, but I have no experience in it. I trying to do it in LTIB
and now I need to create a postgresql.spec file. Could you help me in it?
With best regards,
Alexandr Glukhov
2014-10-24 16:26 GMT+07:00 Pavel Stehule :
> Hi
>
> some in last patch is wrong, I cannot to compile it:
>
> arrayfuncs.c: In function ‘accumArrayResult’:
> arrayfuncs.c:4603:9: error: ‘ArrayBuildState’ has no member named ‘alen’
>astate->alen = 64; /* arbitrary starting array size */
>
Hi
some in last patch is wrong, I cannot to compile it:
arrayfuncs.c: In function ‘accumArrayResult’:
arrayfuncs.c:4603:9: error: ‘ArrayBuildState’ has no member named ‘alen’
astate->alen = 64; /* arbitrary starting array size */
^
arrayfuncs.c:4604:9: error: ‘ArrayBuildState’ has no
2014-10-24 15:48 GMT+07:00 Pavel Stehule :
> Hi
>
> it looks well
>
> doc:
> http://www.postgresql.org/docs/9.4/static/sql-expressions.html#SQL-SYNTAX-ARRAY-CONSTRUCTORS
> it should be fixed too
>
> Regards
>
> Pavel
>
doc updated with additional example for array(subselect). patch attached.
Reg
Hi
it looks well
doc:
http://www.postgresql.org/docs/9.4/static/sql-expressions.html#SQL-SYNTAX-ARRAY-CONSTRUCTORS
it should be fixed too
Regards
Pavel
2014-10-24 10:24 GMT+02:00 Ali Akbar :
> Updated patch attached.
>
> 2014-10-22 20:51 GMT+07:00 Pavel Stehule :
>
>> I agree with you
On Thu, Sep 25, 2014 at 12:38 PM, Heikki Linnakangas <
hlinnakan...@vmware.com> wrote:
> On 09/24/2014 05:48 PM, Abhijit Menon-Sen wrote:
>
>> Updated patches attached.
>>
>
> Thanks, applied some version of these.
>
This set of patches has been applied as b0d81ad but patch 0001 did not make
it in
Hi, here is the revised patch.
Attached files are the followings
- 0001-ALTER-ROLE-CURRENT_USER_v2.patch - the patch.
- testset.tar.bz2 - test set. Run by typing 'make check' as a
superuser of the running postgreSQL server. It creates "testdb"
and some roles.
Documents are not edited t
Updated patch attached.
2014-10-22 20:51 GMT+07:00 Pavel Stehule :
> I agree with your proposal. I have a few comments to design:
>
> 1. patch doesn't hold documentation and regress tests, please append
> it.
>
i've added some regression tests in arrays.sql and a
One of the queries in ri_triggers.c has be a little baffled.
For (relatively) obvious reasons, a FK insert triggers a SELECT 1 FROM
pk_rel ... FOR KEY SHARE.
For not-so-obvious reasons, a PK delete triggers a SELECT 1 FROM fk_rel ...
FOR KEY SHARE.
I can't see what the lock on fk_rel achieves. Bo
On Wed, Oct 22, 2014 at 7:12 PM, Andres Freund
wrote:
>
> On 2014-10-22 13:32:07 +0530, Amit Kapila wrote:
> > On Tue, Oct 21, 2014 at 7:56 PM, Amit Kapila
> > wrote:
> > > On Wed, Oct 8, 2014 at 6:17 PM, Andres Freund
> > wrote:
> > > >
> > > > On 2014-06-25 19:06:32 +0530, Amit Kapila wrote:
>
On Fri, Oct 24, 2014 at 8:26 AM, Dave Page wrote:
> On Fri, Oct 24, 2014 at 7:18 AM, Peter Eisentraut wrote:
> > On 10/21/14 1:16 PM, Tom Lane wrote:
> >> If you do any Postgres development on OS X, you've probably gotten
> >> seriously annoyed by the way that, every single time you reinstall th
96 matches
Mail list logo
