On 2018-07-20 08:56:32 +0900, Michael Paquier wrote:
> On Thu, Jul 19, 2018 at 04:50:06PM -0700, Andres Freund wrote:
> > On 2018-07-20 08:46:50 +0900, Michael Paquier wrote:
> >> On Thu, Jul 19, 2018 at 07:18:32PM -0400, Tom Lane wrote:
> >> I have found the argument about circular dependencies ra
On Thu, Jul 19, 2018 at 04:50:06PM -0700, Andres Freund wrote:
> On 2018-07-20 08:46:50 +0900, Michael Paquier wrote:
>> On Thu, Jul 19, 2018 at 07:18:32PM -0400, Tom Lane wrote:
>> I have found the argument about circular dependencies rather sensible
>> FWIW. So at the end it seems to me that we
On 2018-07-20 08:46:50 +0900, Michael Paquier wrote:
> On Thu, Jul 19, 2018 at 07:18:32PM -0400, Tom Lane wrote:
> > Andres Freund writes:
> >> FWIW, I was off the last few days. I personally think the reasoning to
> >> leave out pg_class, pg_index etc. is bad. We should just make them work
> >>
On Thu, Jul 19, 2018 at 07:18:32PM -0400, Tom Lane wrote:
> Andres Freund writes:
>> FWIW, I was off the last few days. I personally think the reasoning to
>> leave out pg_class, pg_index etc. is bad. We should just make them work
>> and create toast tables as well.
>
> If it's easy to make thos
Andres Freund writes:
> FWIW, I was off the last few days. I personally think the reasoning to
> leave out pg_class, pg_index etc. is bad. We should just make them work
> and create toast tables as well.
If it's easy to make those work and keep them working, then sure, but
I have my doubts. I r
Hi,
On 2018-07-20 07:49:11 +0900, Michael Paquier wrote:
> On Wed, Jul 18, 2018 at 01:02:35PM +0900, Michael Paquier wrote:
> > So, I have been playing with the previous patch and tortured it through
> > a couple of upgrade scenarios, where it proves to work. Attached is an
> > updated patch whic
On Wed, Jul 18, 2018 at 01:02:35PM +0900, Michael Paquier wrote:
> So, I have been playing with the previous patch and tortured it through
> a couple of upgrade scenarios, where it proves to work. Attached is an
> updated patch which adds toast tables except for pg_class, pg_attribute,
> pg_index
On 7/17/18, Michael Paquier wrote:
> [... digging ...]
> This comes from get_rel_infos where large objects are treated as user
> data. Rather than the comment you added, I would rather do the
> following:
> "Large object catalogs and toast tables are mutually exclusive and large
> object data is
On Tue, Jul 17, 2018 at 06:03:26PM +0900, Michael Paquier wrote:
> On Tue, Jul 17, 2018 at 02:55:07PM +0700, John Naylor wrote:
>> I didn't dig deeper, since TOAST and the large object facility are
>> mutually exclusive so there shouldn't be a toast table here anyway.
>> Hope this helps.
>
> [...
On Tue, Jul 17, 2018 at 02:55:07PM +0700, John Naylor wrote:
> I didn't dig deeper, since TOAST and the large object facility are
> mutually exclusive so there shouldn't be a toast table here anyway.
> Hope this helps.
[... digging ...]
This comes from get_rel_infos where large objects are treated
On 7/17/18, Michael Paquier wrote:
> I was just having a second look at this patch, and did a bit more tests
> with pg_upgrade which passed.
>
> +-- 2. pg_largeobject and pg_largeobject_metadata, to avoid problems
> +-- with pg_upgrade
> John, what's actually the failure that was seen here? It wo
On Sat, Jul 14, 2018 at 03:47:38PM +0700, John Naylor wrote:
> I hope you don't mind, but since it might be tedious to piece together
> the addenda I left behind in this thread, I thought it might be useful
> to update Joe's patch. The attached was rebased over the new
> regression test, passes the
On Sat, Jul 14, 2018 at 03:47:38PM +0700, John Naylor wrote:
> I hope you don't mind, but since it might be tedious to piece together
> the addenda I left behind in this thread, I thought it might be useful
> to update Joe's patch. The attached was rebased over the new
> regression test, passes the
On 7/12/18, Peter Eisentraut wrote:
> To get things rolling, I have committed the regression test addition.
>
> I'll look through the other stuff soon.
Hi Peter,
I hope you don't mind, but since it might be tedious to piece together
the addenda I left behind in this thread, I thought it might be
On 10.07.18 03:29, Michael Paquier wrote:
> On Mon, Jul 09, 2018 at 09:19:35PM -0400, Joe Conway wrote:
>> If you can wait for the next commitfest (the original one I put the
>> patch into, i.e. September) I am committed to making it happen. But if
>> you are anxious to getting this into the curren
On Mon, Jul 09, 2018 at 09:19:35PM -0400, Joe Conway wrote:
> If you can wait for the next commitfest (the original one I put the
> patch into, i.e. September) I am committed to making it happen. But if
> you are anxious to getting this into the current commitfest, go for it.
> I am in the middle o
On 07/09/2018 09:16 PM, Michael Paquier wrote:
> On Mon, Jul 09, 2018 at 02:45:26PM +0200, Peter Eisentraut wrote:
>> On 15.06.18 21:15, Joe Conway wrote:
>>> Not surprising -- thanks for the update.
>>>
It occurred to be that we could go further and create most toast
tables automatically
On Mon, Jul 09, 2018 at 02:45:26PM +0200, Peter Eisentraut wrote:
> On 15.06.18 21:15, Joe Conway wrote:
>> Not surprising -- thanks for the update.
>>
>>> It occurred to be that we could go further and create most toast
>>> tables automatically by taking advantage of the fact that the toast
>>> c
On 15.06.18 21:15, Joe Conway wrote:
> Not surprising -- thanks for the update.
>
>> It occurred to be that we could go further and create most toast
>> tables automatically by taking advantage of the fact that the toast
>> creation function is a no-op if there are no varlena attributes. The
>> se
On 2018-02-18 11:18:49 -0500, Tom Lane wrote:
> Joe Conway writes:
> > Is there really a compelling reason to not just create toast tables for
> > all system catalogs as in the attached?
>
> What happens when you VACUUM FULL pg_class? (The associated toast table
> would have to be nonempty for t
On 2/20/18, Michael Paquier wrote:
> Regression tests of pg_upgrade are failing as follows:
> New cluster database "postgres" is not empty
> Failure, exiting
> + rm -rf /tmp/pg_upgrade_check-Xn0ZLe
I looked into this briefly. The error comes from
check_new_cluster_is_empty() in src/bin/pg_upgrade
On 06/15/2018 02:40 PM, John Naylor wrote:
> On 2/19/18, Joe Conway wrote:
>> The attached does exactly this. Gives all system tables toast tables
>> except pg_class, pg_attribute, and pg_index, and includes cat version
>> bump and regression test in misc_sanity.
>>
>> Any further discussion, comm
On 2/19/18, Joe Conway wrote:
> The attached does exactly this. Gives all system tables toast tables
> except pg_class, pg_attribute, and pg_index, and includes cat version
> bump and regression test in misc_sanity.
>
> Any further discussion, comments, complaints?
Hi Joe,
There's been a little b
On Sun, Feb 18, 2018 at 10:43 AM, Joe Conway wrote:
> Is there really a compelling reason to not just create toast tables for
> all system catalogs as in the attached? Then we could just check for 0
> rows in misc_sanity.sql.
+1. I don't have a huge problem with excluding a few key catalogs for
On Mon, Feb 19, 2018 at 11:33:30AM -0500, Joe Conway wrote:
> The attached does exactly this. Gives all system tables toast tables
> except pg_class, pg_attribute, and pg_index, and includes cat version
> bump and regression test in misc_sanity.
>
> Any further discussion, comments, complaints?
T
On 02/18/2018 01:33 PM, Joe Conway wrote:
> On 02/18/2018 11:18 AM, Tom Lane wrote:
>> I'm fairly suspicious of toasting anything that the toast mechanism itself
>> depends on, actually, and that would include at least pg_attribute and
>> pg_index as well as pg_class. Maybe we could get away with
On 02/18/2018 11:18 AM, Tom Lane wrote:
> Joe Conway writes:
>> Is there really a compelling reason to not just create toast tables for
>> all system catalogs as in the attached?
>
> What happens when you VACUUM FULL pg_class? (The associated toast table
> would have to be nonempty for the test
Joe Conway writes:
> Is there really a compelling reason to not just create toast tables for
> all system catalogs as in the attached?
What happens when you VACUUM FULL pg_class? (The associated toast table
would have to be nonempty for the test to prove much.)
I'm fairly suspicious of toasting
On 02/17/2018 11:39 AM, Tom Lane wrote:
> Joe Conway writes:
>> Yes, exactly. I'm fine with not backpatching, just wanted to raise the
>> possibility. I will push later today to HEAD (with a catalog version bump).
>
> BTW, I was wondering if it'd be a good idea to try to forestall future
> oversi
On Sat, Feb 17, 2018 at 03:52:33PM -0800, Andres Freund wrote:
> I've a hard hard hard time believing this is something useful to do. I
> mean by that argument you can just cause trouble everywhere by just
> storing arbitrarily large stuff via sql.
Did you read my last email until the end? Partic
Hi,
On 2018-02-18 08:48:37 +0900, Michael Paquier wrote:
> On Sat, Feb 17, 2018 at 08:52:11AM -0800, Andres Freund wrote:
> > On 2018-02-17 11:39:57 -0500, Tom Lane wrote:
> > > pg_authid | rolpassword | text
> >
> > that seems not not to require one.
>
> You can craft SCRAM v
On Sat, Feb 17, 2018 at 08:52:11AM -0800, Andres Freund wrote:
> On 2018-02-17 11:39:57 -0500, Tom Lane wrote:
> > pg_authid | rolpassword | text
>
> that seems not not to require one.
You can craft SCRAM verifiers that make it fail, which can be easily
done using this module:
Andres Freund writes:
> On 2018-02-17 11:39:57 -0500, Tom Lane wrote:
>> pg_aggregate| agginitval | text
>> pg_aggregate| aggminitval | text
> Seems like it should have a toast table, it's not too hard to imagine
> some form of aggregate to have a large initial co
On 2018-02-17 11:39:57 -0500, Tom Lane wrote:
> BTW, I was wondering if it'd be a good idea to try to forestall future
> oversights of this sort by adding a test query in, say, misc_sanity.sql.
> Something like
+many
> relname | attname | atttypid
>
Joe Conway writes:
> Yes, exactly. I'm fine with not backpatching, just wanted to raise the
> possibility. I will push later today to HEAD (with a catalog version bump).
BTW, I was wondering if it'd be a good idea to try to forestall future
oversights of this sort by adding a test query in, say,
On 02/16/2018 05:24 PM, Tom Lane wrote:
> Joe Conway writes:
>> On 02/16/2018 05:07 PM, Andres Freund wrote:
>>> If problematic for < master users I think you'll have to restart cluster
>>> with allow_system_table_mods, manually create/drop toasted column. IIRC
>>> that should add a toast table ev
Joe Conway writes:
> On 02/16/2018 05:07 PM, Andres Freund wrote:
>> On 2018-02-16 16:56:15 -0500, Joe Conway wrote:
>>> Looking at the issue, the problem seems to be missing toast table for
>>> pg_policy. Also attached is a one line patch. It isn't clear to me
>
On 02/16/2018 05:07 PM, Andres Freund wrote:
> Hi,
>
> On 2018-02-16 16:56:15 -0500, Joe Conway wrote:
>> Looking at the issue, the problem seems to be missing toast table for
>> pg_policy. Also attached is a one line patch. It isn't clear to me
>> whether this
Hi,
On 2018-02-16 16:56:15 -0500, Joe Conway wrote:
> Looking at the issue, the problem seems to be missing toast table for
> pg_policy. Also attached is a one line patch. It isn't clear to me
> whether this is a candidate for backpatching.
Don't think it is - it'd no
Currently if you try to create a too large policy, it fails with:
ERROR: row is too big: size X, maximum size 8160
An example for reproducing this is attached.
Looking at the issue, the problem seems to be missing toast table for
pg_policy. Also attached is a one line patch. It isn
40 matches
Mail list logo