On Mon, Oct 06, 2014 at 08:57:54PM -0400, Tom Lane wrote:
I eventually realized that the critical difference was you'd added
CFLAGS= to the configure call. On this platform that has the net
effect of removing -O2 from the compiler flags, and apparently that
shifts around the stack layout
On 10/08/2014 07:23 AM, furu...@pm.nttdata.co.jp wrote:
What set of options would you pass if you want to use it as a synchronous
standby? And if you don't? Could we just have a single --synchronous
flag, instead of -F and --reply-fsync?
If you set synchronous_commit as remote_write, the
Amit Kapilaamit.kapil...@gmail.com
On Tue, Oct 7, 2014 at 8:13 PM, Sawada Masahiko sawada.m...@gmail.com
javascript:_e(%7B%7D,'cvml','sawada.m...@gmail.com'); wrote:
On Tue, Oct 7, 2014 at 12:58 PM, Amit Kapila amit.kapil...@gmail.com
javascript:_e(%7B%7D,'cvml','amit.kapil...@gmail.com');
On Tue, 2014-10-07 at 13:33 +0100, Simon Riggs wrote:
Is there a way of detecting that we are updating a unique constraint
column and then applying the HW locking only in that case? Or can we
only apply locking when we have multiple unique constraints on a
table?
What is the use case of doing
On Fri, Sep 19, 2014 at 1:07 AM, Jehan-Guillaume de Rorthais
j...@dalibo.com wrote:
We kept the WAL files and log files for further analysis. How can we help
regarding this issue?
Commit c2f79ba has added as assumption that the WAL receiver should always
enforce the create of .done files
On Wed, Oct 8, 2014 at 12:41 AM, Anssi Kääriäinen
anssi.kaariai...@thl.fi wrote:
The MySQL documentation says that you should try to avoid using an ON
DUPLICATE KEY UPDATE clause on tables with multiple unique indexes[1].
The proposed feature's documentation has the same suggestion[2]. Still,
On 10/08/2014 11:10 AM, Peter Geoghegan wrote:
The reasoning behind making the unique index specification optional is:
We cannot easily cover corner cases with another syntax - unique
indexes must be named directly to cover every case, and make the
user's intent absolutely clear. That's not
On Wed, Oct 8, 2014 at 3:47 AM, Peter Geoghegan p...@heroku.com wrote:
It seems like what you're talking about here is just changing the
spelling of what I already have.
I think there's a subtle difference in expectations too. The current
BEFORE INSERT trigger behavior is somewhat defensible
Hello.
I am interested in the json type on postgresql. I would like to implement
additional operations on the json structure that may extract/insert table
like information from the json tree structure.
I have a implementation on javascript that shows this type of operations.
You can see examples
On 10/08/2014 07:23 AM, furu...@pm.nttdata.co.jp wrote:
What set of options would you pass if you want to use it as a
synchronous standby? And if you don't? Could we just have a single
--synchronous
flag, instead of -F and --reply-fsync?
If you set synchronous_commit as remote_write,
On Wed, Oct 8, 2014 at 1:25 AM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
Instead of naming the index, you should name the columns, and the system can
look up the index or indexes that match those columns.
It's not totally clear that we need *any* WITHIN clause, BTW. I'm not
dead set on
On Wed, Oct 8, 2014 at 1:36 AM, Marti Raudsepp ma...@juffo.org wrote:
I think there's a subtle difference in expectations too. The current
BEFORE INSERT trigger behavior is somewhat defensible with an
INSERT-driven syntax (though I don't like it even now [1]).
There is no way around it. We
On Tue, Oct 7, 2014 at 2:27 PM, Marti Raudsepp ma...@juffo.org wrote:
but the new approach seems
surprising: changes from BEFORE INSERT get persisted in the database,
but AFTER INSERT is not fired.
I am sorry, I realize now that I misunderstood the current proposed
trigger behavior, I thought
On 10/08/2014 10:44 AM, Michael Paquier wrote:
On Fri, Sep 19, 2014 at 1:07 AM, Jehan-Guillaume de Rorthais
j...@dalibo.com wrote:
We kept the WAL files and log files for further analysis. How can we help
regarding this issue?
Commit c2f79ba has added as assumption that the WAL receiver
On Wed, 2014-10-08 at 02:22 -0700, Peter Geoghegan wrote:
On Wed, Oct 8, 2014 at 1:25 AM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
Instead of naming the index, you should name the columns, and the system can
look up the index or indexes that match those columns.
It's not totally
On Wed, 2014-10-08 at 01:10 -0700, Peter Geoghegan wrote:
On Wed, Oct 8, 2014 at 12:41 AM, Anssi Kääriäinen
anssi.kaariai...@thl.fi wrote:
The MySQL documentation says that you should try to avoid using an ON
DUPLICATE KEY UPDATE clause on tables with multiple unique indexes[1].
The
On Wed, Oct 8, 2014 at 12:28 PM, Peter Geoghegan p...@heroku.com wrote:
On Wed, Oct 8, 2014 at 1:36 AM, Marti Raudsepp ma...@juffo.org wrote:
I think there's a subtle difference in expectations too. The current
BEFORE INSERT trigger behavior is somewhat defensible with an
INSERT-driven syntax
On Tue, Oct 7, 2014 at 3:46 AM, Robert Haas robertmh...@gmail.com wrote:
On Mon, Oct 6, 2014 at 5:57 AM, David Rowley dgrowle...@gmail.com wrote:
Can anyone shed any light on how I might determine where the scan rel is
in
the tree? I need to find it so I can check if the RangeTblEntry is
On 2014-10-09 00:21:44 +1300, David Rowley wrote:
Ok, so I've been hacking away at this for a couple of evenings and I think
I have a working prototype finally!
Cool!
So it seems it's not quite as efficient as join removal at planning time,
but still a big win when it's possible to perform
On 10/08/2014 11:47 AM, furu...@pm.nttdata.co.jp wrote:
On 10/08/2014 07:23 AM, furu...@pm.nttdata.co.jp wrote:
What set of options would you pass if you want to use it as a
synchronous standby? And if you don't? Could we just have a single
--synchronous
flag, instead of -F and --reply-fsync?
On 2014-06-25 19:06:32 +0530, Amit Kapila wrote:
2.
LWLockWakeup()
{
..
#ifdef LWLOCK_STATS
lwstats-spin_delay_count += SpinLockAcquire(lock-mutex);
#else
SpinLockAcquire(lock-mutex);
#endif
..
}
Earlier while releasing lock, we don't count it towards LWLock stats
spin_delay_count.
On 2014-10-08 14:47:44 +0200, Andres Freund wrote:
On 2014-06-25 19:06:32 +0530, Amit Kapila wrote:
5.
LWLockWakeup()
{
..
dlist_foreach_modify(iter, (dlist_head *) wakeup)
{
PGPROC *waiter = dlist_container(PGPROC, lwWaitLink, iter.cur);
LOG_LWDEBUG(LWLockRelease, l, mode,
On Wed, Oct 8, 2014 at 6:54 PM, Heikki Linnakangas hlinnakan...@vmware.com
wrote:
1. Where do the FF files come from? In 9.2, FF-segments are not supposed
to created, ever.
Since this only happens with streaming replication, the FF segments are
probably being created by walreceiver.
On 8 October 2014 01:47, Peter Geoghegan p...@heroku.com wrote:
It seems like what you're talking about here is just changing the
spelling of what I already have. I think that would be confusing to
users when the time comes to actually implement a fully-generalized
MERGE, even with the
On 8 October 2014 00:34, Peter Geoghegan p...@heroku.com wrote:
INSERTs see #2 win, and by a wider margin than #1 beat #2 with
UPDATEs. However, insert.sh is by design very unsympathetic towards
#1. It uses a serial primary key, so every INSERT uselessly obtains a
HW lock on the same leaf
Hi,
Attached you can find the next version of my LW_SHARED patchset. Now
that atomics are committed, it seems like a good idea to also add their
raison d'être.
Since the last public version I have:
* Addressed lots of Amit's comments. Thanks!
* Peformed a fair amount of testing.
* Rebased the
On Wed, Sep 24, 2014 at 11:10 AM, Etsuro Fujita
fujita.ets...@lab.ntt.co.jp wrote:
(2014/09/13 2:42), Fujii Masao wrote:
On Wed, Sep 10, 2014 at 10:37 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Fujii Masao wrote:
On Wed, Sep 10, 2014 at 12:15 PM, Etsuro Fujita
On Wed, Oct 8, 2014 at 6:54 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
On 10/08/2014 10:44 AM, Michael Paquier wrote:
On Fri, Sep 19, 2014 at 1:07 AM, Jehan-Guillaume de Rorthais
j...@dalibo.com wrote:
We kept the WAL files and log files for further analysis. How can we help
On 2014-09-29 13:38:37 -0400, Robert Haas wrote:
On Mon, Sep 29, 2014 at 12:05 PM, Stephen Frost sfr...@snowman.net wrote:
Lastly, I will say that I feel it'd be good to support bi-directional
communication as I think it'll be needed eventually, but I'm not sure
that has to happen now.
I
On 2014-09-10 16:53:12 -0400, Robert Haas wrote:
diff --git a/src/include/libpq/libpq.h b/src/include/libpq/libpq.h
index 5da9d8d..0b8db42 100644
--- a/src/include/libpq/libpq.h
+++ b/src/include/libpq/libpq.h
@@ -37,6 +37,31 @@ typedef struct
} u;
} PQArgBlock;
On 10/08/2014 04:38 AM, Paweł Cesar Sanjuan Szklarz wrote:
Hello.
I am interested in the json type on postgresql. I would like to
implement additional operations on the json structure that may
extract/insert table like information from the json tree structure.
I have a implementation on
On 10/08/2014 04:59 PM, Fujii Masao wrote:
On Wed, Oct 8, 2014 at 6:54 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
Instead of creating any .done files during recovery, we could scan pg_xlog
at promotion, and create a .done file for every WAL segment that's present
at that point. That
On Wed, Oct 8, 2014 at 4:25 PM, Andrew Dunstan and...@dunslane.net wrote:
On 10/08/2014 04:38 AM, Paweł Cesar Sanjuan Szklarz wrote:
Hello.
I am interested in the json type on postgresql. I would like to implement
additional operations on the json structure that may extract/insert table
On Wed, Oct 8, 2014 at 8:47 AM, Andres Freund and...@2ndquadrant.com wrote:
I don't see that as being relevant. The difference is an instruction or
two - in the slow path we'll enter the kernel and sleep. This doesn't
matter in comparison.
And the code is *so* much more readable.
I find the
On 2014-10-08 13:13:33 -0400, Robert Haas wrote:
On Wed, Oct 8, 2014 at 8:47 AM, Andres Freund and...@2ndquadrant.com wrote:
I don't see that as being relevant. The difference is an instruction or
two - in the slow path we'll enter the kernel and sleep. This doesn't
matter in comparison.
Robert Haas wrote:
On Wed, Oct 8, 2014 at 8:47 AM, Andres Freund and...@2ndquadrant.com wrote:
I don't see that as being relevant. The difference is an instruction or
two - in the slow path we'll enter the kernel and sleep. This doesn't
matter in comparison.
And the code is *so* much more
On 10/08/2014 12:13 PM, Paweł Cesar Sanjuan Szklarz wrote:
I don't think we need to import Mongo type notation here. But
there is probably a good case for some functions like:
json_table_agg(anyrecord) - json
which would work like json_agg() but would return an array of
Hi,
Am Samstag, den 04.10.2014, 15:05 -0500 schrieb Jim Nasby:
On 10/4/14, 1:21 PM, Jeff Janes wrote:
On Thu, Oct 2, 2014 at 6:21 AM, Michael Banck wrote:
we have seen repeatedly that users can be confused about why PostgreSQL
is not shutting down even though they requested it.
On 2014-10-08 14:23:44 -0300, Alvaro Herrera wrote:
Robert Haas wrote:
On Wed, Oct 8, 2014 at 8:47 AM, Andres Freund and...@2ndquadrant.com
wrote:
I don't see that as being relevant. The difference is an instruction or
two - in the slow path we'll enter the kernel and sleep. This
On Mon, Sep 29, 2014 at 7:21 AM, Simon Riggs si...@2ndquadrant.com wrote:
Having said that, it would be much nicer to have a mode that allows
you to just say the word UPDATE and have it copy the data into the
correct columns, like MySQL does. That is very intuitive, even if it
isn't very
On 10/08/2014 02:04 PM, Thom Brown wrote:
There is work already being done on providing update operations.
I've been looking out for that. Has there been a discussion on how
that would look yet that you could point me to?
https://github.com/erthalion/jsonbx
Note that a) it's an
On 2014-10-08 15:23:22 -0400, Robert Haas wrote:
On Wed, Oct 8, 2014 at 9:35 AM, Andres Freund and...@2ndquadrant.com wrote:
1) Convert PGPROC-lwWaitLink into a dlist. The old code was frail and
verbose. This also does:
* changes the logic in LWLockRelease() to release all shared
On Wed, Oct 8, 2014 at 9:35 AM, Andres Freund and...@2ndquadrant.com wrote:
2) Implement the wait free LW_SHARED algorithm.
+ * too high for workloads/locks that were locked in shared mode very
s/locked/taken/?
+ * frequently. Often we were spinning in the (obviously exlusive) spinlock,
On Wed, Oct 8, 2014 at 6:25 AM, Simon Riggs si...@2ndquadrant.com wrote:
I change my view on this, after some more thought. (Hope that helps)
Great.
If we implement MERGE, I can see we may also wish to implement MERGE
CONCURRENTLY one day. That would be different to UPSERT.
So in the future
On 08/10/14 21:03, Robert Haas wrote:
On Wed, Oct 8, 2014 at 10:09 AM, Andres Freund and...@2ndquadrant.com wrote:
WRT my complaint in the other subthread, I think PQsendMethods should
just be renamed to PQcommMethods or similar. That'd, in combination with
a /* at some point we might want to
On Mon, Oct 6, 2014 at 8:35 AM, Robert Haas robertmh...@gmail.com wrote:
I think the problem is that it's not possible to respect the usual
guarantees even at READ COMMITTED level when performing an INSERT OR
UPDATE operation (however spelled). You may find that there's a tuple
with the same
On 08/10/14 11:28, Peter Geoghegan wrote:
On Wed, Oct 8, 2014 at 1:36 AM, Marti Raudsepp ma...@juffo.org wrote:
But the
MERGE syntax, to me, strongly implies that insertion doesn't begin
before determining whether a conflict exists or not.
I think you're right. Another strike against the
Peter Geoghegan p...@heroku.com wrote:
On Tue, Oct 7, 2014 at 5:23 AM, Simon Riggs si...@2ndquadrant.com wrote:
IIRC it wasn't agreed that we needed to identify which indexes in the
upsert SQL statement itself, since this would be possible in other
ways and would require programmers to know
On 8 October 2014 21:16, Peter Geoghegan p...@heroku.com wrote:
My opinion is that syntax for this should be similar to MERGE in the
*body* of the command, rather than some completely different syntax.
e.g.
WHEN NOT MATCHED THEN
INSERT
WHEN MATCHED THEN
UPDATE
I'm happy that we put
Peter Geoghegan p...@heroku.com wrote:
On Mon, Oct 6, 2014 at 8:35 AM, Robert Haas robertmh...@gmail.com wrote:
I think the problem is that it's not possible to respect the usual
guarantees even at READ COMMITTED level when performing an INSERT OR
UPDATE operation (however spelled). You may
On 2014-10-08 22:13:46 +0300, Heikki Linnakangas wrote:
Hmm. So the simple, non-table driven, calculation gives the same result as
using the lookup table using the reflected lookup code. That's expected; the
lookup method is supposed to be the same, just faster. However, using the
normal
About patch 1, which I just pushed, there were two reviews:
Andres Freund wrote:
On 2014-09-25 18:59:31 -0300, Alvaro Herrera wrote:
diff --git a/src/include/utils/ruleutils.h b/src/include/utils/ruleutils.h
new file mode 100644
index 000..520b066
--- /dev/null
+++
Peter Geoghegan p...@heroku.com wrote:
On Wed, Oct 8, 2014 at 1:25 AM, Heikki Linnakangas hlinnakan...@vmware.com
wrote:
Instead of naming the index, you should name the columns, and
the system can look up the index or indexes that match those
columns.
+1
That is what I have been
* Fabrízio de Royes Mello (fabriziome...@gmail.com) wrote:
On Tue, Oct 7, 2014 at 1:24 PM, Simon Riggs si...@2ndquadrant.com wrote:
I hope we can get pgAudit in as a module for 9.5. I also hope that it
will stimulate the requirements/funding of further work in this area,
rather than squash
On Wed, Oct 8, 2014 at 2:50 PM, Kevin Grittner kgri...@ymail.com wrote:
What I said was in response to your assertion that your technique
would *never* generate a duplicate key error.
That is strictly true: the INSERT cannot raise a unique violation
error, because to do so would cause it to
On 09/10/14 10:13, Andres Freund wrote:
On 2014-10-08 22:13:46 +0300, Heikki Linnakangas wrote:
Hmm. So the simple, non-table driven, calculation gives the same result as
using the lookup table using the reflected lookup code. That's expected; the
lookup method is supposed to be the same, just
On Wed, Oct 8, 2014 at 2:04 PM, Simon Riggs si...@2ndquadrant.com wrote:
While I am also happy with taking a vote, if we do so I vote against
even this much less MERGE-like syntax. It's verbose, and makes much
less sense when the mechanism is driven by would-be duplicate key
violations rather
/*
+ * Arrange to remove a dynamic shared memory mapping at cleanup time.
+ *
+ * dsm_keep_mapping() can be used to preserve a mapping for the entire
+ * lifetime of a process; this function reverses that decision, making
+ * the segment owned by the current resource owner. This may be
On Wed, Oct 8, 2014 at 2:01 PM, Kevin Grittner kgri...@ymail.com wrote:
Although the last go-around does suggest that there is at least one
point of difference on the semantics. You seem to want to fire the
BEFORE INSERT triggers before determining whether this will be an
INSERT or an UPDATE.
On Wed, Oct 8, 2014 at 11:38 PM, Heikki Linnakangas hlinnakan...@vmware.com
wrote:
On 10/08/2014 04:59 PM, Fujii Masao wrote:
On Wed, Oct 8, 2014 at 6:54 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
Instead of creating any .done files during recovery, we could scan
pg_xlog
at
On Thu, Oct 9, 2014 at 6:26 AM, Alvaro Herrera alvhe...@2ndquadrant.com
wrote:
About patch 1, which I just pushed, there were two reviews:
Andres Freund wrote:
On 2014-09-25 18:59:31 -0300, Alvaro Herrera wrote:
diff --git a/src/include/utils/ruleutils.h
b/src/include/utils/ruleutils.h
On Thu, Oct 9, 2014 at 1:51 AM, Peter Geoghegan p...@heroku.com wrote:
On Wed, Oct 8, 2014 at 2:01 PM, Kevin Grittner kgri...@ymail.com wrote:
Although the last go-around does suggest that there is at least one
point of difference on the semantics. You seem to want to fire the
BEFORE INSERT
On 14/10/09 7:06, Stephen Frost wrote:
* Fabrízio de Royes Mello (fabriziome...@gmail.com) wrote:
On Tue, Oct 7, 2014 at 1:24 PM, Simon Riggs si...@2ndquadrant.com wrote:
I hope we can get pgAudit in as a module for 9.5. I also hope that it
will stimulate the requirements/funding of further
On Wed, Oct 8, 2014 at 4:30 PM, Marti Raudsepp ma...@juffo.org wrote:
On Thu, Oct 9, 2014 at 1:51 AM, Peter Geoghegan p...@heroku.com wrote:
On Wed, Oct 8, 2014 at 2:01 PM, Kevin Grittner kgri...@ymail.com wrote:
Although the last go-around does suggest that there is at least one
point of
On Wed, Oct 8, 2014 at 2:04 PM, Andres Freund and...@2ndquadrant.com wrote:
So, what makes it work for me (among other unrelated stuff) seems to be
the following in .gdbinit, defineing away some things that gdb doesn't
handle:
macro define __builtin_offsetof(T, F) ((int) (((T *) 0)-F))
macro
On Wed, Oct 8, 2014 at 2:55 AM, David Fetter da...@fetter.org wrote:
On Wed, Oct 08, 2014 at 12:41:46AM -0300, Fabrízio de Royes Mello wrote:
On Wed, Oct 8, 2014 at 12:36 AM, Josh Berkus j...@agliodbs.com wrote:
On 10/07/2014 09:44 AM, Fabrízio de Royes Mello wrote:
We can think in a
On Thu, Oct 9, 2014 at 2:46 AM, Peter Geoghegan p...@heroku.com wrote:
Indeed, the current behavior breaks even the canonical keep track of
how many posts are in a thread trigger example
use an AFTER trigger for this kind of thing, and all of these
issues go away.
In the latest patches from
On Wed, Oct 8, 2014 at 6:12 PM, Marti Raudsepp ma...@juffo.org wrote:
Oh, one more consideration: I believe you will run into the same issue
if you want to implement BEFORE UPDATE triggers in any form. Skipping
BEFORE UPDATE entirely seems to violate POLA.
Good thing that the patch doesn't do
On Thu, Oct 9, 2014 at 4:56 AM, Marti Raudsepp ma...@juffo.org wrote:
create trigger ev1 before insert on evt_type execute procedure ins();
create trigger ev2 before update on evt_type execute procedure upd();
create trigger ev3 after insert on evt_type execute procedure ins();
create trigger
On Wed, Oct 8, 2014 at 7:04 PM, Marti Raudsepp ma...@juffo.org wrote:
Oops, I missed for each row here.
Note that I have an open item for what to do about statement level
triggers here: https://wiki.postgresql.org/wiki/UPSERT
I'm not satisfied with the current behavior. It needs more
(2014/10/08 22:51), Fujii Masao wrote:
On Wed, Sep 24, 2014 at 11:10 AM, Etsuro Fujita
fujita.ets...@lab.ntt.co.jp wrote:
On Wed, Sep 10, 2014 at 10:37 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Fujii Masao wrote:
On Wed, Sep 10, 2014 at 12:15 PM, Etsuro Fujita
On Wed, Oct 8, 2014 at 11:22 PM, Robert Haas robertmh...@gmail.com wrote:
On Sun, Jun 29, 2014 at 9:12 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Meh. Even SELECT 1 is going to be doing *far* more pallocs than that
to
get through raw parsing, parse analysis, planning, and execution
startup.
On Thu, Oct 9, 2014 at 4:02 AM, Andres Freund and...@2ndquadrant.com
wrote:
/*
+ * Arrange to remove a dynamic shared memory mapping at cleanup time.
+ *
+ * dsm_keep_mapping() can be used to preserve a mapping for the entire
+ * lifetime of a process; this function reverses that
What set of options would you pass if you want to use it as a
synchronous standby? And if you don't? Could we just have a single
--synchronous
flag, instead of -F and --reply-fsync?
If you set synchronous_commit as remote_write, the options would
be different .
The set of options
Hello, simplly inhibit set retry flag when ProcDiePending in
my_sock_write seems enough.
But it returns with SSL_ERROR_SYSCALL not SSL_ERROR_WANT_WRITE so
I modified the patch 4 as the attached patch.
Finally, the attached patch works as expected with Andres's patch
1-3.
regards,
--
Kyotaro
On 8 October 2014 23:24, Peter Geoghegan p...@heroku.com wrote:
Also, it would be useful to hear that your're going to do something
about the references to rows using conflicting(), since nobody has
agreed with you there. Or hopefully even that you've listened and
implemented something
76 matches
Mail list logo
