On Mon, Jun 10, 2019 at 11:49:03PM -0700, Andres Freund wrote:
> Well, all four. Given it's just copied code I don't see much code in
> splitting the commit anymore.
Thanks for pushing the fix, the result looks fine.
> I noticed some other uglyness: check_timezone calls interval_in(),
> without a
Hi,
On 2019-06-11 14:56:36 +0900, Michael Paquier wrote:
> On Mon, Jun 10, 2019 at 10:33:37PM -0700, Andres Freund wrote:
> > Yea, that's where the default_table_access_method code originates from,
> > obviously. I'll backpatch the default_text_search_config fix separately
> > (and first).
>
> So
On Mon, Jun 10, 2019 at 10:33:37PM -0700, Andres Freund wrote:
> Yea, that's where the default_table_access_method code originates from,
> obviously. I'll backpatch the default_text_search_config fix separately
> (and first).
So you are just planning to add a check on MyDatabaseId for both? No
ob
Hi,
On 2019-06-10 16:37:33 +0900, Michael Paquier wrote:
> On Sat, Jun 08, 2019 at 08:26:07AM -0700, Andres Freund wrote:
> > We have plenty other callbacks that aren't bulletproof, so I don't think
> > this is really something we should / can change in isolation here.
>
> Good point. I was look
On Sat, Jun 08, 2019 at 08:26:07AM -0700, Andres Freund wrote:
> We have plenty other callbacks that aren't bulletproof, so I don't think
> this is really something we should / can change in isolation here.
Good point. I was looking at the check callbacks in guc.c for similar
changes, and missed
> On Sat, Jun 8, 2019 at 5:30 PM Andres Freund wrote:
>
> On 2019-06-08 16:03:09 +0200, Dmitry Dolgov wrote:
> > > On Thu, Jun 6, 2019 at 9:06 AM Michael Paquier
> > > wrote:
> > > The table AM lookup happens only when creating a table, so we could just
> > > get
> > > a failure when attempting
Hi,
On 2019-06-08 16:03:09 +0200, Dmitry Dolgov wrote:
> > On Thu, Jun 6, 2019 at 9:06 AM Michael Paquier wrote:
> > The table AM lookup happens only when creating a table, so we could just get
> > a failure when attempting to create a table with this incorrect value.
>
> is correct, but doesn't
Hi,
On 2019-06-06 16:06:36 +0900, Michael Paquier wrote:
> On Thu, Jun 06, 2019 at 11:19:48AM +1000, Haribabu Kommi wrote:
> > Thanks for the details steps to reproduce the bug, I am also able to
> > reproduce the problem.
>
> This way is even more simple, no need for zheap to be around:
> =# cre
> On Thu, Jun 6, 2019 at 9:06 AM Michael Paquier wrote:
>
> I was wondering if we actually need at all a catalog lookup at this
> stage, simplifying get_table_am_oid() on the way so as we always
> throw an error (its missing_ok is here to allow a proper error in the
> GUC context).
Just for me to
Thanks Hari for helping in verifying.
Regards,
Vignesh
EnterpriseDB: http://www.enterprisedb.com
On Thu, Jun 6, 2019 at 6:50 AM Haribabu Kommi
wrote:
>
> On Thu, Jun 6, 2019 at 1:46 AM vignesh C wrote:
>
>>
>> Hi,
>>
>> *I noticed pg_basebackup failure when default_table_access_method option
On Thu, Jun 06, 2019 at 11:19:48AM +1000, Haribabu Kommi wrote:
> Thanks for the details steps to reproduce the bug, I am also able to
> reproduce the problem.
This way is even more simple, no need for zheap to be around:
=# create access method heap2 TYPE table HANDLER heap_tableam_handler;
CREAT
On Thu, Jun 6, 2019 at 1:46 AM vignesh C wrote:
>
> Hi,
>
> *I noticed pg_basebackup failure when default_table_access_method option
> is set.*
>
> *Test steps:*
>
> Step 1: Init database
> ./initdb -D data
>
> Step 2: Start Server
> ./postgres -D data &
>
> Step 3: Set Guc option
> export PGOPTI
Hi,
*I noticed pg_basebackup failure when default_table_access_method option is
set.*
*Test steps:*
Step 1: Init database
./initdb -D data
Step 2: Start Server
./postgres -D data &
Step 3: Set Guc option
export PGOPTIONS='-c default_table_access_method=zheap'
Step 4: Peform backup
/pg_basebac
13 matches
Mail list logo
