On 10 January 2018 at 04:24, Jeff Davis wrote:
> On Sat, Jan 6, 2018 at 10:38 AM, Simon Riggs wrote:
>> For this to be useful, it needs to include some details of how to use
>> it when people have NOT used range datatypes in their tables.
>
> Good idea. I added an example th
per-optimization.html#id-1.8.3.17.9
https://www.postgresql.org/docs/devel/static/planner-optimizer.html
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 10 January 2018 at 16:08, Robert Haas wrote:
> I think that we really need to think about allowing clients to tell
> the server which GUCs they'd like reported, instead of having a single
> list to which everyone is bound.
+1
--
Simon Riggshttp://www.2
e can
use that to match against in the case of error. XLogPageHeaderData can
be extended by 2 bytes without increasing its size when using 8 byte
alignment. The new 2 byte value is the same anywhere in the file, so
that works quickly and easily. And it doesn't increase the size
;>
>> Thoughts on better wording?
>>
>
> I think that this DEBUG1 message appears when sent any WAL after
> caught up even without this patch. This patch makes this message
> appear at a properly timing. Or am I missing something?
We're not talking about standby
ple complain... asking them not to is unlikely to get anywhere.
We must encourage people to speak up if they see an improvement or a
lack of quality. I have benefited from such comments and they are not
often intended negatively.
Every complaint is not a hard blocker and complainers can also be
w
On 16 January 2018 at 06:21, Michael Paquier wrote:
> On Tue, Jan 16, 2018 at 10:40:43AM +0900, Masahiko Sawada wrote:
>> On Sun, Jan 14, 2018 at 12:43 AM, Simon Riggs wrote:
>>> On 9 January 2018 at 04:36, Masahiko Sawada wrote:
>>> We're not talking about stand
the patch as proposed is about the easiest 3-5% of what would actually
> be required to cover all the holes.
Maybe so.
At present, one major use of Cursors is in postgres_fdw.
In that usage, the query executes and returns all the rows. No other
side execution is possible.
How do we make parallel
quot;when"?
If a parallel cursor is requested, we could simply prevent other
intermediate commands other than FETCH (next).
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
t)}
{substring(Columname, Constants...)}
It would be a shame if people had to remember to use this for the
common and obvious cases.
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 18 January 2018 at 08:59, Konstantin Knizhnik
wrote:
>
>
> On 18.01.2018 11:38, Simon Riggs wrote:
>>
>> On 10 January 2018 at 09:54, Konstantin Knizhnik
>> wrote:
>>
>>> Sorry, issue with documentation is fixed.
>>
>> OK, thanks.
>&g
On 14 January 2018 at 23:15, Petr Jelinek wrote:
> Updated version attached.
Applied, thanks
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
k-of-an-envelope estimate is 9 billion index tuples.
If they did, the gains would be even bigger.
But as you say, a unique index with many duplicates could be a
problem, and index fragmentation would make the situation worse.
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
; which relations it opened and only close those and the rest should be
> closed by caller? That should also remove the other ugly part which is
> that the ExecuteTruncateGuts modifies the input list. What if caller
> wanted to use those relations it sent as parameter later?
Agreed
--
On 19 January 2018 at 05:38, Masahiko Sawada wrote:
> Hi,
>
> Attached patch for fixing a typo in slotfuncs.c
>
> s/possition/position/
Fixed, thanks.
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
te too many? Which
would be a problem in increased planning time.
I have a slight reservaton about whether 1.25x is still a sensible
heuristic. Should we add a parameter for that to allow testing during
beta?
Marking as Ready For Committer.
--
Simon Riggshttp://www.2ndQuadrant.com
On 17 January 2018 at 05:49, Jeff Davis wrote:
> On Wed, Jan 10, 2018 at 7:49 AM, Simon Riggs wrote:
>> Do we optimize for TIMESTAMP <@ RANGE as well?
>
> Not currently. It requires a little extra complexity because empty
> ranges will match anything and need special
On 19 January 2018 at 08:25, Simon Riggs wrote:
> On 17 January 2018 at 05:49, Jeff Davis wrote:
>> On Wed, Jan 10, 2018 at 7:49 AM, Simon Riggs wrote:
>>> Do we optimize for TIMESTAMP <@ RANGE as well?
>>
>> Not currently. It requires a little extra comple
ust wasted cycles.
The subscriber side already has various requirements, such as manually
created DDL, so requiring sensible FKs is not so bad. This situation
will improve over next few years.
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
nd ROLLBACK in cursor loop bodies. But I think people will
>> eventually want it.
>
> The may want it, but silently promoting all cursors to held ones is
> not the way to give it to them, unless we narrow it down the the
> 'for-loop derived cursor' only.
I don'
also prevent SAVEPOINTs, though
that seems not to be intended.
The two cases are dissimilar and it would be possible to block the
former but allow the latter.
It's not documented or tested that SET LOCAL would work or not work.
Does it work?
--
Simon Riggshttp://www.2ndQuadrant
saction and a concurrent abort is
requested then decoding should be interrupted at the next sensible
point. Allowing the two actions to occur without interlock is an
issue, so I suggest we just don't do it, rather than allow it and fix
subsequent breakage, which is what I understand this pa
On 23 January 2018 at 05:08, Jeff Davis wrote:
> On Fri, Jan 19, 2018 at 2:07 AM, Simon Riggs wrote:
>> err... that isn't correct. An empty range matches nothing, so can be
>> ignored in joins.
>>
>> So probably best to explain some more, please.
>
> The sem
g to be unlocked. While it is
locked the 2PCxact cannot be aborted or committed.
There is no danger of accidental abort because the prepare has persistent state.
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 24 January 2018 at 01:35, Peter Geoghegan wrote:
> On Tue, Jan 23, 2018 at 5:51 AM, Simon Riggs wrote:
>>> Not yet working
>>> * Partitioning
>>> * RLS
>>>
>>> Based on this successful progress I imagine I'll be looking to commit
>>&
On 24 January 2018 at 13:15, Feike Steenbergen
wrote:
> On 5 January 2018 at 15:19, Simon Riggs wrote:
>> Yup, I got this.
>
> I saw the commit in the master branch but not in the REL_10_STABLE branch,
> I'm totally not up-to-date with the backpatching process, but I was
ort hook?). That call will
just return when and if it is OK to abort. Any waiting or throwing of
ERRORs can occur inside the plugin.
The plugin can provide a function to allow an abort that type of abort
if it wishes, but no new core functionality required for that. If
needed, we would wait on a latch the plugin provides for that.
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
d the abort path is not considered one we
need to optimize.
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
omments were based on the idea that 2PC patch would
simply block aborts, which of course will not work for streaming,
hence the difference)
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 29 January 2018 at 14:13, Tomas Vondra wrote:
> 4) inspect the new row (which we still have in reorderbuffer)
>
> 5) Kabooom! The row has column "c" which we don't see in the catalog.
We don't use caches? Why does a cache miss cause it to explode?
--
Simon Ri
cases also.
MERGE as submitted here follows all MVCC rules similar to an UPDATE
join. If it hits a problem with concurent activity it throws
ERROR: could not serialize access due to concurrent update
to make sure there is no ambiguity (as described directly above).
As we discussed earlier, rem
ocumentation about recommended use cases. Probably it will be very often
> question.
That is more qualitative assessment of each, which I think I will defer on.
This patch is about implementing the SQL Standard compliant MERGE
command which is widely used in other databases and by various tools.
Overall, I'm following the style of development process you have
yourself used a number of times now. Waiting for mega-patches to be
complete is not as useful as phased development.
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 29 January 2018 at 15:44, Bruce Momjian wrote:
> On Mon, Jan 29, 2018 at 03:12:23PM +0000, Simon Riggs wrote:
>> On 29 January 2018 at 14:55, Pavel Stehule wrote:
>>
>> > My note was not against MERGE or INSERT ON CONFLICT. If I understand to
>> > this
>
On 29 January 2018 at 16:06, Tom Lane wrote:
> Simon Riggs writes:
>> On 29 January 2018 at 15:07, Robert Haas wrote:
>>> An argument could be made that this patch is already too late for PG
>>> 11, because it's a major feature that was not submitted in relativ
everything benefits from further review.
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 29 January 2018 at 16:50, Tom Lane wrote:
> Bruce Momjian writes:
>> On Mon, Jan 29, 2018 at 04:34:48PM +0000, Simon Riggs wrote:
>>> ... If unfinished means it has caveats
>>> that is different to unfinished meaning crappy, risky, contentious
>>> etc..
&
On 29 January 2018 at 16:23, Chapman Flack wrote:
> On 01/29/2018 11:13 AM, Simon Riggs wrote:
>> On 29 January 2018 at 15:44, Bruce Momjian wrote:
>>> Uh, if we know we are going to get question on this, the patch had
>>> better have an explanation of when to use
On 29 January 2018 at 17:35, Peter Geoghegan wrote:
> On Mon, Jan 29, 2018 at 8:51 AM, Simon Riggs wrote:
>> On 29 January 2018 at 16:44, Bruce Momjian wrote:
>>
>>> I think the question is how does it handle cases it doesn't support?
>>> Does it give
On 29 January 2018 at 20:41, Peter Geoghegan wrote:
> On Mon, Jan 29, 2018 at 6:11 AM, Simon Riggs wrote:
>> New patch attached that correctly handles all known concurrency cases,
>> with expected test output.
>
> This revision, v13, seems much improved in this area.
>
ou
>> change your mind on that.
>
> You're mistaken. Nothing I've said here is inconsistent with my
> previous remarks on how we deal with concurrency.
Please see here
https://www.postgresql.org/message-id/20171102191636.GA27644%40marmot
On 2 November 2017 at 19:16, Peter Geoghegan
ow agree with doing that and are happy that there are no
dangers, then I'm happy we now have consensus again and we can
continue implementing MERGE for PG11.
This is a good outcome, thanks, our users will be happy.
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Old + New for check = 2
plus calculate again in index = 3
?
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 1 February 2018 at 08:49, Konstantin Knizhnik
wrote:
>
>
> On 01.02.2018 03:10, Simon Riggs wrote:
>>
>> On 10 January 2018 at 09:54, Konstantin Knizhnik
>> wrote:
>>
>>> (new version attached)
>>
>> Why this comment?
>>
>>
rently throws an error, as requested. It looks
to be possible, but it would require some variation of EvalPlanQual.
My prototype of that doesn't yet work, so I can't yet confirm whether
it is even possible. If it is, I will submit as an option for PG11.
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
would we like to change from ERROR to
success? or which new test would you like to add?
Thanks
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Author.
Dean and John's results show that different algorithms work better for
different cases.
How about we make ANALYZE's MCV algorithm pluggable? And then include,
say, 2 additional algorithms.
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
hat WAIT LSN is good syntax because this allows us to wait
for something else in future.
Without having reviewed the patch, I think we want this feature in PG11.
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 1 February 2018 at 12:45, Simon Riggs wrote:
> I think it would be very helpful if we could discuss everything with
> direct relevance to v14, so this becomes a patch review, not just a
> debate.
> i.e. which isolation test would we like to change from ERROR to
> success? or
much just 2^-nbits.
The full 8 bytes of the xl_prev pointer aren't working for a living.
More isn't better, always.
If we really can't persuade you of that, it doesn't sink the patch. We
can have the WAL pointer itself - it wouldn't save space but it would
at least alleviate the spinlock.
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
arch and I will shepherd this to
commit.
Thomas, I suggest we also do what Robert suggested elsewhere which was
to have an connection option that returns xid or lsn (or both) via the
protocol, so we can use that with the WAIT command and you can have
the overall causal consistency feature
On 1 February 2018 at 09:32, Simon Riggs wrote:
> OK, thanks. Just checking my understanding and will add to the
> comments in the patch.
I'm feeling good about ths now, but for personal reasons won't be
committing this until late Feb/early March.
--
Simon Riggs
On 2 February 2018 at 18:46, Robert Haas wrote:
> On Fri, Feb 2, 2018 at 3:46 AM, Simon Riggs wrote:
>> In PG11, I propose the following command, sticking mostly to Ants'
>> syntax, and allowing to wait for multiple events before it returns. It
>> doesn't hold snap
e for the
> patch. We can get to this stuff later.
There are no concurrency issues. The patch gives the correct answer in
all cases, or an error to avoid problems. We've agreed that it is
desirable we remove some of those if possible, though they are there
as a result of our earlier discussions.
> Note that I consider cleaning
> up the Query and plan representations to be prerequisite to commit.
You'll need to be more specific. Later patches do move some things.
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
NOT MATCHED
> AND cast(null as int2) = pg_catalog.lastval()
>THEN DO NOTHING;
>
> -- ERROR: unrecognized node type: 114
> MERGE INTO public.found_test_tbl as target_0
> USING public.itest7a as ref_0
> ON target_0.a = ref_0.a
> WHEN NOT MATCHED
>THEN INSERT VALUES ((select a from public.rtest_t3 limit 1 offset 6));
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
happened to have those values set
equal.
Minor bug, thanks for spotting.
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 3 February 2018 at 23:17, Peter Geoghegan wrote:
> On Sat, Feb 3, 2018 at 2:15 PM, Simon Riggs wrote:
>>> I started looking at SQL Server's MERGE to verify that it also does
>>> not impose any restrictions on subselects in a MERGE UPDATE's
>>> targetli
;
> It is not clear to me what is exactly your concern if we try to follow
> #2? To me, #2 seems like a natural choice.
At first, but it gives an anomaly so is not a good choice. The patch
does behavior #5, it rechecks the conditions with the latest row.
Otherwise
WHEN MATCHED AND a=0 THEN UPD
atever we decide for concurrent behavior will affect how we support
them. We can't move forwards on them until we have that nailed down.
I could give a longer technical commentary but I will be unavailable
now for some time, so unable to give further discussion.
--
Simon Riggs
ty-related module, so
users can't see how it is configured, as well as being more
tightly integrated so it can be better tailored to various uses
Summary is that the choice is not random, nor mere preference
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.c
> > Shouldn't we ideally discuss the API first?
>
> I wonder if every GUC that takes an OS command should allow a shared
> object to be specified --- maybe control that if the command string
> starts with a # or something.
>
Very good idea
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Solutions for the Enterprise
otice that almost all of the infrastructure already exists to
support this, so this patch does very little. It avoids additional locking
on main execution paths and as far as I am aware, does not break anything.
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com
TransactionIdIsCurrentTransactionId() doesn't seem to be well optimized for
the case when an xid has not yet been assigned, so for read only
transactions.
A patch for this is attached.
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQ
he end of their execution for whatever reason then you can
see a consistent result."
I think I already covered your concerns in my suggested docs for this
feature.
I'm not suggesting it for general use.
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Solutions for the Enterprise
On Wed, 18 Dec 2019 at 14:06, Tom Lane wrote:
> Simon Riggs writes:
> > I present a patch to allow READ UNCOMMITTED that is simple, useful and
> > efficient.
>
> Won't this break entirely the moment you try to read a tuple containing
> toasted-out-of-line values?
On Wed, 18 Dec 2019 at 17:35, Robert Haas wrote:
> On Wed, Dec 18, 2019 at 10:18 AM Simon Riggs
> wrote:
> > This was my first concern when I thought about it, but I realised that
> by taking a snapshot and then calculating xmin normally, this problem would
> go away.
>
On Wed, 18 Dec 2019 at 18:37, Tom Lane wrote:
> Simon Riggs writes:
> > So this is the same discussion as elsewhere about potentially aborted
> > transactions...
> > AFAIK, the worst that happens in that case is that the reading
> transaction
> > will e
like general agreement on that point from others on this thread.
> That should be reserved for something that has reasonably
> consistent, standards-compliant behavior.
>
Since we're discussing it, exactly what standard are we talking about here?
I'm not saying I care about t
On Wed, 18 Dec 2019 at 19:29, Heikki Linnakangas wrote:
> On 18/12/2019 20:46, Mark Dilger wrote:
> > On 12/18/19 10:06 AM, Simon Riggs wrote:
> >> Just consider this part of the recovery toolkit.
> >
> > In that case, don't call it "read uncommitted&
On Thu, 19 Dec 2019 at 02:22, Andres Freund wrote:
> Hi,
>
> On 2019-12-18 18:06:21 +0000, Simon Riggs wrote:
> > On Wed, 18 Dec 2019 at 17:35, Robert Haas wrote:
> >
> > > On Wed, Dec 18, 2019 at 10:18 AM Simon Riggs
> > > wrote:
> > > > Thi
On Thu, 19 Dec 2019 at 12:42, Bernd Helmle wrote:
> Am Donnerstag, den 19.12.2019, 00:13 + schrieb Simon Riggs:
> > So the consensus is for a more-specifically named facility.
> >
> > I was aiming for something that would allow general SELECTs to run
> > with
On Thu, 19 Dec 2019 at 19:27, Robert Haas wrote:
> On Wed, Dec 18, 2019 at 5:07 AM Simon Riggs wrote:
> > TransactionIdIsCurrentTransactionId() doesn't seem to be well optimized
> for the case when an xid has not yet been assigned, so for read only
> transactions.
> &g
sNormal(xid) and replace with a test for
TransactionIdIsNormal(topxid).
Such a frequently used function is worth discussing, just as we previously
optimised TransactionIdIsInProgress() and MVCC visibility routines, where
we discussed what the most common routes through the functions were before
decid
On Fri, 20 Dec 2019 at 17:46, Tom Lane wrote:
> Simon Riggs writes:
> > On Fri, 20 Dec 2019 at 13:07, Robert Haas wrote:
> >> With regard to this point, I second Tomas's comments.
>
> > I also agree with Tomas' comments. I am explaining *why* it will b
On Mon, 6 Jan 2020 at 02:56, Justin Pryzby wrote:
> commit 6f3a13ff058f15d565a30c16c0c2cb14cc994e42 Enhance docs for ALTER
> TABLE lock levels of storage parms
> Author: Simon Riggs
> Date: Mon Mar 6 16:48:12 2017 +0530
>
>
> SET ( class="PARAMETER&q
rage params" rather
> than
> "this command", since planner params never "modify the table contents".
> Possibly other instances in the document (and createtable) should be
> changed
> for consistency.
>
Yes, but it's not a correction, just a different preference of wording.
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Solutions for the Enterprise
what I am interested in.
>
Hopefully there will be no danger of me gaining access if I have a crafted
rolename?
postgres=# create role "&backdoor";
CREATE ROLE
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Solutions for the Enterprise
to search for data with historic snapshots.
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Wed, 24 Apr 2019 at 12:55, Etsuro Fujita
wrote:
> > My point is that this should not be necessary.
>
> In my opinion, I think this is necessary...
>
Could we decide by looking at what FDWs are known to exist? I hope we are
trying to avoid breakage in the smallest number of F
o I suggest we do
the same on XLogBackgroundFlush() so callers can indicate whether they want
it to be flexible or not.
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
work on the session until COMMIT/ABORT. That means we can then
drop locks on sesion temporary tables and drop on-commit temp tables when
we hit the prepare, not try and hold them for later.
A patch is needed to implement the above, but I think we can forget the
current patch as not needed.
--
Si
On Thu, 23 May 2019 at 16:55, Andres Freund wrote:
> Hi,
>
> On 2019-05-23 12:36:09 +0100, Simon Riggs wrote:
> > The ONLY case where this matters is if someone does a PREPARE and then
> > starts doing other work on the session. Which makes no sense in the
> normal
> &
On Fri, 24 May 2019 at 01:39, Michael Paquier wrote:
> On Thu, May 23, 2019 at 08:54:59AM -0700, Andres Freund wrote:
> > On 2019-05-23 12:36:09 +0100, Simon Riggs wrote:
> >> The ONLY case where this matters is if someone does a PREPARE and then
> >> starts doin
ted in
> that transaction, use) etc the temp table after the PREPARE.
>
I don't see there is a problem here, but run out of time to explain more,
for a week.
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
ers ended up.
Presumably stored values can just be read from storage, so no overhead in
after triggers?
Having the stored values show as NULL would be OK for virtual ones. But
what do we do if the column is NOT NULL? Do we still have nulls then?
It would be useful to have a way to generate
r due to ordering being required from the return value of some
> precision loss function.
>
Anything left anchored would benefit, so SUBSTR(), TRIM() etc
Main use for this would be where the partition condition is a function, so
we can still order by partitions easily.
--
Simon Riggs
hould be to just treat them as a value.
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Wed, 31 Oct 2018 at 08:29, Erik Rijkers wrote:
> On 2018-10-31 09:15, Simon Riggs wrote:
> > On Wed, 31 Oct 2018 at 07:58, Erikjan Rijkers wrote:
> >
> >
> >> I have also noticed that logical replication isn't possible on tables
> >> with a gen
ored generated columns should be treated just like we'd treat a column
value added by a trigger.
e.g. if we had a Timestamp column called LastUpdateTimestamp we would want
to send that value
> Similar considerations also apply to foreign tables. What is the
> meaning of a stored generated
uery shouldn't make other cases more difficult from a
behavioral perspective just to avoid the ERROR. The ERROR sounds annoying,
but not sure how annoying avoiding it would be.
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Tue, 6 Nov 2018 at 10:56, Robert Haas wrote:
> On Tue, Nov 6, 2018 at 1:54 PM Simon Riggs wrote:
> > Error in the COPY or in the DDL? COPY preferred. Somebody with insert
> rights shouldn't be able to prevent a table-owner level action. People
> normally drop partitions
On Tue, 6 Nov 2018 at 11:06, Robert Haas wrote:
> On Tue, Nov 6, 2018 at 2:01 PM Simon Riggs wrote:
> > If you can remove the ERROR without any other adverse effects, that
> sounds great.
> >
> > Please let us know what, if any, adverse effects would be caused so
der locale issues etc.), so
> we need to recompute the generated columns on the target anyway, so it's
> pointless to send the already computed stored values.
>
Makes sense.
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
aving indexes defined using WHERE NOT NULL is a very important use case.
> Assuming we go that route, I'd propose we still yank the existing todo
> comment about turning it into a GUC.
>
Agreed
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
pportunity to make improvements on
> the backup side as well.
>
> I'll submit a patch for the 2019-01 commitfest.
>
-1 for removal, in this release
It's not there because anyone likes it, it's there because removing it is a
risk
Recent changes are the reason to keep it,
> all of the other 3rd party backup solutions and any restore solution
> that a user has come up with, are going to have to be changed to deal
> with the changes in how recovery works, so this is a good time to make
> these changes.
>
If those tools are updated and the changes all
hould
backpatch this change, assuming it is acceptable.
This patch doesn't do it, but the suggestion that we touch
GetSnapshotData() in the same way so we de-duplicate eagerly is a different
matter and would need careful performance testing to ensure we don't slow
down 2PC users.
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
; handling different types of PK, including compound keys, PK updates,...
Try locking the root tid rather than the TID, that is at least unique
per page for a chain of tuples, just harder to locate.
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 20 February 2018 at 13:19, Konstantin Knizhnik
wrote:
>
>
> On 20.02.2018 14:26, Simon Riggs wrote:
>>
>> On 15 February 2018 at 16:00, Konstantin Knizhnik
>> wrote:
>>
>>> So in heap_acquire_tuplock all competing transactions are waiting fo
ever rewind. So it would be
good if we could pass a parameter that skips the rewind since it will
never be needed and causes a performance hit. What I imagine is we can
just persist the as-yet unfetched portion of the cursor from the
current row onwards, rather than rewind and store the w
201 - 300 of 716 matches
Mail list logo
