Hi,
On 2018-02-22 23:11:07 -0800, Andres Freund wrote:
> I think using RTLD_LOCAL on most machines would be a much better
> idea. I've not found proper explanations why GLOBAL is used. We started
> using it ages ago, with [2], but that commit contains no explanation,
> and a quick search didn't sh
Hi hackers,
Due to recent naming inflation, the isolation tester output has become
jagged (when viewed in a monospace font):
test lock-update-delete ... ok
test lock-update-traversal... ok
test insert-conflict-do-nothing ... ok
test insert-conflict-do-nothing-2 ... ok
test insert-confli
On Fri, Feb 23, 2018 at 6:05 AM, Robert Haas wrote:
> On Thu, Feb 22, 2018 at 7:54 AM, Thomas Munro
> wrote:>
>> The best solution I have come up with so far is to add a reference
>> count to SERIALIZABLEXACT. I toyed with putting the refcount into the
>> DSM instead, but then I ran into problem
Ah, I understand now. We can lie to the executor about the order,
because when we are moving based on the second outer column, we have a
stretch of equal values in the inner column, so we can consider them to
be sorted whatever way we need.
The patch applies cleanly, make check-world passes.
On 23 February 2018 at 04:11, Jesper Pedersen
wrote:
> Are UPDATE and DELETE suppose to be supported ?
To be honest, I had not even considered those. Without looking in
detail I imagine it may be possible to allow this simply by setting
the AppendPath->trypartitionprune in the correct cases in th
On 23 February 2018 at 11:40, David Rowley wrote:
> On 23 February 2018 at 04:11, Jesper Pedersen
> wrote:
>> Are UPDATE and DELETE suppose to be supported ?
>
> To be honest, I had not even considered those.
I can say that I had considered those. Handling of UPDATE and DELETE
with partitions is
Amit Langote wrote:
> On Fri, Feb 23, 2018 at 11:32 AM, Alvaro Herrera
> wrote:
> > Uh, wow, how have I missed that all this time! Yes, it probably does.
> > I'll rework this tomorrow ... and the already committed index patch too,
> > I think.
>
> BTW, not sure if you'd noticed but I had emaile
On Thu, Feb 22, 2018 at 10:14 PM, Peter Eisentraut
wrote:
> Here is a patch that adds a way to specify an external command for
> obtaining SSL passphrases. There is a new GUC setting
> ssl_passphrase_command.
>
> Right now, we rely on the OpenSSL built-in prompting mechanism, which
> doesn't work
On Thu, Feb 22, 2018 at 6:52 PM, Alvaro Herrera wrote:
> Alvaro Herrera wrote:
>> Another option is to rethink this feature from the ground up: instead of
>> cloning catalog rows for each children, maybe we should have the trigger
>> lookup code, when running DML on the child relation (the partiti
On 23 February 2018 at 04:04, Tom Lane wrote:
> Alvaro Herrera writes:
>> Please join pgsql-translat...@postgresql.org.
>
> What surprises me about this thread is that apparently the sad state
> of the v10 translations wasn't already discussed on that list?
>
> I have no objection to calling for
On Fri, Feb 23, 2018 at 11:26:31AM +0900, Michael Paquier wrote:
> An other, evil, idea that I have on top of all those things is to
> directly hexedit the WAL segment of the standby just at the limit where
> it would receive a record from the primary and insert in it garbage
> data which would mak
On Fri, Feb 23, 2018 at 08:16:12AM -0500, Robert Haas wrote:
> On Thu, Feb 22, 2018 at 10:14 PM, Peter Eisentraut
> wrote:
>> Here is a patch that adds a way to specify an external command for
>> obtaining SSL passphrases. There is a new GUC setting
>> ssl_passphrase_command.
>>
>> Right now, we
On Fri, Feb 16, 2018 at 12:14 AM, Ashutosh Bapat
wrote:
> Appreciate you taking time for review.
>
> PFA updated version.
Committed 0001.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On Wed, Feb 21, 2018 at 5:44 AM, Amit Langote
wrote:
> Please find attached updated patches.
Committed 0001 and 0002.
I'm having some difficulty wrapping my head around 0003 because it has
minimal comments and no useful commit message. I think, though, that
it's actually broken. Pre-patch, the
On Thu, Feb 22, 2018 at 9:48 PM, Michael Paquier wrote:
> On Thu, Feb 22, 2018 at 11:24:37AM -0800, Andres Freund wrote:
>> I suspect I'm going to get some grief for this, but I think the time has
>> come to bite the bullet and support changing databases in the same
>> process...
>
> I'd like to s
Thom Brown writes:
> Something that isn't clear to me is, for a language that didn't meet
> 80% translation for a component, if it does reach 80% after the major
> version release, does it then get shipped in a minor release, or is
> out of that version completely until the next major version?
No
On Fri, Feb 23, 2018 at 10:41 AM, Tom Lane wrote:
> Thom Brown writes:
>> Something that isn't clear to me is, for a language that didn't meet
>> 80% translation for a component, if it does reach 80% after the major
>> version release, does it then get shipped in a minor release, or is
>> out of
Andres Freund writes:
> First question:
> Why do we currently use RTLD_GLOBAL loading extension libraries, but
> take pains ([1]) to make things work without RTLD_GLOBAL.
As mentioned in that very message, the point was better missing-symbol
error detection, not RTLD_GLOBAL/LOCAL per se.
> I thi
On Thu, February 22, 2018 11:04 pm, Tom Lane wrote:
> Alvaro Herrera writes:
>> Please join pgsql-translat...@postgresql.org.
>
> What surprises me about this thread is that apparently the sad state
> of the v10 translations wasn't already discussed on that list?
The list is more or less dead -
Robert Haas wrote:
> On Mon, Jan 29, 2018 at 3:32 AM, Antonin Houska wrote:
> > I think of a variant of this: implement an universal function that tests the
> > binary values for equality (besides the actual arguments, caller would have
> > to
> > pass info like typlen, typalign, typbyval for e
On Thu, Feb 22, 2018 at 9:24 PM, Tom Lane wrote:
> Magnus Hagander writes:
> > I hacked up an attempt to do this. It does seem to work in the very
> simple
> > case, but it does requiring changing the order in InitPostgres() to load
> > the startup packet before validating those.
>
> I doubt tha
On Thu, Feb 22, 2018 at 9:09 PM, Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
> On 2/22/18 12:38, Magnus Hagander wrote:
> > I'm not entirely sure which the others ones are. Auto-Vacuum obviously
> > is one, which doesn't use the worker infrastructure. But I'm not sure
> > which the
Alexander Kuzmenkov writes:
> In create_mergejoin_plan:
> * implied inner ordering is then "ORDER BY x, y, x", but the pathkey
> * drops the second sort by x as redundant, and this code must cope.
> -- should this read "the pathkey machinery drops"?
I changed that and improved some othe
Magnus Hagander writes:
> Here's another attempt at moving this one forward. Basically this adds a
> new GucSource being GUC_S_CLIENT_EARLY. It now runs through the parameters
> once before CheckMyDatabase, with source set to GUC_S_CLIENT_EARLY. In this
> source, *only* parameters that are flagged
On Fri, Feb 23, 2018 at 7:52 PM, Tom Lane wrote:
> Magnus Hagander writes:
> > Here's another attempt at moving this one forward. Basically this adds a
> > new GucSource being GUC_S_CLIENT_EARLY. It now runs through the
> parameters
> > once before CheckMyDatabase, with source set to GUC_S_CLIEN
On 2/22/18 23:58, Michael Paquier wrote:
> One of the tests is failing:
> t/001_ssltests.pl .. 1/62
> # Failed test 'certificate authorization fails with revoked client cert:
> matches'
> # at /home//git/postgres/src/test/ssl/../../../src/test/perl/TestLib.pm
> line 354.
> #
On 2/23/18 10:48, Robert Haas wrote:
> On Fri, Feb 23, 2018 at 10:41 AM, Tom Lane wrote:
>> Thom Brown writes:
>>> Something that isn't clear to me is, for a language that didn't meet
>>> 80% translation for a component, if it does reach 80% after the major
>>> version release, does it then get s
On Fri, Feb 23, 2018 at 2:09 PM, Peter Eisentraut
wrote:
> That section is meant to say, if a translation ships in 10.0 with 81%
> but then drops to 79% because some backpatching changes strings, we
> won't drop it in 10.2.
>
> In the opposite case, it would be added to a minor release.
Good to k
On Sat, Dec 23, 2017 at 4:53 PM, Robert Haas wrote:
> As I mentioned in the commit message for the Parallel Append commit
> (ab72716778128fb63d54ac256adf7fe6820a1185), it's kind of sad that this
> doesn't work with UNION ALL queries, which are an obvious candidate
> for such parallelization. It t
Adding -hackers to this in the interest of getting it committed by Monday's
wrap-up.
https://www.postgresql.org/message-id/6e375316-91a4-7825-ef8b-9b8915ab6980%402ndquadrant.com
David J.
On Sat, Feb 17, 2018 at 8:43 PM, Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
> On 2/5/18 10:
On Sun, Nov 26, 2017 at 3:04 AM, Robert Haas wrote:
> On Tue, Nov 21, 2017 at 5:38 PM, Peter Geoghegan wrote:
>>> That having been said, I think the place where our plans most commonly
>>> go wrong is where we incorrectly estimate the number of tuples by
>>> multiple orders of magnitude - 100x is
On Fri, Feb 23, 2018 at 6:06 PM, Thomas Munro
wrote:
> If we switched to policy 3 and (say) work_mem were somehow
> automagically adjusted to be divided by number of participants at
> planning and execution time, then Parallel Hash wouldn't have to
> change at all to conform to the policy. It wou
On Thu, Feb 22, 2018 at 3:28 PM, Magnus Hagander wrote:
> I would prefer that yes. But having to re-read 9TB is still significantly
> better than not being able to turn on checksums at all (state today). And
> adding a catalog column for it will carry the cost of the migration
> *forever*, both fo
On 02/24/2018 01:34 AM, Robert Haas wrote:
> On Thu, Feb 22, 2018 at 3:28 PM, Magnus Hagander wrote:
>> I would prefer that yes. But having to re-read 9TB is still significantly
>> better than not being able to turn on checksums at all (state today). And
>> adding a catalog column for it will ca
Hi,
On 2018-02-24 03:07:28 +0100, Tomas Vondra wrote:
> I agree having to restart the whole operation after a crash is not
> ideal, but I don't see how adding a flag actually solves it. The problem
> is the large databases often store most of the data (>80%) in one or two
> central tables (think f
Tels wrote:
> Last but not least I'd be able to help with the german translation, but I
> have no clear idea how, or what the actual status is. Are German
> translators actually needed?
German, along with Russian and French, are pretty much the only
translations kept fully up to date almost all t
On 02/24/2018 03:11 AM, Andres Freund wrote:
> Hi,
>
> On 2018-02-24 03:07:28 +0100, Tomas Vondra wrote:
>> I agree having to restart the whole operation after a crash is not
>> ideal, but I don't see how adding a flag actually solves it. The problem
>> is the large databases often store most of
Greetings,
* Tomas Vondra (tomas.von...@2ndquadrant.com) wrote:
> On 02/24/2018 03:11 AM, Andres Freund wrote:
> > On 2018-02-24 03:07:28 +0100, Tomas Vondra wrote:
> >> I agree having to restart the whole operation after a crash is not
> >> ideal, but I don't see how adding a flag actually solves
Hi,
I see the patch also does throttling by calling vacuum_delay_point().
Being able to throttle the checksum workers not to affect user activity
definitely seems like a useful feature, no complaints here.
But perhaps binding it to vacuum_cost_limit/vacuum_cost_delay is not the
best idea? I mean,
Hi hackers,
Here is an attempt at updating parallel.sgml to cover Parallel Hash.
I will be neither surprised nor offended if Robert would like to put
it differently!
--
Thomas Munro
http://www.enterprisedb.com
update-parallel-join-docs.patch
Description: Binary data
40 matches
Mail list logo
