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 dealing with isolation: snapsho
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 tryi
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 commiter" and tried to add me as the
>>> *second* author. But the CF app forces certain
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 function
> (pg_current_xlog_lo
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:
http://www.postgresql.org/mailpref/pgsql-hackers
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
> my tests.
>
> +1 for this patch. Looks like t
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, func
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 of duplication
either
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 call?
>
> The
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 r
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
mailto:a...@8kdata.com>> wrote:
>
>
> Hi.
>
> I have a newbie question for extension development. Extensions
provide an entry point, and are dynamically linked to PostgreSQL
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 tests.
>
> The only fly
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 existing funcitons.
> That's
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] where
> 1 BC is represented as
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 HORIGUCHI
>>> wrote:
I marked this as "ready for commiter" and tried to a
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 case that's relevant,
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 for it.
--
Robert Haa
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 maili
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 t
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
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 applying transactions
>> in an order which may not
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 later.
>
> Well, I'm pretty interested in usin
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 funcito
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 != op->o
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 for the new patch.
>>
>>
>> At Fri, 26 Feb 2016 08:52:54 +0900, Masah
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 adding your own and calling
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
Á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
t
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
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]
GetXLogOl
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 t
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 p
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 i
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 Architec
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 subs
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 performs 2PC here.
> And in princ
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 something else. Wha
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 them SSI cannot tell whether there is an
>
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 was possible to
>> glean this information on the primary, but the timings are
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 functi
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 inte
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
«GetXLogOld
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(), pg_current_xlog_insert_location()
43 matches
Mail list logo