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 b/contrib/
On 12/30/2013 01:22 AM, Sergey Konoplev wrote:
On Sun, Dec 29, 2013 at 8:44 AM, knizhnik 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 $$ begin return
r.x
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 r
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 pro
On 2013-12-29 19:57:31 -0800, Peter Geoghegan wrote:
> On Sun, Dec 29, 2013 at 8:18 AM, Heikki Linnakangas
> 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 building a w
On Mon, Dec 30, 2013 at 2:03 AM, knizhnik wrote:
> On 12/30/2013 01:22 AM, Sergey Konoplev wrote:
>> On Sun, Dec 29, 2013 at 8:44 AM, knizhnik wrote:
>>> But passing direved_table type instead of base_table type to volume()
>>> function for record belonging to derived_table seems to be possible a
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: BEGI
On Mon, Dec 30, 2013 at 8:19 AM, Andres Freund 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 sentence..
Maybe i
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 Mon, Dec 30, 2013 at 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*
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
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 been
> playing aroun
>> 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,
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 (reg
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 wrote:
> On Mon, Dec 30, 2013 at 6:02 PM, Amit Kapila
> wrote:
>> For Windows build, I am using whatever latest Git provides rather than
>> downloading
>> individual components which might not be good, but I find it
>> convenient. The latest
>> Git (
> 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)
>> tore
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
inclu
On Sun, Dec 29, 2013 at 9:09 AM, Heikki Linnakangas
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 bit since we
19 matches
Mail list logo
