Re: [HACKERS] proposal: get oldest LSN - function

On 27.02.2016 16:09, Michael Paquier wrote: On Sat, Feb 27, 2016 at 3:52 PM, Kartyshov Ivan wrote: Maybe i wasn't too accurate in terms, because I newbie, but: We can get information about xlog, using big amout of support function (pg_current_xlog_location(),

Re: [HACKERS] proposal: get oldest LSN - function

On 27.02.2016 22:36, Yury Zhuravlev wrote: Hello. You forgot to declare a GetXLogOldestLSNPtr function in a header file (in xlog.h I think). Some compilers refuse to compile this code (MSVC for example). Now I see warning from GCC: xlog.c:10627:1: warning: no previous prototype for

Re: [HACKERS] exposing pg_controldata and pg_config as functions

On 02/21/2016 05:30 AM, Michael Paquier wrote: > Looking again at this thread I guess that this is consensus, based on > the proposal from Josh and seeing no other ideas around. Another idea > would be to group all the fields that into a single function > pg_control_data(). I think a single

Re: [HACKERS] postgres_fdw vs. force_parallel_mode on ppc

On Fri, Feb 26, 2016 at 04:16:58PM +0530, Robert Haas wrote: > Committed these patches after revising the comment you wrote and > adding documentation. I've modified buildfarm member mandrill to use force_parallel_mode=regress and max_parallel_degree=5; a full run passes. We'll now see if it

Re: [HACKERS] Proposal: "Causal reads" mode for load balancing reads without stale data

On 27 February 2016 at 13:20, Michael Paquier wrote: > On Mon, Feb 22, 2016 at 9:39 AM, Thom Brown wrote: >> On 21 February 2016 at 23:18, Thomas Munro >> wrote: >> The replay_lag is particularly cool. Didn't think it

Re: [HACKERS] The plan for FDW-based sharding

On Sat, Feb 27, 2016 at 3:57 PM, Simon Riggs wrote: > On 27 February 2016 at 17:54, Kevin Grittner wrote: >> >> On a single database SSI can see whether a read has >> caused such a problem. If you replicate the transactions to >> somewhere else and read

Re: [HACKERS] The plan for FDW-based sharding

On 27 February 2016 at 17:54, Kevin Grittner wrote: > On a single database SSI can see whether a read has > caused such a problem. If you replicate the transactions to > somewhere else and read them SSI cannot tell whether there is an > anomaly OK, I thought you were saying

Re: [HACKERS] The plan for FDW-based sharding

On Sat, Feb 27, 2016 at 1:14 PM, Konstantin Knizhnik wrote: > We do not try to preserve transaction commit order at all nodes. > But in principle it can be implemented using XTM API: it allows to redefine > function which actually sets transaction status. pg_dtm

Re: [HACKERS] Sanity checking for ./configure options?

On 2016-02-27 14:15:45 -0600, Jim Nasby wrote: > Yeah, and I don't see any reasonable way to do that... we don't require sed > or the like, do we? We actually do. Check the bottom of configure.in. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your

Re: [HACKERS] Sanity checking for ./configure options?

On 2/26/16 9:29 PM, Peter Eisentraut wrote: To make this really robust, you might need to do pattern matching on the value. Yeah, and I don't see any reasonable way to do that... we don't require sed or the like, do we? I'll look at the other things you mentioned. -- Jim Nasby, Data

Re: [HACKERS] Sanity checking for ./configure options?

On 2/26/16 9:34 AM, Ivan Kartyshov wrote: The following review has been posted through the commitfest application: make installcheck-world: tested, failed Implements feature: tested, failed Spec compliant: tested, failed Documentation:tested, failed Tested, I think

Re: [HACKERS] Convert pltcl from strings to objects

On 2/25/16 9:30 AM, Alvaro Herrera wrote: Jim Nasby wrote: Here we have another case. prodesc is a global thing. And it is shared between different operations. Problem was that there is no partcular owner, and we have to wait when last operation which deals with it would finish. It looks like

Re: [HACKERS] PostgreSQL extension API? Documentation?

On 02/27/16 14:11, Álvaro Hernández Tortosa wrote: > Why would it be so much work? Creating a function list, and maybe > documenting those, doesn't sound like a daunting task. > > I wouldn't mind volunteering for this work, but I guess I would need > some help to understand and identify

Re: [HACKERS] proposal: get oldest LSN - function

Hello. You forgot to declare a GetXLogOldestLSNPtr function in a header file (in xlog.h I think). Some compilers refuse to compile this code (MSVC for example). Now I see warning from GCC: xlog.c:10627:1: warning: no previous prototype for «GetXLogOldestLSNPtr» [-Wmissing-prototypes]

Re: [HACKERS] PostgreSQL extension API? Documentation?

On 02/27/16 13:51, Álvaro Hernández Tortosa wrote: > ... I still lack a list of functions that might be callable (I > understand not even those labeled with PGDLLIMPORT are all good candidates > and some good candidates might not be labeled as such) from an extension > point of view. Have you

