On Sat, Dec 28, 2013 at 10:36:19PM -0500, Peter Eisentraut wrote:
While playing around with the pginclude tools, I noticed that pgcrypto
header files are failing to include some header files whose symbols they
use. This change would fix it:
diff --git a/contrib/pgcrypto/pgp.h
On 12/30/2013 01:22 AM, Sergey Konoplev wrote:
On Sun, Dec 29, 2013 at 8:44 AM, knizhnik knizh...@garret.ru wrote:
create function volume(r base_table) returns integer as $$ begin return
r.x*r.y; end; $$ language plpgsql strict stable;
create function volume(r derived_table) returns integer as
On 2013-12-29 02:48:21 -0500, Tom Lane wrote:
4. The server tries to start, and fails because it can't find a WAL file
containing the last checkpoint record. This is pretty unsurprising given
the facts above. The reason you don't see any no such file report is
that XLogFileRead() will report
On 12/30/2013 05:57 AM, Peter Geoghegan wrote:
Now, when you actually posted the prototype, I realized that it was
the same basic design that I'd cited in my very first e-mail on the
IGNORE patch (the one that didn't have row locking at all) - nobody
else wanted to do heap insertion first for
On 2013-12-29 19:57:31 -0800, Peter Geoghegan wrote:
On Sun, Dec 29, 2013 at 8:18 AM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
My position is not based on a gut feeling. It is based on carefully
considering the interactions of the constituent parts, plus the
experience of actually
On Mon, Dec 30, 2013 at 2:03 AM, knizhnik knizh...@garret.ru wrote:
On 12/30/2013 01:22 AM, Sergey Konoplev wrote:
On Sun, Dec 29, 2013 at 8:44 AM, knizhnik knizh...@garret.ru wrote:
But passing direved_table type instead of base_table type to volume()
function for record belonging to
Hi there,
I created two patches improving the log messages generated by
log_lock_waits. The first patch shows the process IDs holding a lock
we try to acquire (show_pids_in_lock_log.patch), sample output
(log_lock_waits=on required):
session 1: BEGIN; LOCK TABLE foo IN SHARE MODE;
session 2:
On Mon, Dec 30, 2013 at 8:19 AM, Andres Freund and...@2ndquadrant.com wrote:
Maybe you should describe what you mean with unprincipled. Sure, the
current patch deadlocks, but I don't see anything fundamental,
unresolvable there. So I don't understand what the word unprincipled
means in that
On 2013-12-30 12:29:22 -0800, Peter Geoghegan wrote:
But even if that wasn't
true, I don't know why you feel the need to go on and on about buffer
locking like this months later. Are you trying to be provocative? Can
you *please* stop?
ERR? Peter? *You* quoted a statement of mine that only
On 12/30/2013 12:45 PM, Andres Freund wrote:
On 2013-12-30 12:29:22 -0800, Peter Geoghegan wrote:
But even if that wasn't
true, I don't know why you feel the need to go on and on about buffer
locking like this months later. Are you trying to be provocative? Can
you *please* stop?
ERR? Peter?
On Mon, Dec 30, 2013 at 7:22 AM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
Ah, I didn't remember that thread. Yeah, apparently I proposed the exact
same design back then. Simon complained about the dead tuples being left
behind, but I don't think that's a big issue with the design we've
It seems fine to me if the new function ignores the specific error of
relation does not exist while continuing to throw other errors.
Thanks. Here is the revised conceptual patch. I'm going to post a
concrete patch and register it to 2014-01 Commit Fest.
Before proceeding the work, I would
On 12/31/2013 02:38 AM, Tatsuo Ishii wrote:
Before proceeding the work, I would like to make sure that followings
are complete list of new functions. Inside parentheses are
corresponding original functions.
toregproc (regproc)
toregoper (regoper)
toregclass (regclass)
toregtype (regtype)
Alvaro Herrera wrote:
1. slru.c doesn't consider file names longer than 4 hexadecimal chars.
For 9.3, I propose we skip this and tweak the code to consider files
whose names are 4 or 5 chars in length, to remain compatible with
existing installations that have pg_multixact/member having a
On Mon, Dec 30, 2013 at 11:08 AM, David Rowley dgrowle...@gmail.com wrote:
On Mon, Dec 30, 2013 at 6:02 PM, Amit Kapila amit.kapil...@gmail.com
wrote:
For Windows build, I am using whatever latest Git provides rather than
downloading
individual components which might not be good, but I find
On 12/31/2013 02:38 AM, Tatsuo Ishii wrote:
Before proceeding the work, I would like to make sure that followings
are complete list of new functions. Inside parentheses are
corresponding original functions.
toregproc (regproc)
toregoper (regoper)
toregclass (regclass)
toregtype (regtype)
In src/include/pgstat.h, the PGSTAT_NUM_TABENTRIES macro
attempts to subtract off the size of the PgStat_MsgTabstat
struct up to the m_entry[] field. This macro was correct up
until the fields m_block_read_time and m_block_write_time
were added to that struct, as the macro was not changed to
On Sun, Dec 29, 2013 at 9:09 AM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
While mulling this over further, I had an idea about this: suppose we
marked the tuple in some fashion that indicates that it's a promise
tuple. I imagine an infomask bit, although the concept makes me wince
a
18 matches
Mail list logo
