Re: [HACKERS] [BUG FIX] Compare returned value by socket() against PGINVALID_SOCKET instead of < 0

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

Re: [HACKERS] proposal: persistent plpgsql plugin info - field plugin_info for plpgsql_function structure

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

Re: [HACKERS] PoC: Partial sort

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

Re: [HACKERS] proposal: persistent plpgsql plugin info - field plugin_info for plpgsql_function structure

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

[HACKERS] What exactly is drop-index-concurrently-1.spec trying to test?

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

Re: [HACKERS] Patch: show relation and tuple infos of a lock to acquire

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

Re: [HACKERS] proposal: multiple read-write masters in a cluster with wal-streaming synchronization

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

Re: [HACKERS] Get more from indices.

"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

Re: [HACKERS] proposal: persistent plpgsql plugin info - field plugin_info for plpgsql_function structure

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

Re: [HACKERS] proposal: multiple read-write masters in a cluster with wal-streaming synchronization

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

[HACKERS] proposal: multiple read-write masters in a cluster with wal-streaming synchronization

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

Re: [HACKERS] proposal: persistent plpgsql plugin info - field plugin_info for plpgsql_function structure

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

Re: [HACKERS] fix_PGSTAT_NUM_TABENTRIES_macro patch

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

Re: [HACKERS] proposal: persistent plpgsql plugin info - field plugin_info for plpgsql_function structure

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

[HACKERS] proposal: persistent plpgsql plugin info - field plugin_info for plpgsql_function structure

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

Re: [HACKERS] fix_PGSTAT_NUM_TABENTRIES_macro patch

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

Re: [HACKERS] fix_PGSTAT_NUM_TABENTRIES_macro patch

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

Re: [HACKERS] fix_PGSTAT_NUM_TABENTRIES_macro patch

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

Re: [HACKERS] Patch: show relation and tuple infos of a lock to acquire

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)): (

Re: [HACKERS] Patch: show relation and tuple infos of a lock to acquire

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

Re: [HACKERS] [PATCH] Store Extension Options

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

Re: [HACKERS] Patch: show relation and tuple infos of a lock to acquire

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)

Re: [HACKERS] [PATCH] Store Extension Options

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: >>

Re: [HACKERS] PoC: Partial sort

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

Re: [HACKERS] [PATCH] Store Extension Options

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

Re: [HACKERS] [PATCH] Store Extension Options

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

Re: [HACKERS] [PATCH] Store Extension Options

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

Re: [HACKERS] [PATCH] Store Extension Options

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 = ...

Re: [HACKERS] Proposal: variant of regclass

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

[HACKERS] [PATCH] Store Extension Options

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

Re: [HACKERS] INSERT...ON DUPLICATE KEY LOCK FOR UPDATE

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

Re: [HACKERS] Patch: Show process IDs of processes holding a lock; show relation and tuple infos of a lock to acquire

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 (

[HACKERS] Patch: show relation and tuple infos of a lock to acquire

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

Re: [HACKERS] INSERT...ON DUPLICATE KEY LOCK FOR UPDATE

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

Re: [HACKERS] INSERT...ON DUPLICATE KEY LOCK FOR UPDATE

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

Re: [HACKERS] Patch: Show process IDs of processes holding a lock; show relation and tuple infos of a lock to acquire

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

Re: [HACKERS] PoC: Partial sort

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