Re: [HACKERS] PostgreSQL extension API? Documentation?

Álvaro Hernández Tortosa wrote: I wouldn't mind volunteering for this work, but I guess I would need some help to understand and identify the candidate parts of the API. If anyone could help me here, please let me know. When you write an extension often regret that someone specified this or

Re: [HACKERS] The plan for FDW-based sharding

Neither pg_dtm, neither pg_tsdtm supports serializable isolation level. We implemented distributed snapshot isolation - repeatable-read isolation level. We also do not support read-committed isolation level now. We do not try to preserve transaction commit order at all nodes. But in principle it

Re: [HACKERS] PostgreSQL extension API? Documentation?

On 27/02/16 15:43, Tom Lane wrote: Chapman Flack writes: On 02/27/16 08:37, �lvaro Hernández Tortosa wrote: In other words: what is the API surface exposed by PostgreSQL to extension developers? The assumption is that no PostgreSQL code should be modified, just

Re: [HACKERS] Support for N synchronous standby servers - take 2

On Fri, Feb 26, 2016 at 10:53 AM, Kyotaro HORIGUCHI wrote: > At Fri, 26 Feb 2016 10:38:22 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI > wrote in > <20160226.103822.12680005.horiguchi.kyot...@lab.ntt.co.jp> >> Hello, Thanks

Re: [HACKERS] [PATCH] fix DROP OPERATOR to reset links to itself on commutator and negator

