reproduce but you
>> can see pretty clearly a few lines above in auth.c that it can be
>> NULL. (I'm surprised Coverity didn't complain about that. Maybe it
>> can't see this code due to macros.)
committed and backpatched
--
Peter Eisentraut http:/
On 11/10/17 10:29, Fabien COELHO wrote:
> Or basically all is fine, I'm just nitpicking for nothing, shame on me.
>
> As I said, I rather like more precise declarations.
committed
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Suppo
st char * case, but
not the char ** -> const char ** case.
--
Peter Eisentraut http://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 you
LWLockTrancheArray = (const char **) // twice
These are not cases of "cheating". This is just the return value of a
memory allocation function being cast from void * to the appropriate
result type. That is an orthogonal style decision that I have
maintained in these cases.
--
ch for the principal point I raised, which is how much work we need to
> do to not further worsen the corruption.
You're right. Just trying to put the risk in context, and to understand the
extent of the concern that you have.
--
Peter Geoghegan
it might be some other HOT chain root following TID
recycling by VACUUM)?
Assuming that's what you meant: I would have thought that the
xmin/xmax matching within heap_get_root_tuples() makes the sanity
checking fairly reliable in practice.
--
Peter Geoghegan
--
Sent via pgsql-hackers m
ng to make sense of what you said.
> It's the second
> vacuum. The reindex part was about $user trying to fix the problem...
> As you need two vacuums with appropriate cutoffs to hit the "rows
> revive" problem, that'll often in practice not happen immediately.
Thi
T chains are sane, which is how the enhanced amcheck notices
the bug here in practice. (Before this bug was discovered, I would
have expected amcheck to catch problems like it slightly later, during
the Bloom filter probe for that HOT chain...but, in fact, it never
gets there with corruption from this bug
d
> contents that way, but we already allow to pass arbitrary stuff to
> heap_page_items(). Since pinning wouldn't be changed, there's no danger
> of the page being moved out from under us.
+1. I've done things like this before myself.
--
Peter Geoghegan
-
/www.postgresql.org/message-id/CAH2-Wz=mv4dmoapficrsyntv2kinxeotbwuy5r7fxxoc-oe...@mail.gmail.com
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 11/8/17 11:11, Merlin Moncure wrote:
> On Wed, Nov 8, 2017 at 9:13 AM, Peter Eisentraut
> wrote:
>> I have already submitted a separate patch that addresses these questions.
>
> Maybe I'm obtuse, but I'm not seeing it? In very interested in the
> general approac
hashsearch.c uses FALSE in some comments.
> - In execExpr.c, ExecCheck mentions TRUE.
That one is an SQL TRUE, so I left it.
> - AggStateIsShared mentions TRUE and FALSE.
> - In arrayfuncs.c, ReadArrayStr, CopyArrayEls and ReadArrayBinary use TRUE.
Fixed the other ones.
--
Peter Eisentra
) was about 20% faster at the time, while
qsort_tuple() was 5% - 10% faster.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
t;.
>> So I just added the end tag. Attached the update patch with the suggested
>> correction.
>
> Ah, I can see the warning as well. Using empty tags is forbidden since
> c29c5789, which is really recent. Sorry for missing it. Simon got
> trapped by that as well visibly.
g.
> Accordingly I propose the attached patch. If anyone's interested in
> experimenting on other platforms, we might be able to refine/complicate
> the FLUSH_DISTANCE selection further, but I think this is probably good
> enough for a first cut.
What is the status of this? Is
language
> function if you needed to. SQL has no flow control but I'm not too
> concerned about that.
I have already submitted a separate patch that addresses these questions.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote D
motivations for procedures is to do more complex and
expensive things including transaction control. So saving exception
overhead is not really on the priority list there.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & S
d.
I'll look for a place to add some documentation around this.
> Was surprised that pg_dump didn't use DROP ROUTINE, when appropriate.
It's not clear to me why that would be preferred.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7
ly. That syntax is currently not available, but it should
not be hard to add.
I don't understand the point about wanting to return an int. How would
you pass that around, since there is no declared return type?
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Dev
eating nonsensical reverse compilations
like CREATE FUNCTION RETURNS PROCEDURE. Catalog queries using
prorettype == 0 would behave sensibly by default. For example, an inner
or outer join against pg_type would automatically make sense.
--
Peter Eisentraut http://www.2ndQuadrant.com
On Tue, Nov 7, 2017 at 3:29 PM, Nico Williams wrote:
> On Thu, Nov 02, 2017 at 03:25:48PM -0700, Peter Geoghegan wrote:
>> Nico Williams wrote:
>> >A MERGE mapped to a DML like this:
>
> I needed to spend more time reading MERGE docs from other RDBMSes.
Please don&#x
(though less
so in terms of raw TPS).
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Tue, Nov 7, 2017 at 2:36 PM, Tom Lane wrote:
> Peter Geoghegan writes:
>> My point is only that it's worth considering that this factor affects
>> how representative your sympathetic case is. It's not clear how many
>> PageIndexMultiDelete() calls
ortant that subset of calls is, and so
on. Maybe it doesn't matter at all.
[1]
https://postgr.es/m/cah2-wzmyry7mnjf0gw5wtk3cszh3gqfhhoxvsyuno5pk8cu...@mail.gmail.com
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscrip
if (accessor->write_chunk != NULL)
> + pfree(accessor->write_chunk);
> + accessor->write_chunk = (SharedTuplestoreChunk *)
> + palloc0(accessor->write_pages * BLCKSZ);
>
> Are we guaranteed t
27;s a bit
like locking every row that the predicate touches, but of course that
isn't at all practical.
I should stop trying to make a watertight case against this, even though
I still think that's possible. For now, instead, I'll just say that this
is *extremely* complicated, and
ach1 is what other systems implement. I think that it would
be important to point out that MERGE with Approach1 isn't special, but
ON CONFLICT DO UPDATE is special. We'd also say that higher isolation
levels will not have duplicate violations.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
rg/wiki/Key_normalization#Making_all_items_in_the_index_unique_by_treating_heap_TID_as_an_implicit_last_attribute
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
what I like to call "banana skin
effects":
https://postgr.es/m/cah2-wzku2xk2dpz7n8-a1mvuuttuvhqkfna+eutwnwctgyc...@mail.gmail.com
This may have nothing at all to do with your results; I'm just pointing
it out as a possibility.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing
On 10/29/17 08:50, Michael Paquier wrote:
> On Thu, Oct 26, 2017 at 9:25 AM, Peter Eisentraut
> wrote:
>> Here is an updated patch set. This is just a rebase of the previous
>> set, no substantial changes. Based on the discussion so far, I'm
>> proposing that 0001 t
variable, and some of them
> would end up having to cast away the const on their end.
OK, here is an updated patch with the controversial bits removed.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote
ains))
xmax_new_tuple = InvalidTransactionId;
else
xmax_new_tuple = HeapTupleHeaderGetRawXmax(oldtup.t_data);
My naive guess is that we have to create a new MultiXactId here in at
least some cases, just like FreezeMultiXactId() sometimes does.
--
Peter Geoghegan
--
Sent via pgsql-hackers
7;m missing something here?
Can you be more specific about what you mean here? I think that I
understand where you're going with this, but I'm not sure.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
l those results, so you'd need a
way to designate which ones, e.g.,
AS $$
SELECT set_config('something', 'value');
SELECT * FROM interesting_table; -- return only this one
SELECT set_config('something', 'oldvalue');
$$;
--
Peter Eisentraut
out statements, only about a command string that might
contain multiple commands. So I don't think anything would break.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mail
;s just that psql doesn't
print the non-last result sets.
We don't have any way to measure from psql how long each individual
result set took to compose. For that you will need deeper tools like
EXPLAIN ANALYZE and some way to process that data. That is way beyond
what \timing cu
On 11/2/17 19:52, Stephen Frost wrote:
> Uh, libpq doesn't actually have symbol versioning, at least not on the
> installed Ubuntu packages for PG10, as shown by objdump -T :
You're right, I was dreaming. But in any case, he would need symbol
versioning of libssl.
--
eSQL
> support downgrades?
no
--
Peter Eisentraut http://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
cases where you have to
> cast away the const somewhere else. I realize that strtol has an ancient
> pedigree, but I do not think it's very good design.
Would you prefer leaving the input argument as char *, or change the
endptr argument to const as well?
--
Peter Eisentraut
we can define it any way we want.
Agreed -- we can. It isn't controversial at all to say that the SQL
standard has nothing to say on this question. The problem is that the
semantics you argue for are ill-defined, and seem to create more
problems than they solve. Why keep bringing up the SQL
e good if we could get it
> fixed in 10.1.
done
--
Peter Eisentraut http://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:
hy it's not done that way is that this would not catch
errors of the command before the pipe.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresq
to BufFile's
double buffering and segmentation schemes just to get shared file
clean-up, if for some reason you want direct file handles.
Is that something that you really think is possible?
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make cha
example doesn't actually have a source (just a target), so it
isn't actually like MERGE.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
or less free of
controversy.
Yes, that certainly will make an easier patch for MERGE.
Indeed, it will.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
e any way to avoid this deadlock?
I don't see a way to avoid it in general, unless we come up with a novel
way of creating replication slots.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via
s cooperation from various different parties, and the details
will likely be platform dependent. But it's generally a solved problem.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers m
a pretty complete patch.
--
Peter Eisentraut http://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/ma
I propose for MERGE will probably cause confusion;
just look into Oracle's MERGE implementation for examples of this. We
ought to go out of our way to make it clear that MERGE doesn't provide
these guarantees.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@p
icularly
technically challenging IMV.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
#x27;t seem
that compelling. I mention it now because It's worth acknowledging that
ON CONFLICT could be pushed a bit further in this direction. Of course,
this still falls far short of making ON CONFLICT entirely like MERGE.
[1] https://commitfest.postgresql.org/15/1241/
--
Peter Geoghegan
?
> starting server anyway
> pg_ctl: could not read file "/tmp/pgsql/postmaster.opts"
>
> The attached patch changes the message to "trying to start server
> anyway" to highlight it is an attempt, not something that will happen.
committed
--
Peter Eisentraut
update the same.
I think those debug messages refer to the SQL name of the function, so
they look correct to me as is.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mai
On 9/15/17 00:20, Michael Paquier wrote:
> On Fri, Sep 15, 2017 at 12:02 PM, Michael Paquier
> wrote:
>> On Fri, Sep 15, 2017 at 11:46 AM, Peter Eisentraut wrote:
>>> passwordcheck: Add test suite
>>>
>>> Also improve one error message.
>>>
>&g
ases differently. It was buggy
even on its own terms. The FrozenTransactionId test used an xmin from
HeapTupleHeaderGetXmin(), not HeapTupleHeaderGetRawXmin().
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
whether or not it is safe to
interrogate clog for a given heap tuple using a tool like amcheck.
And, it wasn't obvious that you couldn't have a codepath that failed
to account for pre-cutoff non-frozen tuples -- codepaths that call
TransactionIdDidCommit() despite it actually being unsaf
resource usage, it would probably be bad if a
wal_keep_segments setting papered over problems with replication slots
for example.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mail
g
patched around a bit recently. I have rewritten it a bit to make it
clearer.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make ch
ften use
>
> coalesce(current_setting(setting_name, true), default_value_here)
>
> as an implementation of current_setting() with a default value.
That appears to address this use case then. Do we need the new proposed
variant still?
--
Peter Eisentraut ht
On 10/3/17 12:31, Dang Minh Huong wrote:
> Sorry but please change "Huong Dangminh"(my name) to "Dang Minh Huong".
done
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via
r in commit messages during
beta, which also makes some sense. So making the contributor list
fairly late and then not changing it much is more efficient.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent vi
Could someone clarify the status of this patch set? It has been in
"Waiting" mode since the previous CF and no new patch, just a few
questions from the author.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training
commit fest, so I'm closing the commit fest entry for now.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make change
On 11/1/17 10:29, Michael Paquier wrote:
> On Wed, Nov 1, 2017 at 2:24 PM, Peter Eisentraut
> wrote:
>> Committed to master. I suppose this should be backpatched?
>
> Thanks! Yes this should be back-patched.
OK, done for 10, 9.6, and 9.5.
The tablespace mapping feature star
explanation and warnings. But it's not
clear whether it's worth it given the existing alternatives.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (
t the right set of primitives might be to
address them.
--
Peter Eisentraut http://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
3669 +
+ innerTuples: 20 +
+ innerAllTheSame: 0+
+ leafPlaceholders: 569 +
+ innerPlaceholders: 0+
+ leafRedirects: 0+
+ innerRedirects:0+
+
This function should return a row with columns for each of these pieces
of informatio
;s
what you need in order to get the desired guarantees in READ COMMITTED
mode [2]. This is the main reason why it was as painful a project as it
was. Further generalizing that seems fraught with difficulties. It seems
logically impossible to generalize it in a way where you don't end up
w
uot; at the beginning.
Committed incorporating that suggestion.
--
Peter Eisentraut http://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
I suppose this should be backpatched?
(I changed the strcpy() to strlcpy() for better karma.)
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.
to take up with Andres,
if you haven't already. I have a hard time imagining a single query
needed to use more than that many tablespaces at once, so maybe this
is fine.
> I don't really believe anyone uses
> temp_tablespaces for IO load balancing anymore and I hate code like
>
r
tape. It hardly matters -- perhaps you should leave it there in order
to keep the code simple, as you'll be keeping the leader tape in local
memory, too. (But it still won't fly to continue to clobber it, of
course -- you still need to find a dedicated place for BufFileSet in
share
int result
but that would have a lot more overhead, potentially.
Thoughts?
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From 2e5d50cb39b926b29a6081f2387b95621357a4a0 Mon Sep 17 00:00:00 2001
From: Peter Eisen
cution context. I don't know if we have such a
thing yet or something that we could easily latch on to.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From 1b3318154540d0fe71480ca58938433ecfccabbd Mon Sep
he merit of actually
being how MERGE works in every other system. Both Robert and Stephen
seem to be almost sold on what I suggest, so I think that I've
probably already explained my position quite well.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
rhaps someone more familiar with postgres_fdw details can
check it.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From 097ecf61a9c2740b02a21be19a92aed92388346a Mon Sep 17 00:00:00 2001
From: Peter Eisentraut
dling with this in the back branches. Maybe only the places where
the errors are not caught at all should be fixed there. Comments welcome.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training &
. In those cases, I added a cast or two.
Generally, I find these const decorations useful as easy function
documentation.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From a8163e84c83887e4a3b81642c13799593270
tively engaging with me
at this point. We're going around in circles.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ation easier in the short term. ISTM that you're making this
difficult for yourself for reasons that are known only to you.
>> And, indeed, it seems that you're proposing an implementation that
>> adds no new functionality, just syntax compatibility. Do we really
>> w
CONFLICT without even
saying why. I can only surmise that you think that doing so will
simplify the implementation, but I can guarantee you that it won't.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
op of the ON CONFLICT guarantees, and ultimately
arriving at something that is comparable to other implementations over
many releases might be okay if anyone had the slightest idea of what
that would look like. You haven't even _described the semantics_,
which you could do by addressing the speci
ed having inserted such a row, that still counts as a CONFLICT
with READ COMMITTED.
[1] https://wiki.postgresql.org/wiki/UPSERT#Goals_for_implementation
[2]
https://www.postgresql.org/docs/devel/static/transaction-iso.html#xact-read-committed
--
Peter Geoghegan
--
Sent via pgsql-hackers
compliant. Thank you to Peter for
> providing the infrastructure on which this is now possible for PG11.
>
> Serge puts this very nicely by identifying two different use cases for MERGE.
MERGE benefits from having a join that is more or less implemented in
the same way as any other jo
ssing, saying something about unique violations, and that unique
violations *cannot* be suppressed in MERGE, even though that's
possible with other DML statements (with something called
IGNORE_DUP_KEY).
What other systems *do* have this restriction? I've never seen one that did.
-
On Fri, Oct 27, 2017 at 6:24 AM, Robert Haas wrote:
> 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 felt free to mandate a non-standard SQL requirement, namely
> the presence of a
https://www.postgresql.org/message-id/CAM3SWZRP0c3g6+aJ=yydgyactzg0xa8-1_fcvo5xm7hrel3...@mail.gmail.com
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 10/26/17 16:10, Tom Lane wrote:
> Peter Eisentraut writes:
>> On 10/16/17 03:19, Thomas Kellerer wrote:
>>> I don't know if this is intentional, but the Postgres 10 manual started to
>>> use lowercase IDs as anchors in the manual.
>
>> Here is a patc
On 10/27/17 04:06, Pavel Stehule wrote:
> Why buildin process has prefix bgworker?
Implementation detail. This has been changed in master already.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
S
can be applied to PG 10 to put the upper case
anchors back.
The question perhaps is whether we want to maintain this patch
indefinitely, or whether a clean break is better.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training &
ord to corrupt
again, though!)
> Maybe this is relevant ?
> ts=# SELECT * FROM heap_page_items(get_raw_page('sites', 3)) WHERE lp=27;
> lp | lp_off | lp_flags | lp_len | t_xmin | t_xmax | t_field3 | t_ctid |
> t_infomask2 | t_infomask | t_hoff | t_bits | t_oid | t_data
> +----+
hat they could cause corruption like this if you
weren't careful. (In general, I wouldn't recommend using LVM snapshots
as any kind of backup solution.)
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
the version in Postgres 10, this enhanced version (V1.2) has
"heapallindexed" verification, which is really what you want here. If
you install it, and run it against the unique index in question (with
"heapallindexed" verification), that could help. It might provide a
mo
t this low level requirement into
context if you want sound advice from this list.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Sun, Oct 22, 2017 at 12:23 PM, Eric Ridge wrote:
> Can anyone confirm or deny that this is correct? I feel like it is correct,
> but I'm no expert.
What are you going to use the code for? I think that that context is
likely to matter here.
--
Peter Geoghegan
--
Sent via pg
On Thu, Oct 5, 2017 at 7:00 PM, Peter Geoghegan wrote:
> v3 of the patch series, attached, does it that way -- it adds a
> bloom_create(). The new bloom_create() function still allocates its
> own memory, but does so while using a FLEXIBLE_ARRAY_MEMBER. A
> separate bloom_init() fu
On Thu, Oct 19, 2017 at 9:03 AM, Peter Geoghegan wrote:
>> /me studies the problem for a while.
>>
>> What's bothering me about this is: how is cutoff_xid managing to be a
>> new enough transaction ID for this to happen in the first place? The
>> cutoff
ht was an entire HOT
chain).
Now that the problem is fixed by a5736bf7, this test case will prune
and get an LP_REDIRECT ItemId (not an LP_DEAD one), as we're no longer
confused about the continuity of HOT chains within heap_prune_chain().
--
Peter Geoghegan
--
Sent via pgsql-hackers ma
xmax freezing needs to happen to heap-only
tuples, as well as HOT root tuples and non-HOT tuples. But, as I said,
I'm still playing catch-up on MultiXacts, and I too feel like I might
still be missing important details.
[1] https://postgr.es/m/20171017100200.ruszi2c6qqwetce5@al
le holding a super-exclusive lock on the buffer. I can
probably find a way to ensure this only needs to happen in a rare slow
path, when it looks like the invariant might be violated but we need
to make sure (I'm already following this pattern in a couple of
places). Realistically, ther
1 - 100 of 12769 matches
Mail list logo
