[no subject]

2022-06-16 Thread Rama Krishnan
Hi , What type of temp database should i use to maintain logs or export logs? Thanks Rama-krishnan

Re:

2022-06-16 Thread Adrian Klaver
On 6/16/22 07:08, Rama Krishnan wrote: Hi , What type of temp database should i use to maintain logs or export logs? There is no temp database. You will need to be more specific about what you want to achieve. Thanks Rama-krishnan -- Adrian Klaver adrian.kla...@aklaver.com

Re: ERROR: failed to find conversion function from key_vals_nn to record[]

2022-06-16 Thread Tom Lane
"David G. Johnston" writes: > The fact that a domain over an array isn’t being seen as an array here > seems like a bug. Hmm. The attached quick-hack patch seems to make this better, but I'm not sure whether there are any cases it makes worse. regards, tom lane diff --g

Operators on ranges with a domain subtype do not implicitly cast operands of the domain's base type

2022-06-16 Thread Daniel Popowich
I'm using PG 14 and have an application using a custom range with a custom domain subtype. My problem: PG does not do an implicit cast from the domain's base type when used with range operators. Below is a script that will demonstrate the problem (and below that, the output of running it with psql)

Re: Operators on ranges with a domain subtype do not implicitly cast operands of the domain's base type

2022-06-16 Thread Tom Lane
Daniel Popowich writes: > -- domain with underlying type of integer (what constraints we might > -- place on the integer values are not germane to the issue so they're > -- left out). > create domain zzzint integer; > -- a range on our domain > create type zzzrange as rang

Re: Operators on ranges with a domain subtype do not implicitly cast operands of the domain's base type

2022-06-16 Thread Bryn Llewellyn
> dpopow...@artandlogic.com wrote: > > I'm using PG 14 and have an application using a custom range with a custom > domain subtype. My problem: PG does not do an implicit cast from the domain's > base type when used with range operators. I hit what looks to be

Re:

2022-06-16 Thread Abdul Qoyyuum
Best if you just maintain the logs into a log file instead of a database table. On Thu, Jun 16, 2022 at 10:08 PM Rama Krishnan wrote: > Hi , > > What type of temp database should i use to maintain logs or export logs? > > Thanks > Rama-krishnan > -- Abdul Qoyyuum Bin Haji Abdul Kadir HP No: +

Any way to understand state after data corruption failures during startup.

2022-06-16 Thread Harinath Kanchu
Hello, If postgres fail when it is starting as standby due to WAL file corruption, can we get the status through any exit code or by parsing pg_control file ? I can see the “XX001” code is emitted in logs but parsing logs doesn’t seem to be a good option. Please suggest. Thanks.

Re: ERROR: failed to find conversion function from key_vals_nn to record[]

2022-06-16 Thread Bryn Llewellyn
> david.g.johns...@gmail.com wrote: > >> b...@yugabyte.com wrote: >> >> This is what the doc promises. But how can you see it as anything but a bug? >> The subquery evaluates to "null", and only then is the attempt made to >> create a new row which self-evidently violates the domain's constrain

Re: ERROR: failed to find conversion function from key_vals_nn to record[]

2022-06-16 Thread David G. Johnston
On Thu, Jun 16, 2022 at 8:28 PM Bryn Llewellyn wrote: > > *Back to NULLs...* > > Your code examples ran without error and produced the results that you > described. I do understand the fact that, on its face, the NULLs in the > two cases arise for different reasons. But this (still) seems to me

Re: Any way to understand state after data corruption failures during startup.

2022-06-16 Thread Kyotaro Horiguchi
At Thu, 16 Jun 2022 19:46:25 -0700, Harinath Kanchu wrote in > > Hello, > > If postgres fail when it is starting as standby due to WAL file corruption, > can we get the status through any exit code or by parsing pg_control file ? > > I can see the “XX001” code is emitted in logs but parsing

Re: ERROR: failed to find conversion function from key_vals_nn to record[]

2022-06-16 Thread Bryn Llewellyn
> david.g.johns...@gmail.com wrote: > >> b...@yugabyte.com wrote: >> >> Can anybody show me an implementation of a realistic use case that follows >> proper practice — like "every table must a primary key", "a foreign key must >> refer to a primary key", and "joins may be made only "on" columns