d in the .h
It would certainly be useful to have some state that allows sanity
checking on weird state transitions.
What we would benefit from is a README that gives the theory of
operation, so everyone can read and agree.
Presumably we would need to contact authors of main PL languages t
On 31 October 2017 at 12:01, Michael Paquier wrote:
> On Tue, Oct 31, 2017 at 2:00 PM, Simon Riggs wrote:
>> On 30 October 2017 at 18:58, Simon Riggs wrote:
>>> On 30 October 2017 at 15:22, Simon Riggs wrote:
>>>
>>>>> You forgot to update this fo
documenting the difference in how these are handled, as this is
> important to know for somebody writing an external tool for it.
Changes made, moving to commit the attached patch.
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA,
o have one of these two
> features in mind. I think that depends on what other SQL systems one
> has worked with previously.)
Almost all of the meat happens in later patches, so no other review comments.
That seems seems strange in a patch of this size, but its true.
Procedures are just
.
In step 3 we discover that an entry exists in the index for a committed row.
Since we have a unique index we use it to locate the row we know
exists and UPDATE that.
We don't use a new MVCC snapshot, we do what EPQ does. EPQ is already
violating MVCC for UPDATEs, so why does it matter if we do
On 3 November 2017 at 16:35, Peter Geoghegan wrote:
> Simon Riggs wrote:
>>>>
>>>> The *only* behavioural difference I have proposed would be the *lack*
>>>> of an ERROR in (some) concurrent cases.
>>>
>>>
>>> I think that&#x
On 3 November 2017 at 08:26, Robert Haas wrote:
> On Fri, Nov 3, 2017 at 1:05 PM, Simon Riggs wrote:
>>> Therefore, if MERGE eventually uses INSERT .. ON CONFLICT
>>> UPDATE when a relevant unique index exists and does something else,
>>> such as your proposal of ta
On 3 November 2017 at 07:46, Thomas Kellerer wrote:
> PMFJI
>
>> We seem to have a few options for PG11
>>
>> 1. Do nothing, we reject MERGE
>>
>> 2. Implement MERGE for unique index situations only, attempting to
>> avoid errors (Simon OP)
>>
doesn't behave the
same way as an UPDATE-join, according to SQL:2011 in that it must
throw an error if duplicate changes are requested. That would be hard
to emulate using a parser only version.
I would call it impressively clever but likely fragile, in this case,
though I encourage mo
On 2 November 2017 at 17:06, Robert Haas wrote:
> On Tue, Oct 31, 2017 at 5:14 PM, Simon Riggs wrote:
>> I've proposed a SQL Standard compliant implementation that would do
>> much more than be new syntax over what we already have.
>>
>> So these two claims aren
On 2 November 2017 at 19:16, Peter Geoghegan wrote:
> Simon Riggs wrote:
>>
>> So if I understand you correctly, in your view MERGE should just fail
>> with an ERROR if it runs concurrently with other DML?
>
>
> That's certainly my opinion on the matter
;s snapshot).
So if I understand you correctly, in your view MERGE should just fail
with an ERROR if it runs concurrently with other DML?
i.e. if a race condition between the query and an INSERT runs
concurrently with another INSERT
We have no interest in making that work?
--
Simon Riggs
ion is required for PL procedures and functions.
We could put this as an option into PL/pgSQL, but it seems like it is
a function of the transaction manager rather than the driver.
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training
On 31 October 2017 at 18:55, Peter Geoghegan wrote:
> On Tue, Oct 31, 2017 at 2:25 AM, Simon Riggs wrote:
>> If there are challenges ahead, its reasonable to ask for test cases
>> for that now especially if you think you know what they already are.
>> Imagine we go forwa
the DO command might have a variant to allow you to
execute a procedure that isn't stored?
Not suggesting you implement that, just thinking about why/when the
"stored" word would be appropriate.
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 S
On 30 October 2017 at 18:58, Simon Riggs wrote:
> On 30 October 2017 at 15:22, Simon Riggs wrote:
>
>>> You forgot to update this formula in xlog.c:
>>> distance = (2.0 + CheckPointCompletionTarget) *
>>> CheckPointDistanceEstimate;
>>> /* add
On 31 October 2017 at 12:56, Stephen Frost wrote:
> Simon,
>
> * Simon Riggs (si...@2ndquadrant.com) wrote:
>> On 30 October 2017 at 19:55, Stephen Frost wrote:
>> > I don't think MERGE should be radically different from other database
>> > systems and just
On 30 October 2017 at 19:55, Stephen Frost wrote:
> * Robert Haas (robertmh...@gmail.com) wrote:
>> On Sun, Oct 29, 2017 at 1:19 AM, Simon Riggs wrote:
>> > Nothing I am proposing blocks later work.
>>
>> That's not really true. Nobody's going to be happy
On 30 October 2017 at 19:17, Peter Geoghegan wrote:
> On Mon, Oct 30, 2017 at 11:07 AM, Simon Riggs wrote:
>> Please explain in detail the MERGE SQL statements that you think will
>> be problematic and why.
>
> Your proposal is totally incomplete, so I can only surmise its
On 30 October 2017 at 18:59, Peter Geoghegan wrote:
> It is most emphatically *not* just a "small matter of programming".
Please explain in detail the MERGE SQL statements that you think will
be problematic and why.
--
Simon Riggshttp://www.2ndQuadrant.co
On 30 October 2017 at 15:22, Simon Riggs wrote:
>> You forgot to update this formula in xlog.c:
>> distance = (2.0 + CheckPointCompletionTarget) *
>> CheckPointDistanceEstimate;
>> /* add 10% for good measure. */
>> distance *= 1.10;
>> You c
On 30 October 2017 at 15:31, Michael Paquier wrote:
> On Mon, Oct 30, 2017 at 2:22 PM, Simon Riggs wrote:
>> On 25 October 2017 at 00:17, Michael Paquier
>> wrote:
>>> -* Delete old log files (those no longer needed even for previous
>>> -* checkpoint
On 25 October 2017 at 00:17, Michael Paquier wrote:
> On Mon, Oct 23, 2017 at 11:20 PM, Simon Riggs wrote:
>> Remove the code that maintained two checkpoint's WAL files and all
>> associated stuff.
>>
>> Try to avoid breaking anything else
>>
>>
On 30 October 2017 at 09:44, Robert Haas wrote:
> On Sun, Oct 29, 2017 at 1:19 AM, Simon Riggs wrote:
>> Nothing I am proposing blocks later work.
>
> That's not really true. Nobody's going to be happy if MERGE has one
> behavior in one set of cases and an astonishi
We can then use those test cases to drive developments. If we end up
with code for multiple approaches we will be able to evaluate the
differences between proposals using the test cases produced.
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Suppo
On 28 October 2017 at 22:04, Peter Geoghegan wrote:
> On Sat, Oct 28, 2017 at 12:49 PM, Simon Riggs wrote:
>> Nothing I am proposing blocks later work.
>
> Actually, many things will block future work if you go down that road.
> You didn't respond to the specific po
On 28 October 2017 at 20:39, Peter Geoghegan wrote:
> On Sat, Oct 28, 2017 at 3:10 AM, Simon Riggs wrote:
>> SQL:2011 specifically states "The extent to which an
>> SQL-implementation may disallow independent changes that are not
>> significant is implementation-defi
On 28 October 2017 at 00:31, Michael Paquier wrote:
> On Fri, Oct 27, 2017 at 9:00 AM, Robert Haas wrote:
>> On Fri, Oct 27, 2017 at 4:41 PM, Simon Riggs wrote:
>>> I didn't say it but my intention was to just throw an ERROR if no
>>> single unique index can be
On 27 October 2017 at 15:24, Robert Haas wrote:
> On Fri, Oct 27, 2017 at 10:55 AM, Simon Riggs wrote:
>> Questions?
>
> I think one of the reasons why Peter Geoghegan decided to pursue
> INSERT .. ON CONFLICT UPDATE was that, because it is non-standard SQL
> syntax, he f
hape. This looks more likely
to yield a commitable patch.
Major spanners or objections, please throw them in now cos I don't see any.
Questions?
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Title: MER
d like this. Possibly we could
> consider making it a contrib module rather than including it in core,
> although I don't have strong feelings about it.
I see that SP-GIST includes two operator classes in core, one default.
Makes sense to do the same thing with BRIN and add this new op
On 24 October 2017 at 09:50, Tom Lane wrote:
> Simon Riggs writes:
>> Remove the code that maintained two checkpoint's WAL files and all
>> associated stuff.
>
>> Try to avoid breaking anything else
>
>> This
>> * reduces disk space requirement
Remove the code that maintained two checkpoint's WAL files and all
associated stuff.
Try to avoid breaking anything else
This
* reduces disk space requirements on master
* removes a minor bug in fast failover
* simplifies code
--
Simon Riggshttp://www.2ndQuadran
ell spotted both of you!
Shows that reading code and correcting comments is useful activity.
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
On 11 October 2017 at 15:33, Robert Haas wrote:
> On Sat, Oct 7, 2017 at 7:26 AM, Simon Riggs wrote:
>> PredicateLockTuple() specifically avoids adding an SIRead lock if the
>> tuple already has a write lock on it, so surely it must also be
>> correct to skip the SIRead lock
ignore PredicateLockTuple() for cases where we
are about to update or delete the found tuple.
ISTM that a Before Row Trigger would need to add an SIRead lock since
that is clearly a read.
Thoughts?
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote
eries as either the invoker or the owner. We have that
choice for functions, so we already have the concept and syntax
available. We could have another default at FDW level that specifies
what the default is for that type of FDW, and if that is not
specified, we keep it like it currently is.
--
On 15 September 2017 at 16:34, Konstantin Knizhnik
wrote:
> Attached please find yet another version of the patch.
Thanks. I'm reviewing it.
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Se
to continue to support replacement selection.
Forgive me if I missed the explanation, but how will we handle bounded sorts?
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-
On 24 September 2017 at 21:32, Tomas Vondra
wrote:
> Attached is an updated version of the patch, tweaking the comments.
That looks good, thanks. Marking Ready for Committer to give notice
before commit.
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 2
about out of core dependencies etc.
We plan to submit the next evolution of the code in 2018, in time for
the early cycle of PG12.
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers maili
have done with it. Thoughts?
It makes sense to have a fully detailed output in at least one
parameter setting.
How about use the new psql feature for \if to skip tests if the local
is different to the one for which we have detailed test results?
--
Simon Riggshttp://www.2ndQuadrant
On 16 September 2017 at 21:27, Andres Freund wrote:
> On 2017-09-16 15:59:01 -0400, Tom Lane wrote:
>> This does not seem like a problem that justifies a system-wide change
>> that's much more delicate than you thought.
+1
The change/reason ratio is too hig
(1 row)
Yes, that would have made sense for these to be NULL
> postgres[14388][1]=# SELECT pg_is_in_recovery();
> ┌───┐
> │ pg_is_in_recovery │
> ├───┤
> │ f │
> └───┘
> (1 row)
But not this, since it is a bool
nce we were going to get bugs anyway.
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 14 September 2017 at 16:37, Konstantin Knizhnik
wrote:
>
>
> On 14.09.2017 13:19, Simon Riggs wrote:
>> This works by looking at overall stats, and only looks at the overall
>> HOT %, so its too heavyweight and coarse.
>>
>> I suggested storing stat info on t
t testing was performed,
so it can be re-tested later or tested on a variety of platforms.
Particularly in reorderbuffer, surely we will almost immediately reuse
chunks again, so is it worth issuing free() and then malloc() again
soon after? Does that cause additional overhead we could also avoi
On 14 September 2017 at 10:42, Konstantin Knizhnik
wrote:
>
>
> On 13.09.2017 14:00, Simon Riggs wrote:
>>
>> On 13 September 2017 at 11:30, Konstantin Knizhnik
>> wrote:
>>
>>> The only reason of all this discussion about terms is that I need to
&
On 13 September 2017 at 11:30, Konstantin Knizhnik
wrote:
> The only reason of all this discussion about terms is that I need to choose
> name for correspondent index option.
> Simon think that we do not need this option at all. In this case we should
> not worry about right ter
On 13 September 2017 at 09:09, Andreas Karlsson wrote:
> On 09/13/2017 04:04 AM, Simon Riggs wrote:
>>
>> On 31 August 2017 at 05:16, Peter Eisentraut
>> wrote:
>>>
>>> - index support (and related constraint support)
>>
>>
>> Presuma
ce (both the DETACH PARTITION and also DROP TABLE child cases).
Is this requirement documented or in comments anywhere?
I can't see anything about that, which is a fairly major usage point.
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Rem
mn level INSERT | UPDATE | DELETE privs on it. The generation
happens automatically as part of the write action if stored, or not
until select for virtual. It should be possible to have column level
SELECT privs.
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Develo
On 1 September 2017 at 09:47, Konstantin Knizhnik
wrote:
>
> On 01.09.2017 09:25, Simon Riggs wrote:
>>
>> On 1 September 2017 at 05:40, Thomas Munro
>> wrote:
>>>
>>> On Fri, Jun 9, 2017 at 8:08 PM, Konstantin Knizhnik
>>> wrote:
>>
On 29 August 2017 at 07:58, Simon Riggs wrote:
> On 26 August 2017 at 05:40, Mark Kirkwood
> wrote:
>> On 26/08/17 12:18, Simon Riggs wrote:
>>
>>> On 25 August 2017 at 20:53, Tom Lane wrote:
>>>>
>>>> Greg Stark writes:
>>>>>
re until the time when SQL
Standard is updated and we can implement directly. We already support
the ability to invent new plan nodes, so this could be considered as
part of the plugin.
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training
.
Quick prototype seems like it will deliver quite quickly. I couldn't
see a reason to use "LET" rather than just "SET" which would be the
POLA choice.
Thoughts?
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DB
.
Quick prototype seems like it will deliver quite quickly. I couldn't
see a reason to use "LET" rather than just "SET" which would be the
POLA choice.
Thoughts?
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DB
On 7 September 2017 at 11:31, Tom Lane wrote:
> Simon Riggs writes:
>> I would like to relax the restriction to allow this specific use case...
>> SET work_mem = X; SET max_parallel_workers = 4; SELECT ...
>> so we still have only one command (the last select), yet we
On 7 September 2017 at 11:24, Tom Lane wrote:
> Simon Riggs writes:
>> On 5 September 2017 at 10:22, Tom Lane wrote:
>>> Does anyone want to do further review on this patch? If so, I'll
>>> set the CF entry back to "Needs Review".
>
>> OK, I
l_workers = 4; SELECT ...
so we still have only one command (the last select), yet we have
multiple GUC settings beforehand.
Any reason to disallow that?
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Okay.
>
> Does anyone want to do further review on this patch? If so, I'll
> set the CF entry back to "Needs Review".
OK, I'll review Michael's patch (and confirm my patch is dead)
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development,
On 6 September 2017 at 10:27, Tom Lane wrote:
> Simon Riggs writes:
>> Other than that, I'm good to commit.
>> Any last minute objections?
>
> The docs and comments could stand a bit closer copy-editing by a
> native English speaker. Other than that, it seemed s
s looks useful and good to me.
I've changed this line of code to return NULL rather than return tuple
if (!HeapTupleIsValid(tuple))
return tuple;
Other than that, I'm good to commit.
Any last minute objections?
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL D
On 1 September 2017 at 22:08, Michael Paquier wrote:
> On Sat, Sep 2, 2017 at 1:53 AM, Robert Haas wrote:
>> On Mon, Aug 21, 2017 at 5:30 PM, Simon Riggs wrote:
>>> Thinking ahead, are we going to add a new --no-objecttype switch every
>>> time someone wants it?
&
On 6 September 2017 at 06:38, Tom Lane wrote:
> Simon Riggs writes:
>> Based upon input from Tom and Fabien, I propose this additional doc patch.
>
> I do not think any of this is appropriate, particularly not the reference
> to 7.0.3.
OK, no problem.
SERVER_VERSION_NUM is a
On 5 September 2017 at 11:58, Fabien COELHO wrote:
>
> Hello Simon,
>
>> Does raise the further question of how psql behaves when we connect to
>> a pre-10 server, so we have SERVER_VERSION_NUM but yet it is not set.
>> How does this
>> \if SERVER_VERSION_N
add this to the commitfest.
>
> I added some "stable" tests to your patch taking inspiration from the
> test SQL file. I think those will be stable across machines and runs.
> Please let me know if those look good to you.
Why isn't this an open item for PG10?
--
t, at least there is no loss either.
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
his
\if SERVER_VERSION_NUM < x
behave if unset? Presumably it fails, even though the version *is* less than x
Do we need some macro or suggested special handling?
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Serv
On 5 September 2017 at 06:47, Daniel Gustafsson wrote:
>> On 27 Mar 2017, at 10:27, Simon Riggs wrote:
>>
>> On 7 March 2017 at 23:31, Josh Berkus wrote:
>>> On 03/02/2017 07:13 AM, David Steele wrote:
>>>> Hi Simon,
>>>>
>>>> On 2
lock. Would need a few pushups but seems less scary then trying to
make pending standby actions work well enough to commit.
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mail
ecified multiple times
> should cause an error, and that we could let VACUUM run work N times
> on a relation if it is specified this much. This feels more natural,
> at least to me, and it keeps the code simple.
ISTM there is no difference between
VACUUM a, b
and
VACUUM a; VACUUM b;
If
mentioning it here.
>
> The existing reference is alongside a bunch of other third-party
> tools. Mentioning it at the very top of our release notes would give
> it a pride of place with which I'm not too comfortable.
--
Simon Riggshttp://www.2ndQuadrant.com/
Post
ies using logical decoding, such as pglogical or
> proprietary alternatives, can also provide an alternate route,
> often with lower downtime."
>
> pg_upgrade or pg_dump is really the only option for us using LOs.
Sounds like we could change that, or at least add a
ve the problem, along with linking to the page with the list,
>> perhaps?
>
> Yeah, that seems fine.
A link to our docs page that covers those would be fine.
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training &
dy, so don't see an issue with
mentioning it here.
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On 1 September 2017 at 15:19, Tom Lane wrote:
> Simon Riggs writes:
>> I've added tests to the recent patch to show it works.
>
> I don't think those test cases prove anything (ie, they work fine
> on an unpatched server). With a backslash maybe they would.
>
>
On 31 August 2017 at 12:54, Simon Riggs wrote:
>> The above-described topic is currently a PostgreSQL 10 open item. Simon,
>> since you committed the patch believed to have created it, you own this open
>> item. If some other commit is more relevant or if this does not belon
On 1 September 2017 at 08:09, Michael Paquier wrote:
> On Fri, Sep 1, 2017 at 3:05 PM, Simon Riggs wrote:
>> I'm not sure I see the use case for anyone using SAVEPOINTs in this
>> context, so simply throwing a good error message is enough.
>>
>> Clearly nobody
> patch to CommitFest 2017-3.
>
> This patch needs to be rebased for the upcoming commit fest.
I'm willing to review this if the patch is going to be actively worked on.
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Traini
dexDesc), i);
>
> Thanks!
Does the patch work fully with that change? If so, I will review.
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresq
error message is enough.
Clearly nobody is using this, so lets just lock the door. I don't
think fiddling with the transaction block state machine is anything
anybody wants to do in back branches, at least without a better reason
than this.
Simpler version of original patch attached.
--
Sim
gt; error if the slot is already used by somebody else (slots use their own
>> locking mechanism that does not wait). In this case it seems the
>> walsender which was using slot for previous previous step didn't finish
>> releasing the slot by the time we start new command. We
On 26 August 2017 at 05:40, Mark Kirkwood wrote:
> On 26/08/17 12:18, Simon Riggs wrote:
>
>> On 25 August 2017 at 20:53, Tom Lane wrote:
>>>
>>> Greg Stark writes:
>>>>
>>>> I think this is a particularly old piece of code and we're
ust not in love with Simon's specific proposal, especially
> not if we can't think of a better name for it than "MAINU".
Extended/External would be just fine if you could set the toast
target, so I think a better suggestion would be to make "toast_target"
a pe
On 25 August 2017 at 14:08, Tom Lane wrote:
> Simon Riggs writes:
>> On 25 August 2017 at 13:21, Tom Lane wrote:
>>> If you know compression isn't useful, but you don't want to fail on
>>> wide values, then "external" should serve the purpose.
On 25 August 2017 at 13:21, Tom Lane wrote:
> Simon Riggs writes:
>> Main is roughly what is wanted, yet it always tries to compress. If
>> you already know that won't be useful it should be possible to turn
>> compression off.
>
> If you know compression isn'
On 25 August 2017 at 12:24, Tom Lane wrote:
> Simon Riggs writes:
>> It looks like we need a new Column Storage option for MAIN, Uncompressed.
>> We have these Column Storage options
>> Plain - inline only, uncompressed
>> Main - inline until external as last resor
age 'x' or 'e' external immediately
* 2: Store attributes with attstorage 'x' or 'e' external
* 3: Inline compress attributes with attstorage 'm'
* 4: Store attributes with attstorage 'm' external
* --
*/
Not s
On 23 August 2017 at 08:18, Michael Paquier wrote:
> On Wed, Aug 23, 2017 at 10:59 AM, Masahiko Sawada
> wrote:
>> On Tue, Aug 22, 2017 at 3:23 PM, Simon Riggs wrote:
>>> e.g.
>>> replace RelationGetRelationName() with
>>> RelationGetOptionallyQuali
g of parallel
> plans and this patch also tries to follow the same.
OK, I understand this better now, thanks.
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hacke
rol whether we include this new behaviour with
log_qualified_object_names = on | off
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make ch
any issue.
>
> Changed status to "ready for commiter".
I get the problem, but not this solution. It's too specific and of
zero other value, yet not even exactly specific to the issue. We
definitely don't want --no-extension-comments, but --no-comments
removes ALL comments
to
complete if resources are available.
We have the choice of 1) adding a new optimizable quantity, or of 2)
treating cost = speed, so we actually reduce the cost of a parallel
plan rather than increasing it so it is more likely to be picked.
--
Simon Riggshttp://www.2ndQuadrant.
at looks a lot more like a hack
>> > than reasoned-out behavior. So I'm satisfied if COPY FREEZE does what
>
> Fair summary. ThereAreNoPriorRegisteredSnapshots() has functioned that way
> since an early submission[1], and I don't see that we ever discussed it
> exp
never use global indexes", based upon their absolute uselessness in
Oracle.
> Then, wherever we're using IndexTupleData in the index AM code, we would
> replace it with InMemoryIndexTuple. This should satisfy both your use
> case and mine.
Global indexes are a subset of indirect
On 18 August 2017 at 07:30, Michael Paquier wrote:
> On Thu, Aug 17, 2017 at 6:24 PM, Simon Riggs wrote:
>> On 15 August 2017 at 15:37, Piotr Stefaniak
>> wrote:
>>
>>> One thing I tried was a combination of recovery_target_action =
>>> 'shutdown&#
m not surprised they don't work and have never been tested.
Your suggestion of "furthest" is already the default behaviour.
Why are you using 'now'? Why would you want to pick a randomly
selected end time?
recovery_target_time = 'allballs' sounds fun for recover
the example in RFC 5802
> (SCRAM-SHA-1) section 5. But the analogous example in RFC 7677
> (SCRAM-SHA-256) section 3 uses a length of 16. Should we use that instead?
16 preferred, IMHO
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, R
On 1 August 2017 at 08:37, Amit Langote wrote:
> On 2017/08/01 15:22, Simon Riggs wrote:
>> On 1 August 2017 at 07:16, Amit Langote
>> wrote:
>>> In f27a6b15e656 (9.6 & later), we decided to "Mark CHECK constraints
>>> declared NOT VALID va
1 - 100 of 8526 matches
Mail list logo
