Hi All,
Kindly check the below scenario with INTERVAL datatype.
postgres=# select interval '01 20:59:59' + interval '00 05:00:01' as
interval;
interval
1 day 26:00:00
(1 row)
Any operation with INTERVAL data, We are changing the interval values as
"60 sec" as "next minute"
Hi All,
While using IMMUTABLE functions in index expression, we are getting below
corruption on HEAD.
postgres=# CREATE TABLE tab1 (c1 numeric, c2 numeric);
CREATE TABLE
postgres=# INSERT INTO tab1 values (10, 100);
INSERT 0 1
postgres=# CREATE OR REPLACE FUNCTION func1(var1 numeric)
RETURNS
On Mon, Aug 23, 2021 at 4:29 AM Noah Misch wrote:
> On Wed, Aug 18, 2021 at 10:32:10PM -0700, Noah Misch wrote:
> > On Wed, Aug 18, 2021 at 10:47:24AM -0400, Robert Haas wrote:
> > > On Tue, Aug 10, 2021 at 9:35 AM Robert Haas
> wrote:
> > > > Oh, yeah, I think that works, actually. I was
Hi,
On Thu, Jul 29, 2021 at 9:46 PM Robert Haas wrote:
> On Wed, Jul 28, 2021 at 7:33 AM Amul Sul wrote:
> > I was too worried about how I could miss that & after thinking more
> > about that, I realized that the operation for ArchiveRecoveryRequested
> > is never going to be skipped in the
On Mon, Apr 19, 2021 at 2:16 PM Amit Langote
wrote:
> Hi Prabhat,
>
> On Mon, Apr 19, 2021 at 5:13 PM Prabhat Sahu
> wrote:
> >
> > Hi All,
> >
> > Please help me out with my doubt in RANGE partition with TEXT datatype:
> >
> > postgres=# create
Hi All,
Please help me out with my doubt in RANGE partition with TEXT datatype:
postgres=# create table tab1 (col1 text) PARTITION BY RANGE (col1);
CREATE TABLE
postgres=# create table p1 (col1 text);
CREATE TABLE
-- Partition with range from '5' to '10' shows error:
postgres=# alter table
Hi all,
While testing this feature with v20-patch, the server is crashing with
below steps.
Steps to reproduce:
1. Configure master-slave replication setup.
2. Connect to Slave.
3. Execute below statements, it will crash the server:
SELECT pg_prohibit_wal(true);
SELECT pg_prohibit_wal(false);
--
Hi All,
I was testing the feature on top of v3 patch and found the "pg_upgrade"
failure after keeping "alter system read only;" as below:
-- Steps:
./initdb -D data
./pg_ctl -D data -l logs start -c
./psql postgres
alter system read only;
\q
./pg_ctl -D data -l logs stop -c
./initdb -D data2
On Wed, Apr 29, 2020 at 8:52 AM 曾文旌 wrote:
> 2020年4月27日 下午9:48,Prabhat Sahu 写道:
>
> Thanks Wenjing, for the fix patch for previous issues.
> I have verified the issues, now those fix look good to me.
> But the below error message is confusing(for gtt2).
>
> postgres=# dro
On Fri, May 29, 2020 at 8:30 PM Pavel Stehule
wrote:
>
>
> pá 29. 5. 2020 v 16:45 odesílatel Prabhat Sahu <
> prabhat.s...@enterprisedb.com> napsal:
>
>> Hi All,
>>
>> Please check the below scenario, with pseudotype "anyelement" for IN, OUT
Hi All,
Please check the below scenario, with pseudotype "anyelement" for IN, OUT
parameter and the RETURN record in a function.
postgres=# create table tab1(c1 int, c2 int, c3 timestamp) ;
CREATE TABLE
postgres=# CREATE OR REPLACE FUNCTION func_any(IN anyelement, IN
anyelement, OUT v1
obal temp table gtt2 when other backend attached it."?
I mean, without giving extra information for the index attached to that GTT.
On Mon, Apr 27, 2020 at 5:34 PM 曾文旌 wrote:
>
>
> 2020年4月27日 下午5:26,Prabhat Sahu 写道:
>
> Hi Wenjing,
>
> Please check the below scenario
Hi Wenjing,
Please check the below scenario shows different error message with "DROP
TABLE gtt;" for gtt with and without index.
*-- Session1:*postgres=# create global temporary table gtt1 (c1 int);
CREATE TABLE
postgres=# create global temporary table gtt2 (c1 int);
CREATE TABLE
postgres=#
ostgres=# DROP TABLE gtt DROP;
DROP TABLE
Does this syntax intensional? If not, we should get a syntax error.
On Fri, Apr 24, 2020 at 10:25 AM Prabhat Sahu
wrote:
> Hi Wenjing,
>
> Please check, the server getting crash with the below scenario(CLUSTER gtt
> using INDEX).
>
> *--
Hi Wenjing,
Please check, the server getting crash with the below scenario(CLUSTER gtt
using INDEX).
*-- Session1:*
postgres=# create global temporary table gtt (c1 integer) on commit
preserve rows;
CREATE TABLE
postgres=# create index idx1 on gtt (c1);
CREATE INDEX
*-- Session2:*
postgres=#
s=# CLUSTER gtt2 USING idx2;
CLUSTER
In Case2, Case3 we can observe, with the absence of data in GTT, we are
able to "CLUSTER gtt2 USING idx2;" (having partial index)
But why does the same query fail for Case1 (absence of data)?
Thanks,
Prabhat Sahu
>
>
> Wenjing
>
>
>
> I think this is expected, and user test_gtt does not have permission to
> vacuum the system table.
> This has nothing to do with GTT.
>
> Hi Wenjing, Thanks for the explanation.
Thanks for the new patch. I have verified the crash, Now its resolved.
--
With Regards,
Prabhat Kumar Sahu
Hi Wenjing,
Please check below scenario, we are getting a server crash with "ALTER
TABLE" add column with default value as sequence:
-- Create gtt, exit and re-connect the psql prompt, create sequence, alter
table add a column with sequence.
postgres=# create global temporary table gtt1 (c1
On Fri, Apr 17, 2020 at 2:44 PM 曾文旌 wrote:
>
> I improved the logic of the warning message so that when the gap between
> relfrozenxid of GTT is small,
> it will no longer be alarmed message.
>
Hi Wenjing,
Thanks for the patch(v26), I have verified the previous related issues, and
are working
On Wed, Apr 8, 2020 at 1:48 PM 曾文旌 wrote:
>
>
> 2020年4月7日 下午6:22,Prabhat Sahu 写道:
>
> Thanks for review.
>> This parameter should support all types of writing of the bool type like
>> parameter autovacuum_enabled.
>> So I fixed in global_temporary_table_v24-pg1
>
> Thanks for review.
> This parameter should support all types of writing of the bool type like
> parameter autovacuum_enabled.
> So I fixed in global_temporary_table_v24-pg13.patch.
>
Thank you Wenjing for the new patch with the fix and the "VACUUM FULL GTT"
support.
I have verified the above
Hi Wenjing,
Please check the allowed values for boolean parameter
"on_commit_delete_rows".
postgres=# create global temp table gtt1(c1 int)
with(on_commit_delete_rows='true');
CREATE TABLE
Similarly we can successfully create GTT by using the values as:
'true','false', true, false, 'ON', 'OFF',
exit from all other sessions.
postgres=# drop table gtt2 ;
DROP TABLE
Kindly let me know if I am missing something.
On Wed, Apr 1, 2020 at 6:26 PM Prabhat Sahu
wrote:
> Hi Wenjing,
> I hope we need to change the below error message.
>
> postgres=# create global temporary table
Hi Wenjing,
I hope we need to change the below error message.
postgres=# create global temporary table gtt(c1 int) on commit preserve
rows;
CREATE TABLE
postgres=# create materialized view mvw as select * from gtt;
ERROR: materialized views must not use global temporary tables* or views*
On Wed, Apr 1, 2020 at 8:52 AM 曾文旌 wrote:
>
>
> 2020年3月31日 下午9:59,Prabhat Sahu 写道:
>
> Hi Wenjing,
> Thanks for the new patch.
> I saw with the patch(gtt_v23.patch), we are supporting the new concept
> "global temporary sequence"(i.e. session-specifi
Hi Wenjing,
Thanks for the new patch.
I saw with the patch(gtt_v23.patch), we are supporting the new concept
"global temporary sequence"(i.e. session-specific sequence), is this
intentional?
postgres=# create *global temporary sequence* gt_seq;
CREATE SEQUENCE
postgres=# create sequence seq;
> Sorry, I introduced this bug in my refactoring.
> It's been fixed.
>
> Wenjing
>
> Hi Wenjing,
This patch(gtt_v21_pg13.patch) is not applicable on PG HEAD, I hope you
have prepared the patch on top of some previous commit.
Could you please rebase the patch which we can apply on HEAD ?
--
With
Hi All,
Please check the behavior of GTT having column with "SERIAL" datatype and
column with default value as "SEQUENCE" as below:
*Session1:*postgres=# create sequence gtt_c3_seq;
CREATE SEQUENCE
postgres=# create global temporary table gtt(c1 int, c2 serial, c3 int
default
:
>
>
> 2020年3月11日 下午3:52,Prabhat Sahu 写道:
>
> On Mon, Mar 9, 2020 at 10:02 PM 曾文旌(义从)
> wrote:
>
>>
>>
>> Fixed in global_temporary_table_v18-pg13.patch.
>>
> Hi Wenjing,
> Thanks for the patch. I have verified the previous issues wi
On Thu, Mar 19, 2020 at 3:51 PM wenjing.zwj
wrote:
> postgres=# CREATE LOCAL TEMPORARY TABLE gtt1(c1 serial PRIMARY KEY, c2
> VARCHAR (50) UNIQUE NOT NULL) ON COMMIT DELETE ROWS;
> CREATE TABLE
> postgres=# CREATE LOCAL TEMPORARY TABLE gtt2(c1 integer NOT NULL, c2
> integer NOT NULL,
>
On Mon, Mar 16, 2020 at 1:30 PM Konstantin Knizhnik <
k.knizh...@postgrespro.ru> wrote:
>
> It seems to be expected behavior: GTT data is private to the session and
> postgres_fdw establish its own session where content of the table is empty.
> But if you insert some data in f_gtt1, then you will
Hi Wenjing,
Please check the below scenario, where the Foreign table on GTT not showing
records.
postgres=# create extension postgres_fdw;
CREATE EXTENSION
postgres=# do $d$
begin
execute $$create server fdw foreign data wrapper postgres_fdw
options (host 'localhost',dbname
Hi Wenjing,
Please check the below combination of GTT with Primary and Foreign key
relations, with the ERROR message.
*Case1:*postgres=# CREATE GLOBAL TEMPORARY TABLE gtt1(c1 serial PRIMARY
KEY, c2 VARCHAR (50) UNIQUE NOT NULL) ON COMMIT *DELETE* ROWS;
CREATE TABLE
postgres=# CREATE GLOBAL
Hi Wenjing,
Please check the below findings:
After running "TRUNCATE" command, the "relfilenode" field is not changing
for GTT
whereas, for Simple table/Temp table "relfilenode" field is changing after
TRUNCATE.
*Case 1: Getting same "relfilenode" for GTT after and before "TRUNCATE"*
postgres=#
Hi all,
Please check the below behavior for the "SERIAL" datatype.
postgres=# CREATE TABLE t1(c1 int, c2 serial);
CREATE TABLE
postgres=# insert into t1 values (generate_series(1,3));
INSERT 0 3
postgres=# insert into t1 values (generate_series(4,6));
INSERT 0 3
postgres=# select * from t1;
c1 |
On Mon, Mar 9, 2020 at 10:02 PM 曾文旌(义从) wrote:
>
>
> Fixed in global_temporary_table_v18-pg13.patch.
>
Hi Wenjing,
Thanks for the patch. I have verified the previous issues with
"gtt_v18_pg13.patch" and those are resolved.
Please find below case:
postgres=# create sequence seq;
CREATE SEQUENCE
Hi All,
Kindly check the below scenario.
*Case 1: *
postgres=# CREATE GLOBAL TEMPORARY TABLE gtt1(c1 int) on commit delete rows;
CREATE TABLE
postgres=# CREATE GLOBAL TEMPORARY TABLE gtt2(c1 int) on commit preserve
rows;
CREATE TABLE
postgres=# vacuum gtt1;
VACUUM
postgres=# vacuum gtt2;
VACUUM
On Tue, Mar 3, 2020 at 2:11 PM 曾文旌(义从) wrote:
>
>
>
> I fixed in global_temporary_table_v16-pg13.patch.
>
Thank you Wenjing for the patch.
Now we are getting corruption with GTT with below scenario.
postgres=# CREATE GLOBAL TEMPORARY TABLE gtt1(c1 bigint, c2 bigserial) on
commit delete rows;
reference only temporary tables
Thanks,
Prabhat Sahu
On Tue, Feb 25, 2020 at 2:25 PM 曾文旌(义从) wrote:
>
>
> 2020年2月24日 下午5:44,Prabhat Sahu 写道:
>
> On Fri, Feb 21, 2020 at 9:10 PM 曾文旌(义从)
> wrote:
>
>> Hi,
>> I have started testing the "Global temporary table&qu
REATE TABLE
postgres=# create temporary table child2() inherits (parent2);
CREATE TABLE
postgres=# insert into parent2 values(1);
INSERT 0 1
postgres=# insert into child2 values(2);
INSERT 0 1
postgres=# select * from parent2;
a
---
2
(1 row)
postgres=# select * from child2;
a
---
2
(1 row)
Thanks,
Prabhat Sahu
bal temp table
postgres=# create table tab2 (c1 int references gtt1(c1) );
ERROR: referenced relation "gtt1" is not a global temp table
Thanks,
Prabhat Sahu
Hi,
I have started testing the "Global temporary table" feature,
from "gtt_v11-pg13.patch". Below is my findings:
-- session 1:
postgres=# create global temporary table gtt1(a int);
CREATE TABLE
-- seeeion 2:
postgres=# truncate gtt1 ;
ERROR: could not open file "base/13585/t3_16384": No such
Hi all,
I would like to share my observation on this PG feature "Block-level
parallel vacuum".
I have tested the earlier patch (i.e v48) with below high-level test
scenarios, and those are working as expected.
- I have played around with these GUC parameters while testing
On Wed, Dec 25, 2019 at 8:01 AM Michael Paquier wrote:
> On Tue, Dec 24, 2019 at 05:29:25PM +0530, Prabhat Sahu wrote:
> > While performing below operations with Master-Slave configuration, Slave
> is
> > crashed.
> > Below are the steps to reproduce:
> &g
Hi,
While performing below operations with Master-Slave configuration, Slave is
crashed.
Below are the steps to reproduce:
-- create a Slave using pg_basebackup and start:
./pg_basebackup -v -R -D d2 -p 55510
mkdir /home/centos/ts1
-- Session 1(Master):
./psql postgres -p 55510
CREATE
Hi,
While testing this feature with parallel vacuum on "TEMPORARY TABLE", I got
a server crash on PG Head+V36_patch.
Changed configuration parameters and Stack trace are as below:
autovacuum = on
max_worker_processes = 4
shared_buffers = 10MB
max_parallel_workers = 8
On Wed, Dec 18, 2019 at 6:04 PM Amit Kapila wrote:
> On Wed, Dec 18, 2019 at 6:01 PM Prabhat Sahu <
> prabhat.s...@enterprisedb.com> wrote:
>
>> Hi all,
>>
>> While testing on v36 patch with gist index, I came across below
>> segmentation fault.
>&g
Hi all,
While testing on v36 patch with gist index, I came across below
segmentation fault.
-- PG Head+ v36_patch
create table tab1(c1 int, c2 text PRIMARY KEY, c3 bool, c4 timestamp
without time zone, c5 timestamp with time zone, p point);
create index gist_idx1 on tab1 using gist(p);
create
if the fsync was performed just
> once or twice i.e. whether point #1 is the reason for the panic or point
> #2.
>
I have ran the same testcases with and without patch multiple times with
debug option (log_min_messages = DEBUG1), but this time I am not able to
reproduce the crash.
>
On Wed, Oct 30, 2019 at 9:46 PM Robert Haas wrote:
> On Wed, Oct 30, 2019 at 3:49 AM Prabhat Sahu <
> prabhat.s...@enterprisedb.com> wrote:
>
>> While testing the Toast patch(PG+v7 patch) I found below server crash.
>> System configuration:
>> VCPUs: 4, RAM: 8GB
Hi All,
While testing the Toast patch(PG+v7 patch) I found below server crash.
System configuration:
VCPUs: 4, RAM: 8GB, Storage: 320GB
This issue is not frequently reproducible, we need to repeat the same
testcase multiple times.
CREATE OR REPLACE FUNCTION toast_chunks_cnt_func(p1 IN text)
On Mon, Jul 8, 2019 at 9:06 PM Robert Haas wrote:
> On Tue, Jun 25, 2019 at 2:19 AM Prabhat Sahu
> wrote:
> > I have tested the TOAST patches(v3) with different storage options
> like(MAIN, EXTERNAL, EXTENDED, etc.), and
> > combinations of compression and out-of-line s
column "b"
than parent
DETAIL: EXTENDED versus MAIN
Thanks,
Prabhat Sahu
On Wed, Jul 3, 2019 at 7:23 AM Amit Langote wrote:
> Hi Prabhat,
>
> On Tue, Jul 2, 2019 at 5:12 PM Prabhat Sahu
> wrote:
> >
> > Hi,
> >
> > In below testcase when I changed
Hi,
In below testcase when I changed the staorage option for root partition,
newly attached partition not including the changed staorage option.
Is this an expected behavior?
postgres=# CREATE TABLE tab1 (c1 INT, c2 text) PARTITION BY RANGE(c1);
CREATE TABLE
postgres=# create table tt_p1 as
On Tue, Jun 11, 2019 at 9:47 PM Robert Haas wrote:
> On Tue, May 21, 2019 at 2:10 PM Robert Haas wrote:
> > Updated and rebased patches attached.
>
> And again.
>
Hi Robert,
I have tested the TOAST patches(v3) with different storage options
like(MAIN, EXTERNAL, EXTENDED, etc.), and
Hi All,
While trying to explore on CHR() function in PG,
I found that few of the ASCII values are returning hex number values(like
'\x08', '\x0B')
and few are executing within SQL (i.e. chr(9) => Horizontal tab, chr(10)
=> Line feed) as below example.
postgres=# select 1|| chr(8)|| 2 ||
Hi,
I got a failure in pg_dump/pg_restore as below:
pg_dump/pg_restore fails with 'ERROR: schema "public" already exists' for
TAR_DUMP and CUSTOM_DUMP from v94/v95/v96 to v11/master.
-- Take pg_dump in v94/v95/v96:
[prabhat@localhost bin]$ ./pg_dump -f /tmp/*tar_dump_PG94.tar* -Ft postgres
-p
Hi All,
Few more findings on to_timestamp() test with HEAD.
postgres[3493]=# select to_timestamp('15-07-1984 23:30:32',' dd- mm-
hh24: mi: ss');
to_timestamp
---
1984-07-15 23:30:32+05:30
(1 row)
postgres[3493]=# select to_timestamp('15-07-*1984*
Hi All,
I have found below difference in TO_TIMESTAMP results.
postgres[114552]=# select to_timestamp('15-07-1984 23:30:32','dd-mm-
hh24:mi:ss');
to_timestamp
---
1984-07-15 23:30:32+05:30
(1 row)
postgres[114552]=# select to_timestamp('15-07-84
Hi Hackers,
While testing with PG procedure, I found a memory leak on HEAD, with below
steps:
postgres=# CREATE OR REPLACE PROCEDURE proc1(v1 INOUT INT)
AS $$
BEGIN
commit;
END; $$ LANGUAGE plpgsql;
CREATE PROCEDURE
postgres=# call proc1(10);
WARNING: Snapshot reference leak: Snapshot
Hi,
I have taken pg_dumpall in pg-master and after restoring the dump I am not
able to see the "Access privileges" as below:
Same is reproducible in back branches as well, is this fine ?
CREATE ROLE user1 PASSWORD 'user1' SUPERUSER LOGIN;
CREATE DATABASE db1 OWNER=user1;
GRANT ALL ON DATABASE
Hi,
I found a segmentation fault on pg master Head with below steps and
stacktrace.
postgres=# CREATE OR REPLACE FUNCTION func1() RETURNS VOID
LANGUAGE SQL
AS $$
select 10;
$$;
CREATE FUNCTION
postgres=# select func1();
server closed the connection unexpectedly
This probably means the server
On Wed, Mar 7, 2018 at 7:51 PM, Robert Haas <robertmh...@gmail.com> wrote:
> On Wed, Mar 7, 2018 at 8:59 AM, Prabhat Sahu <
> prabhat.s...@enterprisedb.com> wrote:
>>
>> 2018-03-07 19:24:44.263 IST [54400] LOG: background worker "parallel
>> worker"
On Wed, Mar 7, 2018 at 7:16 PM, Robert Haas <robertmh...@gmail.com> wrote:
> On Wed, Mar 7, 2018 at 8:13 AM, Prabhat Sahu <
> prabhat.s...@enterprisedb.com> wrote:
>
>> Hi all,
>>
>> While testing this feature I found a crash on PG head with parall
Hi all,
While testing this feature I found a crash on PG head with parallel create
index using pgbanch tables.
-- GUCs under postgres.conf
max_parallel_maintenance_workers = 16
max_parallel_workers = 16
max_parallel_workers_per_gather = 8
maintenance_work_mem = 8GB
max_wal_size = 4GB
./pgbench
Hi all,
I have been continue doing testing of parallel create index patch. So far
I haven't came across any sort of issue or regression with the patches.
Here are few performance number for the latest round of testing - which
is perform on top of 6th Jan patch submitted by Peter.
Testing is done
66 matches
Mail list logo