Roma Sokolov wrote: See v2 of the patch attached. Hello. I have a stylistic comments. Sometimes you forget a space: + replaces[Anum_pg_operator_oprcom - 1] =true; or use tab insted space: + if (OidIsValid(op->oprnegate) || + (OidIsValid(op->oprcom) && operOid !=

Re: [HACKERS] PostgreSQL extension API? Documentation?

On 27/02/16 15:10, Chapman Flack wrote: On 02/27/16 08:37, Álvaro Hernández Tortosa wrote: In other words: what is the API surface exposed by PostgreSQL to extension developers? The assumption is that no PostgreSQL code should be modified, just adding your own and calling existing

Re: [HACKERS] Re: [COMMITTERS] pgsql: Respect TEMP_CONFIG when running contrib regression tests.

On Sat, Feb 27, 2016 at 9:25 AM, Robert Haas wrote: > On Sat, Feb 27, 2016 at 7:08 PM, Andrew Dunstan > wrote: > > > Perhaps what we need to do is modify pg_regress.c slightly to allow more > > than one --temp-config argument. But that could be done

Re: [HACKERS] The plan for FDW-based sharding

On Fri, Feb 26, 2016 at 5:37 PM, Simon Riggs wrote: > On 26 February 2016 at 22:48, Kevin Grittner wrote: >> if we want logical >> replication to be free of serialization anomalies for those using >> serializable transactions, we need to support

Re: [HACKERS] [PROPOSAL] VACUUM Progress Checker.

Hi! I'm interesting this patch and tested it. I found two strange thing. * Incorrect counting Reproduce: 1. Client1 execute "VACUUM" 2. Client2 execute "VACUUM" 3. Client3 execute "SELECT * FROM pg_stat_vacuum_progress". pid | relid | phase | total_heap_blks | current_heap_blkno

Re: [HACKERS] Proposal: Generic WAL logical messages

Hello, On 27.02.2016 03:05, Andres Freund wrote: Hi, I'm not really convinced by RegisterStandbyMsgPrefix() et al. There's not much documentation about what it actually is supposed to acomplish. Afaics you're basically forced to use shared_preload_libraries with it right now? Also, iterating

[HACKERS] Typo fix

Attached fixes a typo: /* the extra unit accounts for the autovacuum launcher */ MaxBackends = MaxConnections + autovacuum_max_workers + 1 + - +max_worker_processes; + max_worker_processes; Thanks, Amit typo.patch Description: Binary data -- Sent via pgsql-hackers

[HACKERS] Re: [COMMITTERS] pgsql: Respect TEMP_CONFIG when running contrib regression tests.

On Sat, Feb 27, 2016 at 8:36 PM, Andrew Dunstan wrote: > "doesn't meet your need" is probably a better way of putting it. The > facility's use has grown beyond what I originally envisaged, so I think we > will need that patch. > > Would you like me to apply what I have? Go

[HACKERS] Re: [COMMITTERS] pgsql: Respect TEMP_CONFIG when running contrib regression tests.

On 02/27/2016 09:25 AM, Robert Haas wrote: On Sat, Feb 27, 2016 at 7:08 PM, Andrew Dunstan wrote: What I had in mind was something like the attached. In testing this seems to do the right thing, and the nice part is that it will be picked up by the buildfarm in the one

Re: [HACKERS] PATCH: index-only scans with partial indexes

On Sat, Feb 27, 2016 at 6:19 PM, Michael Paquier wrote: > On Sat, Feb 27, 2016 at 1:08 AM, Robert Haas wrote: >> On Fri, Feb 26, 2016 at 6:16 PM, Michael Paquier >> wrote: >>> On Fri, Feb 26, 2016 at 4:18 PM, Kyotaro

Re: [HACKERS] [PATH] Correct negative/zero year in to_date/to_timestamp

On Tue, Feb 23, 2016 at 6:23 AM, Thomas Munro wrote: > This seems to be a messy topic. The usage of "AD" and "BC" imply that > TO_DATE is using the anno domini system which doesn't have a year 0, > but in the DATE type perhaps we are using the ISO 8601 model[2]

Re: [HACKERS] PostgreSQL extension API? Documentation?

Chapman Flack writes: > On 02/27/16 08:37, Álvaro Hernández Tortosa wrote: >> In other words: what is the API surface exposed by PostgreSQL to >> extension developers? The assumption is that no PostgreSQL code should be >> modified, just adding your own and calling

[HACKERS] Re: [COMMITTERS] pgsql: Respect TEMP_CONFIG when running contrib regression tests.

On Sat, Feb 27, 2016 at 7:08 PM, Andrew Dunstan wrote: > What I had in mind was something like the attached. > > In testing this seems to do the right thing, and the nice part is that it > will be picked up by the buildfarm in the one case that's relevant, namely > the ecpg

Re: [HACKERS] PostgreSQL extension API? Documentation?

On 27/02/16 15:01, Fabrízio de Royes Mello wrote: On Sat, Feb 27, 2016 at 10:37 AM, Álvaro Hernández Tortosa > wrote: > > > Hi. > > I have a newbie question for extension development. Extensions provide an entry point, and are dynamically

Re: [HACKERS] PostgreSQL extension API? Documentation?

On 02/27/16 08:37, Álvaro Hernández Tortosa wrote: > In other words: what is the API surface exposed by PostgreSQL to > extension developers? The assumption is that no PostgreSQL code should be > modified, just adding your own and calling existing funcitons. That's an excellent question that

Re: [HACKERS] PostgreSQL extension API? Documentation?

On Sat, Feb 27, 2016 at 10:37 AM, Álvaro Hernández Tortosa wrote: > > > Hi. > > I have a newbie question for extension development. Extensions provide an entry point, and are dynamically linked to PostgreSQL. But what APIs/functions are really available for extensions to

[HACKERS] PostgreSQL extension API? Documentation?

Hi. I have a newbie question for extension development. Extensions provide an entry point, and are dynamically linked to PostgreSQL. But what APIs/functions are really available for extensions to call? The most obvious API is SPI. You could also implements hooks. Of course,

[HACKERS] Re: [COMMITTERS] pgsql: Respect TEMP_CONFIG when running contrib regression tests.

On 02/26/2016 10:59 PM, Robert Haas wrote: On Sat, Feb 27, 2016 at 9:00 AM, Andrew Dunstan wrote: Sure. Saving three lines of Makefile duplication is hardly a world-shattering event, so I thought there might be some other purpose. But I'm not against saving three lines

Re: [HACKERS] Proposal: "Causal reads" mode for load balancing reads without stale data

On Mon, Feb 22, 2016 at 9:39 AM, Thom Brown wrote: > On 21 February 2016 at 23:18, Thomas Munro > wrote: > The replay_lag is particularly cool. Didn't think it was possible to > glean this information on the primary, but the timings are correct in

Re: [HACKERS] [PATCH] fix DROP OPERATOR to reset links to itself on commutator and negator

On Sat, Feb 27, 2016 at 12:46 AM, Roma Sokolov wrote: > Should this patch be added to CommitFest? Yes please. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription:

Re: [HACKERS] proposal: get oldest LSN - function

On Sat, Feb 27, 2016 at 3:52 PM, Kartyshov Ivan wrote: > On 27.02.2016 03:07, Andres Freund wrote >> >> How does it help with any of that? > > Maybe i wasn't too accurate in terms, because I newbie, but: > We can get information about xlog, using big amout of support

Re: [HACKERS] PATCH: index-only scans with partial indexes

On Sat, Feb 27, 2016 at 1:08 AM, Robert Haas wrote: > On Fri, Feb 26, 2016 at 6:16 PM, Michael Paquier > wrote: >> On Fri, Feb 26, 2016 at 4:18 PM, Kyotaro HORIGUCHI >> wrote: >>> I marked this as "ready for

Re: [HACKERS] The plan for FDW-based sharding

On 27/02/16 09:19, Konstantin Knizhnik wrote: On 02/27/2016 06:54 AM, Robert Haas wrote: [...] So maybe the goal for the GTM isn't to provide true serializability across the cluster but some lesser degree of transaction isolation. But then exactly which serialization anomalies are we

Re: [HACKERS] The plan for FDW-based sharding

On 02/27/2016 06:54 AM, Robert Haas wrote: On Fri, Feb 26, 2016 at 10:56 PM, Konstantin Knizhnik wrote: We do not have formal prove that proposed XTM is "general enough" to handle all possible transaction manager implementations. But there are two general ways of