On Thu, Apr 29, 2021 at 4:36 PM Bharath Rupireddy
wrote:
>
> On Thu, Apr 29, 2021 at 4:27 PM Dave Cramer wrote:
> > For testing unusual situations I'd like to be able to cause a backend to
> > terminate due to something like a segfault. Do we currently have this in
> > testing ?
>
> Well, you
On Sat, May 1, 2021 at 10:43 AM Bharath Rupireddy
wrote:
>
> On Fri, Apr 30, 2021 at 2:49 PM Dilip Kumar wrote:
> > Looking into this again, why not as shown below? IMHO, this way the
> > code will be logically the same as it was before the patch, basically
> > why to process an extra statement
On Fri, Apr 30, 2021 at 2:49 PM Dilip Kumar wrote:
> Looking into this again, why not as shown below? IMHO, this way the
> code will be logically the same as it was before the patch, basically
> why to process an extra statement ( *volatility_item = defel;) if we
> have already decided to error.
On Sat, May 1, 2021 at 5:26 AM Bingyu Shen wrote:
> Hi hackers,
>
> I was wondering if we can improve the error messages for acl permission
> failures.
> Current implementation to report errors is in "backend/catalog/aclchk.c"
> void aclcheck_error(AclResult aclerr, ObjectType objtype,
On Sat, May 01, 2021 at 04:43:21PM +1200, Thomas Munro wrote:
> TRAP: FailedAssertion("!all_visible_according_to_vm ||
> prunestate.all_visible", File:
> "/home/pgsql/build-farm/buildroot/HEAD/pgsql.build/../pgsql/src/backend/access/heap/vacuumlazy.c",
> Line: 1347, PID: 16926)
> 2021-04-30
On Sat, May 1, 2021 at 10:14 AM Thomas Munro wrote:
>
> Hi,
>
> TRAP: FailedAssertion("!all_visible_according_to_vm ||
> prunestate.all_visible", File:
> "/home/pgsql/build-farm/buildroot/HEAD/pgsql.build/../pgsql/src/backend/access/heap/vacuumlazy.c",
> Line: 1347, PID: 16926)
>
> 2021-04-30
Hi,
TRAP: FailedAssertion("!all_visible_according_to_vm ||
prunestate.all_visible", File:
"/home/pgsql/build-farm/buildroot/HEAD/pgsql.build/../pgsql/src/backend/access/heap/vacuumlazy.c",
Line: 1347, PID: 16926)
2021-04-30 04:15:50.317 PDT [10349:18] DETAIL: Failed process was
running:
On Wed, Mar 17, 2021 at 6:03 PM Zhihong Yu wrote:
>
> Hi,
> For v35-0007-Prepare-foreign-transactions-at-commit-time.patch :
Thank you for reviewing the patch!
>
> With this commit, the foreign server modified within the transaction marked
> as 'modified'.
>
> transaction marked -> transaction
On Fri, 30 Apr 2021 at 22:00, Mark Dilger
wrote:
> Viewing all of this in terms of which controls allow the tenant to escape
> a hypothetical sandbox seems like the wrong approach. Shouldn't we let
> service providers decide which controls would allow the tenant to escape
> the specific
> On Apr 30, 2021, at 4:28 PM, Stephen Frost wrote:
>
> “Can’t be used to gain superuser” may be a sufficiently clear grouping, as
> was more or less contemplated by the “admin” approach. If that doesn’t work
> though then we need an understanding of what the limits on these groups are,
>
On Tue, Apr 27, 2021 at 10:03 AM Masahiro Ikeda
wrote:
>
>
>
> On 2021/03/17 12:03, Masahiko Sawada wrote:
> > I've attached the updated version patch set.
>
> Thanks for updating the patches! I'm now restarting to review of 2PC because
> I'd like to use this feature in PG15.
Thank you for
On Thu, Apr 22, 2021 at 3:35 PM Tom Lane wrote:
> Peter Geoghegan writes:
> > We already *almost* pay the full cost of durably storing the
> > information used by autovacuum.c's relation_needs_vacanalyze() to
> > determine if a VACUUM is required -- we're only missing
> >
Stephen Frost writes:
> On Fri, Apr 30, 2021 at 19:19 Mark Dilger
> wrote:
>> PostgreSQL defines a number of GUCs that can only be set by superusers. I
>> would like to support granting privileges on subsets of these to
>> non-superuser roles, inspired by Stephen Frost's recent work on
>>
On 04/30/21 19:19, Mark Dilger wrote:
> We could certainly debate which GUCs could be used to escape the sandbox
> vs. which ones could not, but I would prefer a design that allows the
> provider to make that determination.
I find myself wondering how many GUCs flagged SUSET are not flagged that
Hi hackers,
I was wondering if we can improve the error messages for acl permission
failures.
Current implementation to report errors is in "backend/catalog/aclchk.c"
void aclcheck_error(AclResult aclerr, ObjectType objtype, const char
*objectname);
based on the AclResult type, it print log
Greetings,
On Fri, Apr 30, 2021 at 19:19 Mark Dilger
wrote:
> PostgreSQL defines a number of GUCs that can only be set by superusers. I
> would like to support granting privileges on subsets of these to
> non-superuser roles, inspired by Stephen Frost's recent work on
> pg_read_all_data and
Hackers,
PostgreSQL defines a number of GUCs that can only be set by superusers. I
would like to support granting privileges on subsets of these to non-superuser
roles, inspired by Stephen Frost's recent work on pg_read_all_data and
pg_write_all_data roles.
The specific use case motivating
On Fri, Apr 30, 2021 at 2:07 PM Robert Haas wrote:
> OK. I thought about this in regards to zheap, which has this exact
> problem, because it wants to do so-called "in place" updates where the
> new version of the row goes right on top of the old one in the table
> page, and the old version of
On Fri, Apr 30, 2021 at 2:13 PM Jeff Davis wrote:
> FWIW, this is not a problem in my table AM. I am fine having different
> TIDs for each version, just like heapam.
This means that we are largely in agreement about the general nature
of the problem. That seems like a good basis to redefine
On Fri, 2021-04-30 at 12:29 -0700, Peter Geoghegan wrote:
> > Is the problem you're worried about here that, with something like
> > an
> > index-organized table, you can have multiple row versions that have
> > the same logical tuple ID, i.e. primary key value?
>
> That's what I'm talking
On Fri, Apr 30, 2021 at 4:26 PM Mark Dilger
wrote:
> After further reflection, no other verbiage seems any better. I'd say go
> ahead and commit it this way.
OK. I'll plan to do that on Monday, barring objections.
--
Robert Haas
EDB: http://www.enterprisedb.com
On Fri, Apr 30, 2021 at 3:30 PM Peter Geoghegan wrote:
> > Is the problem you're worried about here that, with something like an
> > index-organized table, you can have multiple row versions that have
> > the same logical tuple ID, i.e. primary key value? And that the
> > interfaces aren't
> On Apr 30, 2021, at 1:04 PM, Mark Dilger wrote:
>
>> toast value %u was expected to end at chunk %d, but ended while
>> expecting chunk %d
>>
>> i.e. same as the currently-committed code, except for changing "ended
>> at" to "ended while expecting."
>
> I find the grammar of this new
> On Apr 30, 2021, at 12:47 PM, Robert Haas wrote:
>
> Hmm, I think that might need adjustment, actually. What I was trying
> to do is compensate for the fact that what we now have is the next
> chunk_seq value we expect, not the last one we saw, nor the total
> number of chunks we've seen
On Fri, Apr 30, 2021 at 3:41 PM Mark Dilger
wrote:
> I think that's committable.
>
> The only nitpick might be
>
> - psprintf("toast value %u was expected to end
> at chunk %d, but ended at chunk %d",
> + psprintf("toast value %u index
> On Apr 30, 2021, at 12:29 PM, Robert Haas wrote:
>
> OK, how about this version?
I think that's committable.
The only nitpick might be
- psprintf("toast value %u was expected to end at
chunk %d, but ended at chunk %d",
+
On Fri, Apr 30, 2021 at 12:20 PM Robert Haas wrote:
> Why can't it do what it does already? It's not broken for heap, so why
> should it be broken for anything else? And why are non-HOT updates
> specifically a problem?
No reason.
> > You obviously cannot have the equivalent of
> > duplicate
On Fri, Apr 30, 2021 at 3:26 PM Mark Dilger
wrote:
> It looks mostly good to me. There is a off-by-one error introduced with:
>
> - else if (chunkno != (endchunk + 1))
> + else if (expected_chunk_seq < last_chunk_seq)
>
> I think that needs to be
>
> + else if (expected_chunk_seq <=
> On Apr 30, 2021, at 11:56 AM, Robert Haas wrote:
>
> Can you review this version?
It looks mostly good to me. There is a off-by-one error introduced with:
- else if (chunkno != (endchunk + 1))
+ else if (expected_chunk_seq < last_chunk_seq)
I think that needs to be
+ else if
> On Apr 30, 2021, at 11:56 AM, Robert Haas wrote:
>
> On Fri, Apr 30, 2021 at 2:31 PM Mark Dilger
> wrote:
>> Just to be clear, I did not use your patch v1 as the starting point.
>
> I thought that might be the case, but I was trying to understand what
> you didn't like about my version,
On Fri, Apr 30, 2021 at 2:23 PM Peter Geoghegan wrote:
> I don't know how it's possible to do any of this without first
> addressing what the table AM does in cases where heapam currently does
> a non-HOT update.
Why can't it do what it does already? It's not broken for heap, so why
should it be
On Fri, Apr 30, 2021 at 2:31 PM Mark Dilger
wrote:
> Just to be clear, I did not use your patch v1 as the starting point.
I thought that might be the case, but I was trying to understand what
you didn't like about my version, and comparing them seemed like a way
to figure that out.
> I took the
On Fri, Apr 30, 2021 at 11:23 AM Robert Haas wrote:
> On Fri, Apr 30, 2021 at 2:05 PM Peter Geoghegan wrote:
> > I agree in principle, but making that work well is very hard in
> > practice because of the format of IndexTuple -- which bleeds into
> > everything. That TID is special is probably a
On Fri, 2021-04-30 at 13:56 -0400, Robert Haas wrote:
> I think that would be the best long-term plan.
We should still have *some* answer in the short term for table AM
authors like me. If I use offset numbers as high as MaxOffsetNumber,
then itemptr_to_uint64 will fail. If I base my calculations
On Sat, Mar 06, 2021 at 03:01:43PM -0500, Tom Lane wrote:
> Peter Eisentraut writes:
> > On 2021-01-12 22:44, Andrew Dunstan wrote:
> >> Cross version pg_upgrade is tested regularly in the buildfarm, but not
> >> using test.sh. Instead it uses the saved data repository from a previous
> >> run of
> On Apr 30, 2021, at 9:39 AM, Robert Haas wrote:
>
> On Mon, Apr 26, 2021 at 1:52 PM Mark Dilger
> wrote:
>> The attached patch changes amcheck corruption reports as discussed upthread.
>> This patch is submitted for the v14 development cycle as a bug fix, per
>> your complaint that the
On Fri, 2021-04-30 at 10:50 -0700, Peter Geoghegan wrote:
> I don't know. This conversation is still too abstract for me to be
> able to take a firm position. ISTM that we tend to talk about the
> table AM in excessively abstract terms. It would be a lot easier if
> we
> had clear fixed goals for
On Fri, Apr 30, 2021 at 2:05 PM Peter Geoghegan wrote:
> I agree in principle, but making that work well is very hard in
> practice because of the format of IndexTuple -- which bleeds into
> everything. That TID is special is probably a natural consequence of
> the fact that we don't have an
On Fri, Apr 30, 2021 at 10:56 AM Robert Haas wrote:
> I think that would be the best long-term plan. I guess I have two
> distinguishable concerns. One is that I want to be able to have
> indexes with a payload that's not just a 6-byte TID; e.g. adding a
> partition identifier to support global
On Fri, Apr 30, 2021 at 10:39 AM Robert Haas wrote:
> I agree up to a point but ... are you imagining that the TID continues
> to have its own special place in the page, while the partition
> identifier is stored more like a regular tuple column? Because it
> seems to me that it would be better
On Fri, Apr 30, 2021 at 12:57 PM Tom Lane wrote:
> By my count, we have three votes for forbidding procedure calls via
> fastpath in all branches (me, Joe, Michael), and two for doing
> something laxer (Noah, Laurenz). The former is surely the safer
> choice, so I'm going to go do that.
FWIW,
On Fri, Apr 30, 2021 at 1:37 PM Jeff Davis wrote:
> The particular problem I have now is that Table AMs seem to support
> indexes just fine, but TIDs are under-specified so I don't know what I
> really have to work with. BlockNumber seems well-specified as
> 0..0XFFFE (inclusive), but I don't
On Fri, 2021-04-30 at 12:35 -0400, Tom Lane wrote:
> ISTM that would be up to the index AM. We'd need some interlocks on
> which index AMs could be used with which table AMs in any case, I
> think.
I'm not sure why? It seems like we should be able to come up with
something that's generic enough.
On Fri, Apr 30, 2021 at 10:04 AM Jeff Davis wrote:
> On Fri, 2021-04-30 at 08:36 -0700, Peter Geoghegan wrote:
> > Compatibility with index AMs is more than a matter of switching out
> > the tuple identifier -- if you invent something that has totally
> > different performance characteristics for
On Fri, Apr 30, 2021 at 1:28 PM Peter Geoghegan wrote:
> Global indexes should work by adding an extra column that is somewhat
> like a TID, that may even have its own pg_attribute entry. It's much
> more natural to make the partition number a separate column IMV --
> nbtree suffix truncation and
On Fri, 2021-04-30 at 12:51 -0400, Robert Haas wrote:
> There are two major reasons why I want variable-width tuple IDs. One
> is global indexes, where you need as many bits as the AMs
> implementing
> the partitions need, plus some extra bits to identify which partition
> is relevant for a
Hi David,
You're probably aware of this, but just to make it explicit: Jakub
Wartak was testing performance of recovery, and one of the bottlenecks
he found in some of his cases was dynahash as used by SMgr. It seems
quite possible that this work would benefit some of his test workloads.
He last
On Fri, Apr 30, 2021 at 1:10 PM Tom Lane wrote:
> I agree that global indexes need more bits, but it doesn't necessarily
> follow that we must have variable-width TIDs. We could for example
> say that "real" TIDs are only 48 bits and index AMs that want to be
> usable as global indexes must be
On Fri, Apr 30, 2021 at 10:10 AM Tom Lane wrote:
> > There are two major reasons why I want variable-width tuple IDs. One
> > is global indexes, where you need as many bits as the AMs implementing
> > the partitions need, plus some extra bits to identify which partition
> > is relevant for a
Robert Haas writes:
> On Fri, Apr 30, 2021 at 11:06 AM Tom Lane wrote:
>> Andres seems to feel that we should try to allow variable-width
>> tupleids, but I'm afraid that the cost/benefit ratio for that
>> would be pretty poor.
> There are two major reasons why I want variable-width tuple IDs.
On Fri, 2021-04-30 at 08:36 -0700, Peter Geoghegan wrote:
> Compatibility with index AMs is more than a matter of switching out
> the tuple identifier -- if you invent something that has totally
> different performance characteristics for index AMs, then it's likely
> to break tacit assumptions
Michael Paquier writes:
> On Tue, Mar 09, 2021 at 02:33:47PM -0500, Joe Conway wrote:
>> My vote would be reject using fastpath for procedures in all relevant
>> branches.
>> If someday someone cares enough to make it work, it is a new feature for a
>> new
>> major release.
> FWIW, my vote
On Fri, Apr 30, 2021 at 11:06 AM Tom Lane wrote:
> My thought at the moment is that all APIs above the AM level ought
> to be redefined to use uint64 for tuple identifiers. heapam and
> related index AMs could map block + offset into that in some
> convenient way, and other AMs could do what
On Fri, 2021-04-30 at 12:04 +0200, Matthias van de Meent wrote:
> Other than that, I believe you've also missed the special offset
> numbers specified in itemptr.h (SpecTokenOffsetNumber and
> MovedPartitionsOffsetNumber). I am not well enough aware of the usage
> of these OffsetNumber values, but
On Mon, Apr 26, 2021 at 1:52 PM Mark Dilger
wrote:
> The attached patch changes amcheck corruption reports as discussed upthread.
> This patch is submitted for the v14 development cycle as a bug fix, per your
> complaint that the committed code generates reports sufficiently confusing to
> a
Jeff Davis writes:
> On Fri, 2021-04-30 at 11:06 -0400, Tom Lane wrote:
>> My thought at the moment is that all APIs above the AM level ought
>> to be redefined to use uint64 for tuple identifiers.
> Do you mean that indexes would be expected to hold a uint64, a 48-bit
> int (that directly maps
On Fri, 2021-04-30 at 11:06 -0400, Tom Lane wrote:
> My thought at the moment is that all APIs above the AM level ought
> to be redefined to use uint64 for tuple identifiers.
One challenge might be reliance on InvalidOffsetNumber as a special
value in a number of places (e.g. bitmap index scans).
Hi,
On 2021-04-29 13:28:20 -0400, Álvaro Herrera wrote:
> On 2021-Apr-07, Andres Freund wrote:
>
> > I'm also confused by the use of ConditionVariableTimedSleep(timeout =
> > 10). Why do we need a timed sleep here in the first place? And why with
> > such a short sleep?
>
> I was scared of the
Hi,
On 2021-04-08 17:03:41 +0530, Amit Kapila wrote:
> I haven't tested the patch but I couldn't spot any problems while
> reading it. A minor point, don't we need to use
> ConditionVariableCancelSleep() at some point after doing
> ConditionVariableTimedSleep?
It's not really necessary - unless
On Fri, Apr 30, 2021 at 8:06 AM Tom Lane wrote:
> My thought at the moment is that all APIs above the AM level ought
> to be redefined to use uint64 for tuple identifiers. heapam and
> related index AMs could map block + offset into that in some
> convenient way, and other AMs could do what they
We've figured it out. Please ignore.
Regards.
On Fri, Apr 30, 2021 at 3:13 PM Patrik Novotny wrote:
> Hi,
>
> I need to reproduce the CVE-2020-25695 on PostgreSQL 9.2.24. I know this
> is not a supported version, however, it is important for us to have a
> reproducer for this version as well.
Jeff Davis writes:
> The notion of TID is based on pages and line pointers, which makes
> sense for heapam, but that's not likely to make sense for a custom
> table AM.
> The obvious answer is to make a simple mapping between a TID and
> whatever makes sense to the AM (for the sake of discussion,
On Wed, Apr 28, 2021 at 07:51:43AM +0200, Peter Eisentraut wrote:
> I propose the attached patch to shake up the wording in the connection type
> section of pg_hba.conf.sample a bit. After the hostgssenc part was added
> on, the whole thing became a bit wordy, and it's also a bit inaccurate for
>
On Fri, Apr 30, 2021 at 3:01 PM Amit Kapila wrote:
>
> On Wed, Apr 28, 2021 at 11:03 AM Dilip Kumar wrote:
> >
> > On Wed, Apr 28, 2021 at 11:00 AM Amit Kapila
> > wrote:
> > >
> >
> > The idea I have is to additionally check that we are decoding
> > > streaming or prepared transaction (the
(Thanks for committing the fix.)
On Thu, Apr 29, 2021 at 1:11 AM Álvaro Herrera wrote:
> On Wed, Apr 28, 2021, at 10:21 AM, Amit Langote wrote:
> I noticed that rd_partdesc_nodetached_xmin can sometimes end up with
> value 0. While you seem to be already aware of that, because otherwise
> you
Hi,
I need to reproduce the CVE-2020-25695 on PostgreSQL 9.2.24. I know this is
not a supported version, however, it is important for us to have a
reproducer for this version as well.
The reproducer for supported versions[1] is based on REFRESH MATERIALIZED
VIEW which is not implemented until
On Fri, 30 Apr 2021, 09:46 Jeff Davis, wrote:
>
> The notion of TID is based on pages and line pointers, which makes
> sense for heapam, but that's not likely to make sense for a custom
> table AM.
>
> The obvious answer is to make a simple mapping between a TID and
> whatever makes sense to the
On Wed, Apr 28, 2021 at 11:03 AM Dilip Kumar wrote:
>
> On Wed, Apr 28, 2021 at 11:00 AM Amit Kapila wrote:
> >
>
> The idea I have is to additionally check that we are decoding
> > streaming or prepared transaction (the same check as we have for
> > setting curtxn) or we can check if
On Fri, Apr 30, 2021 at 12:36 PM Bharath Rupireddy
wrote:
> >
> > other comments
> >
> > if (strcmp(defel->defname, "volatility") == 0)
> > {
> > if (is_procedure)
> > - goto procedure_error;
> > + is_procedure_error = true;
> > if (*volatility_item)
> > - goto duplicate_error;
> > +
On Fri, Apr 30, 2021 at 5:06 PM Bharath Rupireddy
wrote:
>
> On Fri, Apr 30, 2021 at 11:23 AM Dilip Kumar wrote:
> >
> > On Fri, Apr 30, 2021 at 11:09 AM Bharath Rupireddy
> > wrote:
> > >
> > > On Fri, Apr 30, 2021 at 10:51 AM Dilip Kumar
> > > wrote:
> > > >
> > > > On Fri, Apr 30, 2021 at
Hi,
our setup:
Postgres server is running on CentOS release 6.10 (Final) instance.
Server Version is PostgreSQL 9.5.9 on x86_64-pc-linux-gnu, compiled by
gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-18), 64-bit
With the following parameters set:
wal_level = 'logical' # replica < logical
On Fri, Apr 30, 2021 at 5:55 AM Masahiko Sawada wrote:
>
> After more thought, it seems to me that we should use txn->size here
> regardless of the top transaction or subtransaction since we're
> iterating changes associated with a transaction that is either the top
> transaction or a
The notion of TID is based on pages and line pointers, which makes
sense for heapam, but that's not likely to make sense for a custom
table AM.
The obvious answer is to make a simple mapping between a TID and
whatever makes sense to the AM (for the sake of discussion, let's say a
plain row
On Fri, Apr 30, 2021 at 11:23 AM Dilip Kumar wrote:
>
> On Fri, Apr 30, 2021 at 11:09 AM Bharath Rupireddy
> wrote:
> >
> > On Fri, Apr 30, 2021 at 10:51 AM Dilip Kumar wrote:
> > >
> > > On Fri, Apr 30, 2021 at 10:43 AM Bharath Rupireddy
> > > wrote:
> > > >
> > > > On Fri, Apr 30, 2021 at
On Thu, Apr 29, 2021 at 9:45 PM vignesh C wrote:
>
> Hi,
>
> While debugging one of the logical decoding issues, I found that xid was not
> included in restoring reorder buffer changes from disk log messages.
> Attached a patch for it. I felt including the XID will be helpful in
> debugging.
On Fri, Apr 30, 2021 at 5:55 AM Masahiko Sawada wrote:
>
> On Thu, Apr 29, 2021 at 9:44 PM vignesh C wrote:
> >
> >
> >
> > On Thu, Apr 29, 2021 at 3:06 PM Amit Kapila wrote:
> > >
> > > On Wed, Apr 28, 2021 at 5:01 PM Amit Kapila
> > > wrote:
> > > >
> > > > On Wed, Apr 28, 2021 at 4:51 PM
76 matches
Mail list logo
