Re: "PANIC: could not open critical system index 2662" - twice

On Fri, 14 Apr 2023, Laurenz Albe wrote: >So if your disk replaces a valid block with zeros (filesystem check >after crash?), that could explain what you see. Oh, I had that happen on a RAID 1 once. On of the two discs had an intermittent error (write I guess) but didn’t fail out of the RAID, and

Re: "PANIC: could not open critical system index 2662" - twice

On Thu, 2023-04-13 at 19:07 +, Evgeny Morozov wrote: > On 13/04/2023 5:02 pm, Laurenz Albe wrote: > > It means that if the error is caused by a faulty disk changing your data, > > you'll notice as soon as you touch the page. > > > > That would perhaps not have made a lot of difference in your

Re: Why does "fetch last from cur" always cause error 55000 for non-scrollable cursor?

> t...@sss.pgh.pa.us wrote: > >> b...@yugabyte.com wrote: >> >> But why does "fetch last" fail here: >> >> -- Test Two >> start transaction; >> declare cur no scroll cursor without hold for >> select g.val as k, g.val*100 as v >> from generate_series(1, 10) as g(val

Re: Why does "fetch last from cur" always cause error 55000 for non-scrollable cursor?

Bryn Llewellyn writes: > But why does "fetch last" fail here: > -- Test Two > start transaction; > declare cur no scroll cursor without hold for > select g.val as k, g.val*100 as v > from generate_series(1, 10) as g(val) > order by g.val; > fetch first from cur; > fetch last from cu

Why does "fetch last from cur" always cause error 55000 for non-scrollable cursor?

I’m using Version 15.2. I did this test: -- Test One start transaction; declare cur no scroll cursor without hold for select g.val as k, g.val*100 as v from generate_series(1, 10) as g(val) order by g.val; fetch first from cur; fetch next from cur; fetch first from cur; rollback;

Re: "PANIC: could not open critical system index 2662" - twice

On 13/04/2023 5:02 pm, Laurenz Albe wrote: > It means that if the error is caused by a faulty disk changing your data, > you'll notice as soon as you touch the page. > > That would perhaps not have made a lot of difference in your case, > except that the error message would have been different and

Re: Unexpected behavior when combining `generated always` columns and update rules

Adrian Klaver writes: > On 4/13/23 09:27, Ciprian Craciun wrote: >> So, based on these observations, I think that `generated always` >> columns are actually computed on insertion, and thus they are not >> reflected in `new` on rules. > Just realized we may have both being saying the same thing. T

Re: Unexpected behavior when combining `generated always` columns and update rules

On 4/13/23 09:27, Ciprian Craciun wrote: On Thu, Apr 13, 2023 at 5:32 PM David G. Johnston wrote: ALSO rules behave like before triggers, not after triggers. The original command is appended to the end of the list of commands, not the start. As Tom observed, the documentation states that in

Re: Unexpected behavior when combining `generated always` columns and update rules

On 4/13/23 09:27, Ciprian Craciun wrote: On Thu, Apr 13, 2023 at 5:32 PM David G. Johnston wrote: ALSO rules behave like before triggers, not after triggers. The original command is appended to the end of the list of commands, not the start. As Tom observed, the documentation states that in

Re: Unexpected behavior when combining `generated always` columns and update rules

On Thu, Apr 13, 2023 at 5:32 PM David G. Johnston wrote: > ALSO rules behave like before triggers, not after triggers. The original > command is appended to the end of the list of commands, not the start. As Tom observed, the documentation states that in case of update rules, the original query

Re: JSON / ASP.NET AJAX Dates support in PostgreSQL

On 4/13/23 08:31, Sebastien Flaesch wrote: >From the investigation we did here, I can confirm that the number in AJAX Date is the milliseconds since Epoch (1970-01-01 00:00:00), and it's always in UTC, even if there is a timezone offset provided. I mention this because it's different from IS

Re: JSON / ASP.NET AJAX Dates support in PostgreSQL

>From the investigation we did here, I can confirm that the number in AJAX Date >is the milliseconds since Epoch (1970-01-01 00:00:00), and it's always in UTC, >even if there is a timezone offset provided. I mention this because it's >different from ISO 8601 datetimes, where the datetime part i

Re: JSON / ASP.NET AJAX Dates support in PostgreSQL

On 4/13/23 09:44, Sebastien Flaesch wrote: Hello, Is there an easy way to convert JSON data containing ASP.NET AJAX Dates into PostgreSQL timestamp? I have this kind of JSON data: {     "PurchaseOrder" : "45",     "CreationDate" : "\/Date(167235840)\/",     "LastChangeDateTime" :

Re: "PANIC: could not open critical system index 2662" - twice

On Thu, 2023-04-13 at 06:56 +, Evgeny Morozov wrote: > On 12/04/2023 2:35 am, Michael Paquier wrote: > > initdb does not enable checksums by default, requiring a > > -k/--data-checksums, so likely this addition comes from from your > > environment. > > OK, so then what does that mean for the e

JSON / ASP.NET AJAX Dates support in PostgreSQL

Hello, Is there an easy way to convert JSON data containing ASP.NET AJAX Dates into PostgreSQL timestamp? I have this kind of JSON data: { "PurchaseOrder" : "45", "CreationDate" : "\/Date(167235840)\/", "LastChangeDateTime" : "\/Date(1672692813062+0100)\/" } Warning: No

Re: Unexpected behavior when combining `generated always` columns and update rules

"David G. Johnston" writes: > On Thursday, April 13, 2023, Ciprian Craciun > wrote: >> create or replace rule propagate_x_and_d as on update to x do also >> update y set x = new.x, d = new.d where y.x = old.x; >> >> As seen above, although the rule correctly propagates the change to >> the `x` c

Re: Unexpected behavior when combining `generated always` columns and update rules

On Thursday, April 13, 2023, Ciprian Craciun wrote: > > create or replace rule propagate_x_and_d as on update to x do also > update y set x = new.x, d = new.d where y.x = old.x; > > As seen above, although the rule correctly propagates the change to > the `x` column, it fails to use the new v

Unexpected behavior when combining `generated always` columns and update rules

Hello all! I'm uncertain if what I've observed (and describe below) is a bug, works as expected (but I've not found it mentioned in the documentation), or it's just a by-product of combining two advanced features that haven't been thoroughly tested together. So, to summarize: I'm trying to use t

Re: Guidance on INSERT RETURNING order

On Thu, Apr 13, 2023, at 8:26 AM, John Howroyd wrote: > > However, the marshalling is presumably already happening (except any tie to > ordering to the original declared tuples); otherwise I really don't > understand how the with syntax (I think first suggested by Adrian Klaver) > would work

Re: [E] Re: parallel aggregation

Still not quite clear: 1. I wonder if there is a clean separation between the phases: once partial aggregation is done only combining is done after that (state transition function never receives results of combining). 2. Can a combiner output also go through serial-deserial before hitting another c

Re: Guidance on INSERT RETURNING order

A few more thoughts. My " simply marshal the RETURNING results through and in memory/temporary table maintaining the order from the SELECT and return these to the client upon commit" isn't quite right with the "upon commit": that (the commit) may happen much later with several statements wrapped i