GUCs but doesn't actually
> convert any existing GUCs to use that. (Unlike the reloptions, which
> your patch coverts.) And so there is no documentation about these
> questions.
>
>
--
Best Wishes,
Chris Travers
Efficito: Hosted Accounting and ERP. Robust and Flexible. No vendor
lock-in.
http://www.efficito.com/learn_more
I think there are actually a number of factors that make this much harder.
On Fri, May 17, 2024 at 2:33 PM Heikki Linnakangas wrote:
>
> On 17/05/2024 05:26, Robert Haas wrote:
> > For bonus points, suppose we make it so that when you click the link,
> > it takes you to a box where you can type i
The following review has been posted through the commitfest application:
make installcheck-world: not tested
Implements feature: not tested
Spec compliant: not tested
Documentation:tested, passed
Good catch. This is a trivial fix and so I hope we can just get it in ri
ready
encrypted, then do these forceably share the same data encrypting keys? Is
there a need to have (possibly in a follow-up patch) an ability to decrypt and
re-encrypt in pg_basebackup (which would need access to both keys) or is this
handled already and I just missed it?
Best Wishes,
Chris Travers
So I am in the process of reviewing the patch and hopefully can provide
something there soon.
However I want to address in the mean time the question of timestamp functions.
I know that is outside the scope of this patch but I would be in favor of
adding them generally, not just as an extensio
Congrats!
On Fri, Jul 28, 2023 at 10:29 PM Christoph Berg wrote:
> The PostgreSQL contributors team has been looking over the community
> activity and, over the first half of this year, has been recognizing
> new contributors to be listed on
>
> https://www.postgresql.org/community/contributors/
.
> > >
> > > While it’s easy to label something as checkbox, I don’t feel we
> have been
> > fair
> >
> > No, actually, it isn't. I am not sure why you are saying that.
> >
> > I’m confused as to what is required to label a fe
there are holes in it. But
there are others who really should be concerned (and this is becoming a
bigger issue where data privacy, PCI-DSS, and other requirements may come
into play), and those need better tooling than we have. I also think that
as data privacy becomes a larger issue, this w
"Right, the improvement this patch gives to the heap is not the full
motivation. Another motivation is the improvement it gives to TableAM API. Our
current API implies that the effort on locating the tuple by tid is small. This
is more or less true for the heap, where we just need to pin and loc
The following review has been posted through the commitfest application:
make installcheck-world: not tested
Implements feature: not tested
Spec compliant: not tested
Documentation:not tested
I have decided to write a review here in terms of whether we want this featur
On Tue, Nov 29, 2022 at 5:57 PM Bruce Momjian wrote:
> On Tue, Nov 29, 2022 at 11:41:07AM -0500, Robert Haas wrote:
> > My argument is that removing xidStopLimit is totally fine, because it
> > only serves to stop the database. What to do about xidWarnLimit is a
> > slightly more complex question
On Mon, Nov 28, 2022 at 11:06 PM Peter Geoghegan wrote:
> On Mon, Nov 28, 2022 at 1:52 PM Bruce Momjian wrote:
> > I think the problem is that we still have bloat with 64-bit XIDs,
> > specifically pg_xact and pg_multixact files. Yes, that bloat is less
> > serious, but it is still an issue wor
:08 AM Chris Travers
> wrote:
> > I didn't see any changes to pg_upgrade to make this change possible on
> upgrade. Is that also outside of the scope of your patch set? If so how
> is that continuity supposed to be ensured?
>
> The scheme is documented in their 000
Hi;
Trying to discuss where we are talking past eachother.
On Fri, Nov 25, 2022 at 9:38 AM Aleksander Alekseev <
aleksan...@timescale.com> wrote:
> Hi hackers,
>
> > I'm wondering whether the safest way to handle this is by creating a
> > new TAM called "heap64", so that all storage changes
On Tue, Nov 22, 2022 at 10:01 AM Aleksander Alekseev <
aleksan...@timescale.com> wrote:
> Hi Chris,
>
> > Right now the way things work is:
> > 1. Database starts throwing warnings that xid wraparound is approaching
> > 2. Database-owning team initiates an emergency response, may take
> downtime
On Mon, Nov 21, 2022 at 10:40 AM Pavel Borisov
wrote:
> > I have a very serious concern about the current patch set. as someone
> who has faced transaction id wraparound in the past.
> >
> > I can start by saying I think it would be helpful (if the other issues
> are approached reasonably) to hav
On Mon, Nov 21, 2022 at 12:25 PM Aleksander Alekseev <
aleksan...@timescale.com> wrote:
> Hi hackers,
>
> > > I have a very serious concern about the current patch set. as someone
> who has faced transaction id wraparound in the past.
> >
> > [...]
> >
> > I had a similar stance when I started wor
The following review has been posted through the commitfest application:
make installcheck-world: not tested
Implements feature: not tested
Spec compliant: not tested
Documentation:not tested
I have a very serious concern about the current patch set. as someone who has
same cannot be said of something like this new
> heap_force_kill() stuff.
>
> > - Any ideas for additional things we should include, or improvements
> > on the sketch above?
>
> Clearly you should work out a way of making it very hard to
> accidentally (mis)use. For example, maybe you make the functions check
> for the presence of a sentinel file in the data directory.
>
Agreed.
>
>
> --
> Peter Geoghegan
>
>
>
--
Best Regards,
Chris Travers
Head of Database
Tel: +49 162 9037 210 | Skype: einhverfr | www.adjust.com
Saarbrücker Straße 37a, 10405 Berlin
d. But it's been
> true all along, and this patch isn't changing that behavior at all.
> I'm not sure if we should do anything more than improve the docs,
> but in any case it seems independent of the CASE issue.
>
> > The current behavior isn't great, but at least it handles these
> > cases consistently.
>
> Really?
>
> regards, tom lane
>
>
>
--
Best Regards,
Chris Travers
Head of Database
Tel: +49 162 9037 210 | Skype: einhverfr | www.adjust.com
Saarbrücker Straße 37a, 10405 Berlin
s route, would it be too much to ask to allow a GUC variable to
preserve the old behavior?
> regards, tom lane
>
>
--
Best Regards,
Chris Travers
Head of Database
Tel: +49 162 9037 210 | Skype: einhverfr | www.adjust.com
Saarbrücker Straße 37a, 10405 Berlin
eld does not need to be added as the
> > padding-enabled output will already include it at the end[1]. This
> > would be handled automatically by the OpenSSL encryption / decryption
> > operations (if it's enabled):
> >
>
> Yes, right.
>
> Regards,
>
> [1]
> https://www.postgresql.org/message-id/031401d3f41d%245c70ed90%241552c8b0%24%40lab.ntt.co.jp
> [2]
> https://www.postgresql.org/message-id/CAD21AoD8QT0TWs3ma-aB821vwDKa1X519y1w3yrRKkAWjhZcrw%40mail.gmail.com
>
> --
> Masahiko Sawadahttp://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>
>
>
--
Best Regards,
Chris Travers
Head of Database
Tel: +49 162 9037 210 | Skype: einhverfr | www.adjust.com
Saarbrücker Straße 37a, 10405 Berlin
On Tue, May 14, 2019 at 9:11 AM Michael Paquier wrote:
> On Tue, May 14, 2019 at 08:08:05AM +0200, Chris Travers wrote:
> > Having thought about this a bit, I think the best solution would be to
> have
> > grant take out an access share lock to the tables granted. This
s share lock to the tables granted. This would
prevent concurrent alter table operations from altering the schema
underneath the grant as well, and thus possibly cause other race conditions.
Any thoughts?
>
> Regards,
> Nick.
>
>
>
--
Best Regards,
Chris Travers
Head of Database
Tel: +49 162 9037 210 | Skype: einhverfr | www.adjust.com
Saarbrücker Straße 37a, 10405 Berlin
050.
>
> --
> Álvaro Herrerahttps://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>
--
Best Regards,
Chris Travers
Head of Database
Tel: +49 162 9037 210 | Skype: einhverfr | www.adjust.com
Saarbrücker Straße 37a, 10405 Berlin
certain criteria. This could have a lower max workers
than autovacuum and therefore less of a threat in terms of total IO usage.
Thoughts?
>
>
> Andres
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>
>
>
--
Best Regards,
Chris Travers
Head of Database
Tel: +49 162 9037 210 | Skype: einhverfr | www.adjust.com
Saarbrücker Straße 37a, 10405 Berlin
bulk inserts all the time, vacuum freeze could have a lot of work to
do, and in some cases I could imagine IO storms making that difficult.
I plan to run some benchmarks on this to try to assess performance impact
of this patch in standard pgbench scenarios.I will also try to come up with
some o
hat very hot tables rise to the top of the
queue and are vacuumed frequently even after setting Autovacuum to be far
more aggressive on a large production database.
Thoughts? Feedback? Waiting for a patch?
--
Best Regards,
Chris Travers
Head of Database
Tel: +49 162 9037 210 | Skype: einhve
t; 2) -h/--help
> >>
> >> 3) rpm -qf $file (and similarly for other packagers)
> >>
> >> 4) set --prefix to install binaries so separate directory (which some
> >> distros already do anyway)
> >>
> >> So to me this seems like a fairly invasiv
ld be an even larger breakage and I
> am not convinced the advantage would be worth it especially since our
> executables are not as closely related and consistent as for example git's.
>
Git commands may be related, but I would actually argue that git commands
have a lot of inconsist
On Tue, Mar 19, 2019 at 12:19 PM Tomas Vondra
wrote:
>
> On 3/19/19 10:59 AM, Chris Travers wrote:
> >
> >
> > Not discussing whether any particular committer should pick this up but
> > I want to discuss an important use case we have at Adjust for this sort
> &
d ... But I don't think that was the case.
>
While I am not currently able to speak for questions of how it is
implemented, I can say with very little doubt that we would almost
certainly use this functionality if it were there and I could see plenty of
other cases where this would be a very appropriate direction for some other
projects as well.
> regards
>
> --
> Tomas Vondra http://www.2ndQuadrant.com
> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>
>
--
Best Regards,
Chris Travers
Head of Database
Tel: +49 162 9037 210 | Skype: einhverfr | www.adjust.com
Saarbrücker Straße 37a, 10405 Berlin
On Mon, Mar 18, 2019 at 4:09 AM Michael Paquier wrote:
> On Sun, Mar 17, 2019 at 09:00:57PM +0800, Chris Travers wrote:
> > I also added test cases and some docs. I don't know if the docs are
> > sufficient. Feedback is appreciated.
>
> To be honest, I don't thi
x27;t know if the docs are
sufficient. Feedback is appreciated. This is of course submitted for v13.
--
Best Regards,
Chris Travers
Head of Database
Tel: +49 162 9037 210 | Skype: einhverfr | www.adjust.com
Saarbrücker Straße 37a, 10405 Berlin
rewind_data_only_mode.patch
Description: Binary data
for some of
our use cases and some other general use cases. I think as a feature,
custom compression methods are a good thing but we are not the only ones
with interests here and would be interested in pushing this forward if
possible or finding ways to contribute to better approaches
e can be a large SQL with a lot of things in it,
> so
> it is good to point that problem is with ltree staff). And is is better to
> word from the point of view of a user. What for you (and me) is unexpected
> end
> of line, for him it is unclosed curly quote.
>
> Also I am not sure, if it is easy, but if it is possible, it would be good
> to
> move "^" symbol that points to the place of the error, to the place inside
> ' '
> where unclosed curly quote is located. As a user I would appreciate that.
>
> So that's what I've seen while giving it superficial look...
>
>
>
--
Best Regards,
Chris Travers
Head of Database
Tel: +49 162 9037 210 | Skype: einhverfr | www.adjust.com
Saarbrücker Straße 37a, 10405 Berlin
Here's a new patch. No rush on it. I am moving it to next commitfest
anyway because as code documentation I think this is a low priority late in
the release cycle.
The changes mostly address Andres's feedback above.
--
Best Regards,
Chris Travers
Head of Database
Tel: +49 16
On Wed, Mar 6, 2019 at 9:33 AM Chris Travers
wrote:
>
>
>> Thoughts?
>>
>
To re-iterate, my experience with PostgreSQL is that people doing
particularly exotic work in PostgreSQL can expect to hit equally exotic
bugs. I have a list that I will not bore people with here
On Wed, Mar 6, 2019 at 3:19 AM Michael Paquier wrote:
> On Tue, Mar 05, 2019 at 12:47:54PM +0000, Chris Travers wrote:
> > I tried installing a test extension into a temp schema. I found
> > this was remarkably difficult to do because pg_temp did not work (I
> > had to cre
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:not tested
I ran make checkworld and everything passed.
I tried installing
r
> > dependency links once the session is over.
>
> Extensions locate at pg_temp_* schemas are temporary objects IMO.
> How do you think? Would you implement this functionality in future?
>
That's the way things are now as far as I understand it, or do I
misunderstand your quest
acuum on some
table spaces, but set it aggressively on a couple system catalogs.
Currently this is not really doable in any sane way.
I also think that if the current catalogs violate expectations regarding
precondition checks this needs to be corrected rather than special-cased
and this seems to be the best way forward.
>
> regards.
>
> --
> Kyotaro Horiguchi
> NTT Open Source Software Center
>
--
Best Regards,
Chris Travers
Head of Database
Tel: +49 162 9037 210 | Skype: einhverfr | www.adjust.com
Saarbrücker Straße 37a, 10405 Berlin
ith the
idea that pages would be upgraded on write?
>
> --
> Alexander Korotkov
> Postgres Professional: http://www.postgrespro.com
> The Russian Postgres Company
>
--
Best Regards,
Chris Travers
Head of Database
Tel: +49 162 9037 210 | Skype: einhverfr | www.adjust.com
Saarbrücker Straße 37a, 10405 Berlin
s for most of that time), and having an ability to set
idle-in-transaction timeouts to figures of greater than a month are things
I could imagine doing. I would certainly favor the idea of 64-big GUC
variables as a general rule.
>
> Greetings,
>
> Andres Freund
>
>
--
Best Regards,
Chris Travers
Head of Database
Tel: +49 162 9037 210 | Skype: einhverfr | www.adjust.com
Saarbrücker Straße 37a, 10405 Berlin
extensions makes this behavior even more inconsistent. I guess I
would vote against accepting this patch as it is.
> --
> Michael
>
--
Best Regards,
Chris Travers
Head of Database
Tel: +49 162 9037 210 | Skype: einhverfr | www.adjust.com
Saarbrücker Straße 37a, 10405 Berlin
ail. Right now it just lists one so you have to follow the link
to the hackers list entry and look at each patch one at a time.
So if we could grab all attachments ending in .diff or .patch and list line
counts, that would be a welcome improvement.
>
> Regards
> Takayuki T
This could probably use a quick note in the docs.
attached is a new signal handing patch. Path is corrected and moved. The
documentation is sightly streamlined in some places and expanded in others.
Feedback requested.
--
Best Regards,
Chris Travers
Head of Database
Tel: +49 162 9037 210 | Skype: einhverfr | www.adjust.com
Saarbrücker Straße
rather than in code comments sine those might be scattered in a
bunch of different places.
>
> Greetings,
>
> Andres Freund
>
--
Best Regards,
Chris Travers
Head of Database
Tel: +49 162 9037 210 | Skype: einhverfr | www.adjust.com
Saarbrücker Straße 37a, 10405 Berlin
On Thu, Jan 17, 2019 at 6:38 PM Andres Freund wrote:
> Hi,
>
> On 2019-01-17 10:50:56 +0100, Chris Travers wrote:
> > diff --git a/src/backend/utils/init/globals.c
> b/src/backend/utils/init/globals.c
> > index c6939779b9..5ed715589e 100644
> > --- a/src/backend/
Latest patch, simpler but answers the key questions as code comments
On Mon, Dec 3, 2018 at 6:56 AM Chris Travers
wrote:
> On Thu, Nov 29, 2018 at 8:46 PM Dmitry Dolgov <9erthali...@gmail.com>
> wrote:
>
>> > On Wed, Oct 10, 2018 at 7:10 PM Chris Travers
>> wr
On Thu, Nov 29, 2018 at 8:46 PM Dmitry Dolgov <9erthali...@gmail.com> wrote:
> > On Wed, Oct 10, 2018 at 7:10 PM Chris Travers
> wrote:
> >
> >> More generally, I'd like this material to be code comments. It's the
> >> kind of stuff tha
On Tue, Oct 9, 2018 at 4:04 PM Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
> On 01/10/2018 14:00, Chris Travers wrote:
> >
> >
> > On Wed, Sep 26, 2018 at 9:54 AM Chris Travers > <mailto:chris.trav...@adjust.com>> wrote:
> >
> &
planner extrapolate from existing
stats in a more efficient way.
--
Best Regards,
Chris Travers
Head of Database
Tel: +49 162 9037 210 | Skype: einhverfr | www.adjust.com
Saarbrücker Straße 37a, 10405 Berlin
On Wed, Oct 3, 2018 at 9:41 AM Chris Travers
wrote:
> The following review has been posted through the commitfest application:
> make installcheck-world: tested, failed
> Implements feature: not tested
> Spec compliant: not tested
> Documentation:teste
On Wed, Oct 3, 2018 at 9:56 AM Chris Travers
wrote:
>
>
> On Wed, Oct 3, 2018 at 9:41 AM Chris Travers
> wrote:
>
>>
>> (errmsg("preparing foreign transactions
> (max_prepared_foreign_transactions > 0) requires maX_foreign_xact_resolvers
> > 0")
On Wed, Oct 3, 2018 at 9:41 AM Chris Travers
wrote:
> The following review has been posted through the commitfest application:
> make installcheck-world: tested, failed
> Implements feature: not tested
> Spec compliant: not tested
> Documentation:
The following review has been posted through the commitfest application:
make installcheck-world: tested, failed
Implements feature: not tested
Spec compliant: not tested
Documentation:tested, failed
I am hoping I am not out of order in writing this before the commitfe
Moving this to documentation due to a general consensus that abstracting this
is not necessarily worth it.
If we don't want to refactor and abstract this, it is worth documenting the
design as to how things work now so that others who face bugs can consult docs
instead of trying to determine ac
On Wed, Sep 26, 2018 at 9:54 AM Chris Travers
wrote:
>
>
> On Tue, Sep 25, 2018 at 3:23 PM Tom Lane wrote:
>
>> Chris Travers writes:
>> > However, what I think one could do is use a struct of volatile
>> > sig_atomic_t members and macros for checking/sett
On Tue, Sep 25, 2018 at 3:23 PM Tom Lane wrote:
> Chris Travers writes:
> > However, what I think one could do is use a struct of volatile
> > sig_atomic_t members and macros for checking/setting. Simply writing a
> > value is safe in C89 and higher.
>
> Yeah, we c
miscadmin.h to use sig_atomic_t?
> ClientConnectionLost would gain PGDLLIMPORT at the same time.
>
I am strongly in favor of doing this.
> --
> Michael
>
--
Best Regards,
Chris Travers
Head of Database
Tel: +49 162 9037 210 | Skype: einhverfr | www.adjust.com
Saarbrücker Straße 37a, 10405 Berlin
On Mon, Sep 24, 2018 at 7:06 PM Andres Freund wrote:
> On 2018-09-24 11:45:10 +0200, Chris Travers wrote:
> > I did some more reading.
> >
> > On Mon, Sep 24, 2018 at 10:15 AM Chris Travers >
> > wrote:
> >
> > > First, thanks for tak
e are a long way out to be able to consider these a single value
as flags.
However, what I think one could do is use a struct of volatile
sig_atomic_t members and macros for checking/setting. Simply writing a
value is safe in C89 and higher.
> regards, tom lane
Very minor revision
On Mon, Sep 24, 2018 at 11:45 AM Chris Travers
wrote:
>
> Ok so having looked into this a bit more
>
> It looks like to be strictly conforming, you can't just use a series of
> flags because neither C 89 or 99 guarantee that sig_atomic_t is read/write
I did some more reading.
On Mon, Sep 24, 2018 at 10:15 AM Chris Travers
wrote:
> First, thanks for taking the time to write this. Its very helpful.
> Additional thoughts inline.
>
> On Mon, Sep 24, 2018 at 2:12 AM Michael Paquier
> wrote:
>
>>
>> There could be
First, thanks for taking the time to write this. Its very helpful.
Additional thoughts inline.
On Mon, Sep 24, 2018 at 2:12 AM Michael Paquier wrote:
> On Fri, Sep 21, 2018 at 12:35:46PM +0200, Chris Travers wrote:
> > I understand how lock levels don't fit a simple hierarch
length(substr)) = substr
> $$ language sql;
>
> This function can be very effective in C language. Now it should be
> implemented with like or regexp, what is significantly more expensive.
>
>
These would just be wrappers around already existing internal functions,
right?
> Regards
>
On Fri, Sep 21, 2018 at 6:46 AM Michael Paquier wrote:
> On Thu, Sep 20, 2018 at 03:08:34PM +0200, Chris Travers wrote:
> > So here's a small patch. I will add it for the next commit fest unless
> > anyone has any reason I shouldn't.
>
> - return Interrup
flags directly.
So here's a small patch. I will add it for the next commit fest unless
anyone has any reason I shouldn't.
--
Best Regards,
Chris Travers
Head of Database
Tel: +49 162 9037 210 | Skype: einhverfr | www.adjust.com
Saarbrücker Straße 37a, 10405 Berlin
sig_refactor.patch
D
oC to emphasise that while we don't want to restrain people
> from "calling out" egregious behaviour, going via the CoC team is often
> more likely to lead to constructive communication and positive change.
>
Agreed on this.
My objection to the additional wording is simply that a) I think it does
not tackle the problem it needs to tackle, and b) creates a claim which
covers a bunch of things that it really shouldn't. It's a serious bug and
I still hope it gets fixed before it causes problems.
>
> --
> Craig Ringer http://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Training & Services
>
--
Best Wishes,
Chris Travers
Efficito: Hosted Accounting and ERP. Robust and Flexible. No vendor
lock-in.
http://www.efficito.com/learn_more
oing elsewhere. So I don't think ti is a question of "trust us" but
rather that the community won't let that sort of abuse happen no matter who
is on the CoC committee.
>
>
> regards
>
> --
> Tomas Vondra http://www.2ndQuadrant.com
> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>
>
--
Best Wishes,
Chris Travers
Efficito: Hosted Accounting and ERP. Robust and Flexible. No vendor
lock-in.
http://www.efficito.com/learn_more
> JD
>
> --
> Command Prompt, Inc. || http://the.postgres.company/ || @cmdpromptinc
> *** A fault and talent of mine is to tell it exactly how it is. ***
> PostgreSQL centered full stack support, consulting and development.
> Advocate: @amplifypostgres || Learn: https://postgresconf.org
> * Unless otherwise stated, opinions are my own. *
>
>
--
Best Wishes,
Chris Travers
Efficito: Hosted Accounting and ERP. Robust and Flexible. No vendor
lock-in.
http://www.efficito.com/learn_more
ad/alloc ... ok
test thread/descriptor... ok
test sql/twophase ... stderr FAILED
== shutting down postmaster ==
===
6 of 56 tests failed.
===========
--
Best Regards,
Chris Travers
Head of
On Mon, Sep 17, 2018 at 2:59 PM Oleksii Kliukin wrote:
>
>
> > On 7. Sep 2018, at 17:57, Chris Travers
> wrote:
> >
> > Hi;
> >
> > Attached is the patch we are fully testing at Adjust. There are a few
> non-obvious aspects of the code around where the
First, I have attached a cleaned-up revision (pg_indent, removing a
dangling comment etc)
On Fri, Sep 14, 2018 at 1:16 PM Thomas Munro
wrote:
> On Sat, Sep 8, 2018 at 3:57 AM Chris Travers
> wrote:
> > Attached is the patch we are fully testing at Adjust.
>
> Thanks!
>
On Fri, Sep 14, 2018 at 4:14 PM Dave Page wrote:
>
>
> On Fri, Sep 14, 2018 at 3:08 PM, Joshua D. Drake
> wrote:
>
>> On 09/14/2018 01:31 AM, Chris Travers wrote:
>>
>>
>> I apologize for the glacial slowness with which this has all been moving.
&
On Fri, Sep 14, 2018 at 11:45 AM Ilya Kosmodemiansky
wrote:
> On Fri, Sep 14, 2018 at 10:31 AM, Chris Travers
> wrote:
> > I really have to object to this addition:
> > "This Code is meant to cover all interaction between community members,
> > whether
PostgreSQL.
>
> I think we are about ready to announce the initial membership of the
> CoC committee, as well, but that should be a separate post.
>
> regards, tom lane
>
>
--
Best Wishes,
Chris Travers
Efficito: Hosted Accounting and ERP. Robust and Flexible. No vendor
lock-in.
http://www.efficito.com/learn_more
nt problem we want to ensure
never happens?
> --
> Michael
>
--
Best Regards,
Chris Travers
Head of Database
Tel: +49 162 9037 210 | Skype: einhverfr | www.adjust.com
Saarbrücker Straße 37a, 10405 Berlin
more in a couple days.
--
Best Regards,
Chris Travers
Head of Database
Tel: +49 162 9037 210 | Skype: einhverfr | www.adjust.com
Saarbrücker Straße 37a, 10405 Berlin
--
Best Regards,
Chris Travers
Head of Database
Tel: +49 162 9037 210 | Skype: einhverfr | www.adjust.com
Saarbrücker Straße 37a, 10405 Berlin
racecond.patch
Description: Binary data
le of days.
>
> --
> Best Regards,
> Chris Travers
> Head of Database
>
> Tel: +49 162 9037 210 | Skype: einhverfr | www.adjust.com
> Saarbrücker Straße 37a, 10405 Berlin
>
>
--
Best Regards,
Chris Travers
Head of Database
Tel: +49 162 9037 210 | Skype: einhverfr | www.
On Thu, Sep 6, 2018 at 1:31 PM Chris Travers
wrote:
>
>
> On Thu, Sep 6, 2018 at 11:08 AM Chris Travers
> wrote:
>
>> Ok, so here's my current patch (work in progress). I have not run tests
>> yet, and finding a way to add a test case is virtually impossible
On Thu, Sep 6, 2018 at 11:08 AM Chris Travers
wrote:
> Ok, so here's my current patch (work in progress). I have not run tests
> yet, and finding a way to add a test case is virtually impossible though I
> expect we will find ways of using gdb to confirm local fix later.
>
>
n the interrupt interval that caused
the loop to break.
2. close() does not get interrupted in a way that will not cause cleanup
problems later.
3. We will reach the next interrupt check at a reasonable interval and safe
spot.
Any initial arguments against?
--
Best Regards,
Chris Travers
He
On Wed, Sep 5, 2018 at 6:55 PM Andres Freund wrote:
> Hi,
>
> On 2018-09-05 18:48:44 +0200, Chris Travers wrote:
> > Will submit a patch here shortly. Thanks! Should we do for master and
> > 10? Or 9.6 too?
>
> Please don't top-post on this list. This needs to
Will submit a patch here shortly. Thanks! Should we do for master and
10? Or 9.6 too?
On Wed, Sep 5, 2018 at 6:40 PM Chris Travers
wrote:
> Yep, Maybe we should check for signals there.
>
> On Wed, Sep 5, 2018 at 5:27 PM Thomas Munro
> wrote:
>
>> On Wed, Sep 5,
Yep, Maybe we should check for signals there.
On Wed, Sep 5, 2018 at 5:27 PM Thomas Munro
wrote:
> On Wed, Sep 5, 2018 at 8:23 AM Chris Travers
> wrote:
> > 1. The query is in a parallel index scan or similar
> > 2. A process is executing a parallel plan and allocating a s
is any way to check for signals before retrying the system
call (which I am not 100% sure where it is yet but on my way).
Any feedback or thoughts before we look at implementing a patch?
--
Best Regards,
Chris Travers
Head of Database
Tel: +49 162 9037 210 | Skype: einhverfr | www.adjust.com
On Wed, Aug 22, 2018 at 9:09 AM Masahiko Sawada
wrote:
> On Wed, Aug 22, 2018 at 1:20 PM Chris Travers
> wrote:
> > The two things I would suggest is that rather than auto-detecting (if I
> understand your patch correctly) whether prepared transactions are possible
> on the ot
On Wed, Aug 22, 2018 at 3:12 AM Masahiko Sawada
wrote:
> On Tue, Aug 21, 2018 at 5:36 PM Chris Travers
> wrote:
> >
> >
> >
> > On Tue, Aug 21, 2018 at 8:42 AM Masahiko Sawada
> wrote:
> >>
> >> On Tue, Aug 21, 2018 at 1:47 AM Chris Travers
On Mon, Aug 20, 2018 at 4:44 PM Tom Lane wrote:
> Chris Travers writes:
> > I am looking at trying to make two modifications to the PostgreSQL FDW
> and
> > would like feedback on this before I do.
>
> > 1. INSERTMETHOD=[insert|copy] option on foreign table.
>
>
On Tue, Aug 21, 2018 at 8:42 AM Masahiko Sawada
wrote:
> On Tue, Aug 21, 2018 at 1:47 AM Chris Travers
> wrote:
> >
> >
> >
> > On Mon, Aug 20, 2018 at 4:41 PM Andres Freund
> wrote:
> >>
> >> Hi,
> >>
> >> On 2018-08-20 1
discussion purposes.
Two things which are currently missing are a) an ability to specify in the
log file where the cleanup routine is located for a background worker and
b) a separation of backend responsibility for restarting cleanup efforts on
server start.
>
>>
>>
>
> --
On Mon, Aug 20, 2018 at 4:41 PM Andres Freund wrote:
> Hi,
>
> On 2018-08-20 16:28:01 +0200, Chris Travers wrote:
> > 1. INSERTMETHOD=[insert|copy] option on foreign table.
> >
> > One significant limitation of the PostgreSQL FDW is that it does a
> prepared
&g
tting or rolling back on cleanup.
I would like to push these both for Pg 12. Is there any feedback on the
concepts and the problems first
--
Best Regards,
Chris Travers
Head of Database
Tel: +49 162 9037 210 | Skype: einhverfr | www.adjust.com
Saarbrücker Straße 37a, 10405 Berlin
On Fri, Jul 27, 2018, 19:01 Andres Freund wrote:
> Hi,
>
> On 2018-07-27 11:15:00 -0500, Nico Williams wrote:
> > Even assuming you can't change the PG license, you could still:
> >
> > - require disclosure in contributions
>
> That really has no upsides, except poison the area. Either we rejec
QL (i.e where any use that involves utilizing the
copyright license for PostgreSQL extends to the patents in question). But
I am not sure that a business case would be able to be made for releasing
any patents under such a license since it means that for anyone else, using
the patents even in commercial software becomes trivial and enforcement
would become very difficult indeed.
--
Best Regards,
Chris Travers
Database Administrator
Tel: +49 162 9037 210 | Skype: einhverfr | www.adjust.com
Saarbrücker Straße 37a, 10405 Berlin
you still have taint problems but
probably not to the same extent.
--
Best Regards,
Chris Travers
Database Administrator
Tel: +49 162 9037 210 | Skype: einhverfr | www.adjust.com
Saarbrücker Straße 37a, 10405 Berlin
1 - 100 of 108 matches
Mail list logo
