On Tue, Jun 22, 2021 at 7:15 AM Amit Kapila wrote:
>
> On Mon, Jun 21, 2021 at 6:38 PM Simon Riggs
> wrote:
> >
> > New chapter for Hash Indexes, designed to help users understand how
> > they work and when to use them.
> >
> > Mostly newly written, but a
On Wed, Jan 20, 2021 at 3:53 PM James Coleman wrote:
>
> On Wed, Jan 20, 2021 at 9:58 AM Simon Riggs wrote:
> >
> > On Wed, 20 Jan 2021 at 14:21, James Coleman wrote:
> >
> > > An alternative approach that occurred to me while typing this reply: a
> > &g
On Thu, Mar 18, 2021 at 6:20 AM Craig Ringer
wrote:
>
> On Mon, 15 Mar 2021 at 21:01, David Steele wrote:
>>
>> On 11/18/20 5:23 AM, Simon Riggs wrote:
>> > On Wed, 18 Nov 2020 at 06:42, Craig Ringer
>> > wrote:
>> >>
>>
New chapter for Hash Indexes, designed to help users understand how
they work and when to use them.
Mostly newly written, but a few paras lifted from README when they were helpful.
--
Simon Riggshttp://www.EnterpriseDB.com/
doc_hash_index.v1.patch
Description: Binary data
Seems like we can skip the uniqueness check if indexUnchanged, which
will speed up non-HOT UPDATEs on tables with B-Trees.
Passes tests.
Comments?
--
Simon Riggshttp://www.EnterpriseDB.com/
skip_nonHOT_btree_unique_check.v1.patch
Description: Binary data
ecoding SQL Interface
> > System Catalogs Related to Logical Decoding
> >
>
> I think this is worth considering but we might want to discuss this as
> a separate change/patch.
Makes sense.
Thanks
--
Simon Riggshttp://www.EnterpriseDB.com/
897795240cfaaed724af2f53ed2c50c9862f951f forgot to reduce the lock
level for CHECK constraints when allowing them to be NOT VALID.
This is simple and safe, since check constraints are not used in
planning until validated.
--
Simon Riggshttp://www.EnterpriseDB.com
The docs don't explicitly mention the reduced lock level for this subcommand.
--
Simon Riggshttp://www.EnterpriseDB.com/
alter_table_validate_lock_level.patch
Description: Binary data
On Thu, 8 Apr 2021 at 18:15, Alvaro Herrera wrote:
>
> On 2021-Apr-08, Simon Riggs wrote:
>
> > On Thu, 8 Apr 2021 at 16:58, David Steele wrote:
>
> > > It's not clear to me which patch is which, so perhaps move one CF entry
> > > to next CF and clar
On Thu, 8 Apr 2021 at 17:44, David Steele wrote:
>
> On 4/8/21 12:29 PM, Simon Riggs wrote:
> > On Thu, 8 Apr 2021 at 16:58, David Steele wrote:
> >
> >>>> It has been five months since this patch was updated, so marking
> >>>> Returned with Feedba
CF entry
> to next CF and clarify which patch is current?
Entry: Maximize page freezing
has this patch, perfectly fine, awaiting review from Alvaro since 29 Nov.
one_freeze_then_max_freeze.v7.patch
Other patch is awaiting changes.
--
Simon Riggshttp://www.EnterpriseDB.com/
On Thu, 8 Apr 2021 at 16:23, David Steele wrote:
>
> On 3/17/21 4:50 PM, Simon Riggs wrote:
> > On Fri, 12 Mar 2021 at 22:16, Tomas Vondra
> > wrote:
> >>
> >> On 1/28/21 2:33 PM, Simon Riggs wrote:
> >>> On Thu, 28 Jan 2021 at 12:53, Masahiko S
On Fri, 12 Mar 2021 at 22:16, Tomas Vondra
wrote:
>
> On 1/28/21 2:33 PM, Simon Riggs wrote:
> > On Thu, 28 Jan 2021 at 12:53, Masahiko Sawada wrote:
> >
> >> This entry has been "Waiting on Author" status and the patch has not
> >> been updated s
On Mon, Jan 18, 2021 at 11:19 PM japin wrote:
>
>
> On Fri, 15 Jan 2021 at 00:22, Simon Riggs
> wrote:
> > As you may be aware the NOT VALID qualifier currently only applies to
> > CHECK and FK constraints, but not yet to unique indexes. I have had
> > cu
On Mon, Jan 18, 2021 at 12:34 AM David Fetter wrote:
>
> On Thu, Jan 14, 2021 at 04:22:17PM +, Simon Riggs wrote:
> > As you may be aware the NOT VALID qualifier currently only applies to
> > CHECK and FK constraints, but not yet to unique indexes. I have had
> > cus
On Thu, 28 Jan 2021 at 12:53, Masahiko Sawada wrote:
> This entry has been "Waiting on Author" status and the patch has not
> been updated since Nov 30. Are you still planning to work on this?
Yes, new patch version tomorrow. Thanks for the nudge and the review.
On Tue, Jan 26, 2021 at 12:51 PM Vik Fearing wrote:
>
> On 1/26/21 1:16 PM, Simon Riggs wrote:
> > On Tue, Jan 26, 2021 at 11:33 AM Vik Fearing
> > wrote:
> >>
> >> On 1/11/21 3:02 PM, Simon Riggs wrote:
> >>> * UPDATE foo SET start_timestamp =
On Tue, Jan 26, 2021 at 11:33 AM Vik Fearing wrote:
>
> On 1/11/21 3:02 PM, Simon Riggs wrote:
> > * UPDATE foo SET start_timestamp = DEFAULT should fail but currently doesn't
>
> I'm still in the weeds of reviewing this patch, but why should this
> fail? It sho
SETs to be SET LOCAL.
The point is that if we declare ahead of time that the transaction
will be reset then we can act differently and more easily for various
circumstances, for SETs, for Temp tables and others.
--
Simon Riggshttp://www.EnterpriseDB.com/
On Fri, Jan 15, 2021 at 4:56 PM Surafel Temesgen wrote:
>
>
>
> On Fri, Jan 15, 2021 at 12:22 AM Simon Riggs
> wrote:
>>
>> SELECT * FROM foo FOR SYSTEM_TIME AS OF ...
>> should NOT include the Start and End timestamp columns
>> because this acts li
On Fri, Jan 15, 2021 at 4:46 PM Surafel Temesgen wrote:
>
>
>
> On Fri, Jan 15, 2021 at 12:27 AM Simon Riggs
> wrote:
>>
>>
>> Yes, I think it can. The current situation is that the Start or End is
>> set to the Transaction Start Timestamp.
>> So if
On Thu, Jan 14, 2021 at 5:42 PM Surafel Temesgen wrote:
>
> Hi Simon,
> Thank you for all the work you does
No problem.
> On Mon, Jan 11, 2021 at 5:02 PM Simon Riggs
> wrote:
>>
>>
>>
>> * Anomalies around use of CURRENT_TIMESTAMP are not discussed or r
WEEN x AND y
SHOULD include the Start and End timestamp columns
since this form of query can include multiple row versions for the
same row, so it makes sense to see the validity times
--
Simon Riggshttp://www.EnterpriseDB.com/
bility, syntax and requirements before I do that.
I can also add similar syntax for UNIQUE and PK constraints.
Thoughts please?
--
Simon Riggshttp://www.EnterpriseDB.com/
alter_index_set_unique_not_valid.v4.patch
Description: Binary data
would exist.
> 9) parsenodes.h
>
> Should we rename mergeTarget_relation to mergeTargetRelation? The
> current name seems like a mix between two naming schemes.
+1
We've had code from 4-5 people in the patch now, so I will re-review
myself to see if I can shed light on anything.
--
Simon Riggshttp://www.EnterpriseDB.com/
itional tests so we can see more
clearly that the tests fail on the present patch.
I will post more on this next week.
--
Simon Riggshttp://www.EnterpriseDB.com/
On Thu, Jan 7, 2021 at 5:59 PM Simon Riggs wrote:
>
> On Mon, Jan 4, 2021 at 2:24 PM Masahiko Sawada wrote:
> > Please also note the v7 patch cannot be applied to the current HEAD. I'm
> > switching the patch as Waiting on Author.
>
> Surafel, please say whether y
On Sat, Jan 2, 2021 at 6:44 PM Jeff Davis wrote:
>
> On Wed, 2020-12-30 at 21:23 +, Simon Riggs wrote:
> > But you cannot seriously argue that a one line patch that changes
> > user
> > visible behavior can be acceptable in Postgres core without tests or
> >
could
be earlier than start time, so that is just wrong. Ideally we would
use commit timestamp and fill the values in later. So the only thing
that makes sense for me is to use the dynamic time of insertion while
we hold the buffer lock, otherwise we will get anomalies.
The wo
ABLES IN SCHEMA test" at
the top of your script? You say there is a problem, but don't describe
the precise problem. Can you give a fully worked example so we can
understand how to resolve?
The meaning of GRANT and REVOKE is now defined by SQL Standard, so not
something we can easily change.
--
Simon Riggshttp://www.EnterpriseDB.com/
nly. Your data and/or
query accuracy may be at risk if you rely on this."
--
Simon Riggshttp://www.EnterpriseDB.com/
On Tue, 15 Dec 2020 at 23:59, Jeff Davis wrote:
>
> On Tue, 2020-12-15 at 17:37 +, Simon Riggs wrote:
> >
> > I definitely don't agree with the premise that all existing heap
> > options should be common across all new or extension tableAMs. There
> > are
haviour of
> table_multi_insert() API for unlogged tables?
I found the additional performance of Paul Guo's work to be compelling
and the idea workable for very large loads.
Surely LockRelationForExtension() is all the inter-process
coordination we need to make this work for parallel loads?
--
Simon Riggshttp://www.EnterpriseDB.com/
On Wed, 30 Dec 2020 at 13:04, Michael Paquier wrote:
> > Yes, we did think of this feature already and rejected it.
>
> I don't recall seeing such a discussion. Do you have some references?
> Just a matter of curiosity :)
Off-list discussions.
--
Simon Riggs
rhaps at a later date.
>
> Here is the highly anticipated and quite underwhelming second part of
> this patch set.
Looks great, but no test to confirm it works. I would suggest adding a
test and committing directly since I don't see any cause for further
discussion.
--
Simon Riggshttp://www.EnterpriseDB.com/
bility in the release notes.
> > This patch should have more tests. Something could be added in
> > create_am.sql where there is a fake heap2 as table AM.
>
> Yes, I had already done that locally.
There are no tests for the new functionality, please could you add some?
--
Simon Riggshttp://www.EnterpriseDB.com/
hen
back up again. It must be a one-way transition from "unsafe" to a
higher level, so if people want to use this for temp reporting servers
or initial loading, great, but they can't use it as a quick speed-up
for databases containing needs-to-be-safe data. Possibly the state
change mig
nced to do whatever else we agree is desirable.
Do we need something like DISCARD ALL EXCEPT PREPARED STATEMENTS; ??
If there are different requirements for each pooler, what are they?
--
Simon Riggshttp://www.EnterpriseDB.com/
s if we are dropping them
all anyway.
Patch attached, passes make check with new tests added.
Comments welcome.
--
Simon Riggshttp://www.EnterpriseDB.com/
transaction_cleanup.v4.patch
Description: Binary data
ee with the premise that all existing heap
options should be common across all new or extension tableAMs. There
are dozens of such options and I don't believe that they would all
have meaning in all future storage plugins.
I think options should just work exactly the same for Indexes and Ta
n skip to PG15.
--
Simon Riggshttp://www.EnterpriseDB.com/
and
repeated planning of sub-plans for similar partitions.
--
Simon Riggshttp://www.EnterpriseDB.com/
I'm changing the patch to only work with Xids not both xids and
multixacts. If this gets committed we can think more about multixacts
and whether to optimize freezing them in the same situation or not.
--
Simon Riggshttp://www.EnterpriseDB.com/
one_freeze_then_max_freeze.v7.patch
Description: Binary data
On Fri, 20 Nov 2020 at 11:47, Simon Riggs wrote:
>
> On Fri, 20 Nov 2020 at 10:15, Simon Riggs wrote:
> >
> > On Fri, 20 Nov 2020 at 01:40, Masahiko Sawada wrote:
> > >
> > > On Thu, Nov 19, 2020 at 8:02 PM Simon Riggs wrote:
> > > >
> >
they may contain more tuples than before and
will increase the probability that the page is marked all_frozen.
So yes, as you say, the net effect will be to reduce the number of
write I/Os in subsequent vacuums required to move forward
relfrozenxid.
--
Simon Riggshttp://www.EnterpriseDB.com/
On Fri, 20 Nov 2020 at 10:15, Simon Riggs wrote:
>
> On Fri, 20 Nov 2020 at 01:40, Masahiko Sawada wrote:
> >
> > On Thu, Nov 19, 2020 at 8:02 PM Simon Riggs wrote:
> > >
> > > On Wed, 18 Nov 2020 at 17:59, Robert Haas wrote:
> > > >
>
since that would
slow it down when we want to speed it up.
I've updated the patch to match your proposal, so we can compare. It
seems a shorter patch.
(This patch is an optimization that is totally independent to the
other proposals on this thread).
--
Simon Riggshttp://www.EnterpriseDB.com/
one_freeze_then_max_freeze.v6.patch
Description: Binary data
On Fri, 20 Nov 2020 at 01:40, Masahiko Sawada wrote:
>
> On Thu, Nov 19, 2020 at 8:02 PM Simon Riggs wrote:
> >
> > On Wed, 18 Nov 2020 at 17:59, Robert Haas wrote:
> > >
> > > On Wed, Nov 18, 2020 at 12:54 PM Simon Riggs
> > &g
On Wed, 18 Nov 2020 at 02:04, Alvaro Herrera wrote:
>
> On 2020-Nov-17, Simon Riggs wrote:
>
> > As an additional optimization, if we do find a row that needs freezing
> > on a data block, we should simply freeze *all* row versions on the
> > page, not just the one
On Wed, 18 Nov 2020 at 17:59, Robert Haas wrote:
>
> On Wed, Nov 18, 2020 at 12:54 PM Simon Riggs wrote:
> > Patches attached.
> > 1. vacuum_anti_wraparound.v2.patch
> > 2. vacuumdb_anti_wrap.v1.patch - depends upon (1)
>
> I don't like the use of ANTI_WRAPA
zation, if we do find a row that needs freezing
> > on a data block, we should simply freeze *all* row versions on the
> > page, not just the ones below the selected cutoff. This is justified
> > since writing the block is the biggest cost and it doesn't make much
>
On Wed, 18 Nov 2020 at 06:42, Craig Ringer
wrote:
>
> On Fri, Nov 13, 2020 at 7:24 PM Simon Riggs wrote:
>>
>>
>> What I'm proposing is an option to add 16 bytes onto each COMMIT
>> record
>
>
> Would it make sense to write this at the time we
On Fri, 13 Nov 2020 at 11:24, Simon Riggs wrote:
>
> On Fri, 13 Nov 2020 at 00:50, tsunakawa.ta...@fujitsu.com
> wrote:
> >
> > From: Simon Riggs
> > > If a rogue user/process is suspected, this would allow you to identify
> > > more easily the
On Mon, 16 Nov 2020 at 22:53, Masahiko Sawada wrote:
> On Tue, Nov 17, 2020 at 5:52 AM Simon Riggs wrote:
> I don't think the doc is wrong. If DISABLE_PAGE_SKIPPING is specified,
> we not only set aggressive = true but also skip checking visibility
> map. For instance, see line
way from this feature by saying "is
intended to be used only when the contents of the visibility map are
suspect".
Reworded docs patch attached.
--
Simon Riggshttp://www.EnterpriseDB.com/
aggressive_rewording.v1.patch
Description: Binary data
s name are there two copies?"
Agreed to all of the above, but I think the issue is miniscule because
ProcArrayLock is acquired in LW_EXCLUSIVE mode at transaction commit.
So it doesn't seem like there is much need to optimize this particular
aspect of the patch.
--
Simon Riggshttp://www.EnterpriseDB.com/
On Fri, 13 Nov 2020 at 00:50, tsunakawa.ta...@fujitsu.com
wrote:
>
> From: Simon Riggs
> > If a rogue user/process is suspected, this would allow you to identify
> > more easily the changes made by specific sessions/users.
>
> Isn't that kind of auditing a job of p
On Thu, 12 Nov 2020 at 06:42, tsunakawa.ta...@fujitsu.com
wrote:
>
> From: Simon Riggs
> > I would like to propose a few points that will help us detect file
> > damage, inconsistencies in files and track actions of users.
>
> Hello, Simon san. Long time no see. I&#x
that were not in the old index
This approach piggybacks on existing operations. AccessShareLock is
held on both indexes before the old one is dropped.
Other ideas are welcome.
Thoughts?
--
Simon Riggshttp://www.EnterpriseDB.com/
ffers, with the right workload.
We don't have any stats to show whether this patch is worthwhile or
not, so I suggest adding the attached instrumentation patch as well so
we can see on production systems whether checkpoint_timeout is too
high by comparison with pg_stat_bgwriter. The patch is writ
t this is a distinct
> argument to my favorite argument, which is that we cannot afford to
> *not* go a bit slower in certain extreme cases).
>
> I welcome debate about this.
Agreed, we can trade initial speed for long term consistency. I guess
there are some heuristics there on that tradeoff.
--
Simon Riggshttp://www.EnterpriseDB.com/
celebrate your results, but we do need to understand the issue, somehow.
--
Simon Riggshttp://www.EnterpriseDB.com/
ehavior. Since the whole idea of the patch is to change
behavior, that seems a reasonable ask. I don't have any doubt about
the validity of the approach or coding.
What you've done so far is very good and I am very positive about
this, well done.
--
Simon Riggshttp://www.EnterpriseDB.com/
work into a background process rather
than pay the cost in the foreground? Perhaps that might not need us to
hold page locks??
--
Simon Riggshttp://www.EnterpriseDB.com/
multi-row should also only happen once we've loaded a
few rows, so we don't introduce overahads for smaller SQL statements.
--
Simon Riggshttp://www.EnterpriseDB.com/
case
where data fits in shared buffers.
Anyway, if we can discuss what you see as broken, we can fix that and
then extend the usage to other cases, such as INSERT SELECT.
--
Simon Riggshttp://www.EnterpriseDB.com/
On Wed, 21 Oct 2020 at 12:16, Dilip Kumar wrote:
>
> On Tue, Oct 20, 2020 at 5:59 PM Dilip Kumar wrote:
> >
> > On Tue, Oct 20, 2020 at 3:00 PM Simon Riggs wrote:
> > >
> > > On Tue, 20 Oct 2020 at 09:50, Dilip Kumar wrote:
> > >
> > > >
behavior either. Thanks for pointing those issues out.
It would make sense to alter pg_wal_replay_pause() so that it blocks
until paused.
I suggest you add the 3-value state as you suggest, but make
pg_is_wal_replay_paused() respond:
if paused, true
if requested, wait until pause
rom bool to tri-state variable (0-> recovery not paused 1-> pause
> requested 2-> actually paused).
>
> Any opinion on this?
Why would we want this? What problem are you trying to solve?
If we do care, why not fix pg_is_wal_replay_paused() so it responds as you wish?
--
Simon Riggshttp://www.EnterpriseDB.com/
On Fri, 9 Oct 2020 at 04:10, Amit Kapila wrote:
>
> On Thu, Oct 8, 2020 at 2:34 PM Simon Riggs wrote:
> >
> > On Thu, 8 Oct 2020 at 09:47, Dilip Kumar wrote:
> >
> > > > This script will wait 10 seconds after INSERT exits
> > > > before executing
saction that
contains many aborted subtransactions that contain invals.
--
Simon Riggshttp://www.enterprisedb.com/
> I am pleased to report that PostgreSQL 13 is now GA:
>
> https://www.postgresql.org/about/news/2077/
>
> Thank you everyone for your hard work and congratulations on another
> successful release!
Well done team!
--
Simon Riggshttp://www.2ndQuadrant.com
er: 58.93 s,
> system: 0.74 s, elapsed: 62.31 s
>
> (I was getting sick of having to calculate the time spent from the log
> timestamps.)
I really like this patch, thanks for proposing it.
Should pg_rusage_init(&ru0);
be at the start of the REDO loop, since you only
hat sets
all tuples at once, or possibly emit an FPI and then follow that with
a second message that sets all other hints on the page.
--
Simon Riggshttp://www.2ndQuadrant.com/
Mission Critical Databases
default
statistics_target, so that default behavior would be unaffected. Larger
settings would be chunked according to the default, so
stats_target=10k(max) would take a 1/100 = 100 snapshots. That approach
allows people to vary that using an existing parameter if needed.
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
Mission Critical Databases
dn't come from a single snapshot,
but then who cares? There is no requirement for consistency - the sample
would be arguably *more* stable because it comes from multiple points in
time, not just one.
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
Mission Critical Databases
validation of the foreign key
> regardless of if there's a pending table rewrite, but the patch as it
> is now only delays if there's a pending rewrite.
>
Consistency seems the better choice, so I agree we should validate later in
all cases. Does changing that have any other eff
tains the changes for the same.
> Thoughts?
>
Unused? To confirm that, everybody that has a logical decoding plugin needs
to check their code so we are certain this is sensible.
Seems like a change with low utility.
--
Simon Riggshttp://www.2ndQuadrant.com/
<http:/
On Thu, 2 Jul 2020 at 02:58, wrote:
> On Tue, Jun 30, 2020 at 01:58:17PM +0100, Simon Riggs wrote:
> > On Tue, 30 Jun 2020 at 02:17, Madan Kumar
> wrote:
> >> It may be better to have one single function returning both
> >> timestamp and origin for a given tran
ning both
> timestamp and origin for a given transaction ID.
>
No need to change existing APIs.
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
Mission Critical Databases
still better than what
> we have now.
>
> If there are open transactions that have acquired an XID, the sessions are
> killed
> before the barrier is absorbed.
>
> inbuilt graceful failover for PostgreSQL
>
That doesn't appear to be very graceful. Perhaps objections
eldom get those with many-way joins.
So +1 for adding this technique. My question is whether it should be added
as an optional facility of a parameterised sub plan, rather than an
always-needed full-strength node. That way the choice of whether to use it
can happen at execution time once we notice that
On Tue, 12 May 2020 at 21:00, Tom Lane wrote:
> Simon Riggs writes:
> > On Tue, 12 May 2020 at 19:11, Tom Lane wrote:
> >> Anyway, I was just throwing this idea out to see if there would be
> >> howls of "you can't rename anything" anguish. Since th
ist of possible changes.
>
If we add in extensions and lwlocks, will they show up as well?
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
Mission Critical Databases
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
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
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
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
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 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
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 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 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&
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 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
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 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?
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
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
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
301 - 400 of 716 matches
Mail list logo
