On Wed, Dec 25, 2013 at 6:05 PM, Joel Jacobson wrote:
> Hi,
>
> I've tried to fix some bugs reported by Andrey Karpov in an article at
> http://www.viva64.com/en/b/0227/
>
> The value returned by socket() is unsigned on Windows and can thus not
> be checked if less than zero to detect an error, in
On Wed, Jan 1, 2014 at 12:52 AM, Pavel Stehule wrote:
> 2013/12/31 Alvaro Herrera
>>
>> I'm not sure I understand this. Do you want to avoid running the
>> checker if a previous run was seen as successful and function has not
>> changed? Suppose the function depends on a table. I invoke the ch
On 12/28/2013 04:51 PM, Alexander Korotkov wrote:
I've compiled it with clang. Yeah, there was mixed declarations. I've
rechecked it with gcc, now it gives no warnings. I didn't try it with
visual studio, but I hope it will be OK.
I looked at this version of the patch and noticed a possibility
2013/12/31 Tom Lane
> Pavel Stehule writes:
> > Requested feature doesn't help me implement this concept 100%, but helps
> > with check If I worked with some instance of function or not. And inside
> > core a implementation is cheap. Outside core it is a magic with hash and
> > checking transact
Peter pointed out in
http://www.postgresql.org/message-id/527c0fe9.7000...@gmx.net
that Kyotaro-san's patch to treat unique indexes as satisfying any sort
condition that they are a prefix of broke the drop-index-concurrently-1
isolation test. The latest iterations of the patch respond to that by
c
On Tue, Dec 31, 2013 at 1:12 AM, Christian Kruse
wrote:
> I created a patch improving the log_lock_wait messages by adding
> relation infos (name and OID) as well as tuple infos (if present –
> ctid and, if available, the tuple itself) in the context.
I think that this is a worthwhile effort, but
The BDR documentation
http://wiki.postgresql.org/images/7/75/BDR_Presentation_PGCon2012.pdf
says,
"Physical replication forces us to use just one
node: multi-master required for write scalability"
"Physical replication provides best read scalability"
I am inclined to agree with the
"Etsuro Fujita" writes:
> [ pathkey_and_uniqueindx_v7_20131203.patch ]
I started to look at this patch. I don't understand the reason for the
foreach loop in index_pathkeys_are_extensible (and the complete lack of
comments in the patch isn't helping). Isn't it sufficient to check that
the index
Pavel Stehule writes:
> Requested feature doesn't help me implement this concept 100%, but helps
> with check If I worked with some instance of function or not. And inside
> core a implementation is cheap. Outside core it is a magic with hash and
> checking transaction id (about 200 lines). When I
Mark Dilger wrote:
> This is not entirely "pie in the sky", but feel free to tell me why this is
> crazy.
Have you seen http://wiki.postgresql.org/wiki/BDR ?
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgs
This is not entirely "pie in the sky", but feel free to tell me why this is
crazy. I
have had this idea for several years, but have not seen anyone else suggest it,
nor any arguments why it would not work.
If we had 64-bit Oids, we could reserve the top 16 bits (for instance) to
indicate a
ser
2013/12/31 Alvaro Herrera
> Pavel Stehule escribió:
> > Hello
> >
> > I am working on plpgsql_check and I would to write a protection against
> > repeated check - so I need to mark a compiled (cached) function. Now,
> > plpgsql extension can store own data to exec state, and I would to some
> > s
A quick grep through the code reveals lots of examples,
so I'll just paste the first ones I notice. There are
references to sizeof(Oid), sizeof(uint32), sizeof(bool),
and sizeof(uint8) that clearly refer to fields in structs that
the macros refer to implicitly, but there is no way for the
compile
Pavel Stehule escribió:
> Hello
>
> I am working on plpgsql_check and I would to write a protection against
> repeated check - so I need to mark a compiled (cached) function. Now,
> plpgsql extension can store own data to exec state, and I would to some
> similar for plpgsql_function. I believe so
Hello
I am working on plpgsql_check and I would to write a protection against
repeated check - so I need to mark a compiled (cached) function. Now,
plpgsql extension can store own data to exec state, and I would to some
similar for plpgsql_function. I believe so it can be useful for any plpgsql
ex
Mark Dilger writes:
> I don't care for the places in the code that say things like
> foo - sizeof(int)
> where "int" refers implicitly to a specific variable or struct field, but
> you have to remember that and change it by hand if you change the
> type of the variable or struct.
> But this
I don't care for the places in the code that say things like
foo - sizeof(int)
where "int" refers implicitly to a specific variable or struct field, but
you have to remember that and change it by hand if you change the
type of the variable or struct.
But this sort of code is quite common i
Mark Dilger writes:
> 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
On 31 December 2013 16:36, Tom Lane wrote:
> Simon Riggs writes:
>> On 31 December 2013 09:12, Christian Kruse wrote:
>>> Output with patch:
>>>
>>> LOG: process 24774 acquired ShareLock on transaction 696 after 11688.720 ms
>>> CONTEXT: relation name: foo (OID 16385)
>>> tuple (ctid (0,1)): (
Simon Riggs writes:
> On 31 December 2013 09:12, Christian Kruse wrote:
>> Output with patch:
>>
>> LOG: process 24774 acquired ShareLock on transaction 696 after 11688.720 ms
>> CONTEXT: relation name: foo (OID 16385)
>> tuple (ctid (0,1)): (1)
> That is useful info.
> I think the message s
2013/12/31 Fabrízio de Royes Mello
>
> On Tue, Dec 31, 2013 at 10:37 AM, Pavel Stehule
> wrote:
> >
> > 2013/12/31 Fabrízio de Royes Mello
> >>
> >> On Tue, Dec 31, 2013 at 9:38 AM, Pavel Stehule
> wrote:
> >> >
> >> > 2013/12/31 Fabrízio de Royes Mello
> >> >>
> >> >> On Tue, Dec 31, 2013 at
On 31 December 2013 09:12, Christian Kruse wrote:
> Output w/o patch:
>
> LOG: process 24774 acquired ShareLock on transaction 696 after 11688.720 ms
>
> Output with patch:
>
> LOG: process 24774 acquired ShareLock on transaction 696 after 11688.720 ms
> CONTEXT: relation name: foo (OID 16385)
On Tue, Dec 31, 2013 at 10:37 AM, Pavel Stehule
wrote:
>
> 2013/12/31 Fabrízio de Royes Mello
>>
>> On Tue, Dec 31, 2013 at 9:38 AM, Pavel Stehule
wrote:
>> >
>> > 2013/12/31 Fabrízio de Royes Mello
>> >>
>> >> On Tue, Dec 31, 2013 at 9:08 AM, Pavel Stehule <
pavel.steh...@gmail.com> wrote:
>>
David Rowley escribió:
> I was about to test it tonight, but I'm having trouble getting the patch to
> compile... I'm really wondering which compiler you are using as it seems
> you're declaring your variables in some strange places.. See nodeSort.c
> line 101. These variables are declared after t
2013/12/31 Fabrízio de Royes Mello
>
> On Tue, Dec 31, 2013 at 9:38 AM, Pavel Stehule
> wrote:
> >
> >
> > 2013/12/31 Fabrízio de Royes Mello
> >>
> >>
> >> On Tue, Dec 31, 2013 at 9:08 AM, Pavel Stehule
> wrote:
> >> >
> >> > Hello
> >> >
> >> > I am looking on this patch
> >> >
> >> > ALTER
On Tue, Dec 31, 2013 at 9:38 AM, Pavel Stehule
wrote:
>
>
> 2013/12/31 Fabrízio de Royes Mello
>>
>>
>> On Tue, Dec 31, 2013 at 9:08 AM, Pavel Stehule
wrote:
>> >
>> > Hello
>> >
>> > I am looking on this patch
>> >
>> > ALTER TABLE foo SET (ext.somext.do_replicate=true);
>> >
>> > Why is there
2013/12/31 Fabrízio de Royes Mello
>
> On Tue, Dec 31, 2013 at 9:08 AM, Pavel Stehule
> wrote:
> >
> > Hello
> >
> > I am looking on this patch
> >
> > ALTER TABLE foo SET (ext.somext.do_replicate=true);
> >
> > Why is there fixed prefix "ext" ?
> >
> > This feature is similar to attaching setti
On Tue, Dec 31, 2013 at 9:08 AM, Pavel Stehule
wrote:
>
> Hello
>
> I am looking on this patch
>
> ALTER TABLE foo SET (ext.somext.do_replicate=true);
>
> Why is there fixed prefix "ext" ?
>
> This feature is similar to attaching setting to function
>
> CREATE OR REPLACE FUNCTION ... SET var = ...
2013/12/31 Tatsuo Ishii
> > 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 (r
Hello
I am looking on this patch
ALTER TABLE foo SET (ext.somext.do_replicate=true);
Why is there fixed prefix "ext" ?
This feature is similar to attaching setting to function
CREATE OR REPLACE FUNCTION ... SET var = ...;
We can use someprefix.someguc without problems there.
Regards
Pavel
On Tue, Dec 31, 2013 at 12:52 AM, Heikki Linnakangas
wrote:
>> Are you suggesting that I lock the tuple only (say, through a special
>> LockPromiseTuple() call), or lock the tuple *and* call
>> XactLockTableWait() afterwards? You and Robert don't seem to be in
>> agreement about which here.
>
> I
Hi,
On 31/12/13 08:48, Simon Riggs wrote:
> > I created two patches..
>
> Patches are related but separate, so should be tracked on separate
> threads.
[x] Done (in <20131231091244.gb25...@defunct.ch>)
> Please add them to the CF app also.
[x] Done. I modified the existing commitfest entry
(
Hi there,
I created a patch improving the log_lock_wait messages by adding
relation infos (name and OID) as well as tuple infos (if present –
ctid and, if available, the tuple itself) in the context.
Sample output (log_lock_waits=on required):
session 1:
CREATE TABLE foo (val integer);
INSERT IN
On Tue, Dec 31, 2013 at 12:52 AM, Heikki Linnakangas
wrote:
> 1. PromiseTupleInsertionLockAcquire()
> 2. Insert heap tuple
> 3. Insert index tuples
> 4. Check if conflict happened. Kill the already-inserted tuple on conflict.
> 5. PromiseTupleInsertionLockRelease()
>
> IOW, the only change to the
On 12/31/2013 09:18 AM, Peter Geoghegan wrote:
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 con
On 30 December 2013 19:52, Christian Kruse wrote:
> I created two patches..
Patches are related but separate, so should be tracked on separate
threads. Please add them to the CF app also.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Train
On Tue, Dec 31, 2013 at 2:41 PM, Andreas Karlsson wrote:
> On 12/29/2013 08:24 AM, David Rowley wrote:
>
>> If it was possible to devise some way to reuse any
>> previous tuplesortstate perhaps just inventing a reset method which
>> clears out tuples, then we could see performance exceed the stan
37 matches
Mail list logo