On Thu, Jul 2, 2020 at 2:02 AM Tom Lane wrote:
> Anders Steinlein writes:
> > We have a materialized view from which a customer reported some
> > confusing/invalid results, leading us to inspect the query and not
> finding
> > anything wrong. Running the query defining the matview manually, or
>
On Thu, Jul 2, 2020 at 2:02 AM Tom Lane wrote:
> Anders Steinlein writes:
> > We have a materialized view from which a customer reported some
> > confusing/invalid results, leading us to inspect the query and not
> finding
> > anything wrong. Running the query defining the matview manually, or
>
On Thu, Jul 2, 2020 at 12:12 PM Magnus Hagander wrote:
>
> On Thu, Jul 2, 2020 at 2:02 AM Tom Lane wrote:
>
>> Anders Steinlein writes:
>> > We have a materialized view from which a customer reported some
>> > confusing/invalid results, leading us to inspect the query and not
>> finding
>> > an
On Thu, Jul 2, 2020 at 1:26 PM Anders Steinlein wrote:
> On Thu, Jul 2, 2020 at 2:02 AM Tom Lane wrote:
>
>> Anders Steinlein writes:
>> > We have a materialized view from which a customer reported some
>> > confusing/invalid results, leading us to inspect the query and not
>> finding
>> > anyt
Is now() computed at the time the view is defined and not at refresh? If
this were a function, I would be more suspicious of that but a plain view,
surely not. I hope.
>
It looks like you are using now() fairly often in that query. That would,
of course, give different results in different transactions, but it could
also give different results if a) the things you are comparing now() to are
timestamp without time zone and b) the session time zone of the user doing
On Thu, Jul 2, 2020 at 3:01 PM Jeremy Smith wrote:
> It looks like you are using now() fairly often in that query. That would,
> of course, give different results in different transactions, but it could
> also give different results if a) the things you are comparing now() to are
> timestamp wit
Hi Michael,
> On 02. Jul, 2020, at 14:55, Michael Lewis wrote:
>
> Is now() computed at the time the view is defined and not at refresh? If this
> were a function, I would be more suspicious of that but a plain view, surely
> not. I hope.
now() returns the time at the beginning of the transac
Anders Steinlein writes:
> On Thu, Jul 2, 2020 at 2:02 AM Tom Lane wrote:
>> I suspect the query underlying the matviews is less deterministic than
>> you think it is.
> Thanks for the tip, but I'm having a hard time thinking that's the case,
> seeing as I'm unable to trigger the wrong result no
On Thursday, July 2, 2020, Anders Steinlein wrote:
>
>
>> Thanks for the tip, but I'm having a hard time thinking that's the case,
>> seeing as I'm unable to trigger the wrong result no matter how hard I try
>> with a new definition/manual query. I've introduced random ordering to the
>> first CT
On Thu, Jul 2, 2020 at 3:44 PM Tom Lane wrote:
> Anders Steinlein writes:
> > On Thu, Jul 2, 2020 at 2:02 AM Tom Lane wrote:
> >> I suspect the query underlying the matviews is less deterministic than
> >> you think it is.
>
> > Thanks for the tip, but I'm having a hard time thinking that's the
How can I catch the errors generated whne I call an INSERT that violates a
constraint? I have coded like this:
my $sth = $dbh->prepare($stmt);
my $rv = $sth->execute() or die $DBI::errstr;
if ( $rv < 0 ) {
On Thu, Jul 2, 2020 at 3:55 PM David G. Johnston
wrote:
> On Thursday, July 2, 2020, Anders Steinlein wrote:
>>
>>
>> I just wanted to add that we're on Postgres 12.3. This matview has been
>> with us since 9.4 days, and we have not experienced any such issues before
>> (could be customers who h
Hi,
If my primary postgresql database will crash and there will be some lag
between primary and standby database then how to findout from standby side
that till what duration data will be available on standby postgresql
database?
Thanks,
Brajendra
Hi,
Please help us to configure the restore_command on postgresql replication
server's recovery.conf file incase of ERROR: requested wal segment has
already been removed on primary and when we have implemented pgbackrest on
primary database.
Primary database -
archive_command = 'pgbackrest --sta
On Thu, 2 Jul 2020 11:03:37 -0400
stan wrote:
> my $sth = $dbh->prepare($stmt);
> my $rv = $sth->execute() or die $DBI::errstr;
that ``or die`` means: if the result of the ``execute`` is false
(which only happens on error), throw an exception (which, as you
noticed, terminates the process unless
Stan:
On Thu, Jul 2, 2020 at 5:03 PM stan wrote:
> How can I catch the errors generated whne I call an INSERT that violates a
> constraint? I have coded like this:
>
> my $sth = $dbh->prepare($stmt);
> my $rv = $sth->execute() or die $DBI::errstr;
>
On Thu, Jul 2, 2020 at 8:06 AM Anders Steinlein wrote:
> On Thu, Jul 2, 2020 at 3:55 PM David G. Johnston <
> david.g.johns...@gmail.com> wrote:
>
>> On Thursday, July 2, 2020, Anders Steinlein wrote:
>>>
>>>
>>> I just wanted to add that we're on Postgres 12.3. This matview has been
>>> with us
Greetings,
* Brajendra Pratap Singh (singh.bpratap...@gmail.com) wrote:
> Please help us to configure the restore_command on postgresql replication
> server's recovery.conf file incase of ERROR: requested wal segment has
> already been removed on primary and when we have implemented pgbackrest on
Anders Steinlein writes:
>> Even that perhaps isn't conclusive, so you could
>> also try comparing the pg_rewrite.ev_action fields for the views'
>> ON SELECT rules. (That might be a bit frustrating because of likely
>> inconsistencies in node "location" fields; but any other difference
>> is cau
On Thu, Jul 2, 2020 at 8:44 AM Tom Lane wrote:
> A plausible explanation for how things got that way is that citext's
> equality operator wasn't in your search_path when you created the original
> matview, but it is in view when you make the new one, allowing that
> equality operator to capture t
On Thu, Jul 2, 2020 at 8:54 AM Jeremy Schneider wrote:
>
> https://www.postgresql.org/message-id/flat/CABTbUpiAOKZ405uArt8cJFtC72RhzthmvWETQK_6Qw0Ad-HquQ%40mail.gmail.com
>
> This thread on hackers actually seemed kindof short to me. Not nearly
> enough bike-shedding to call it a closed case.
>
On 7/2/20 8:54 AM, Jeremy Schneider wrote:
Maybe it's just me, but I'm wondering if it's worth changing the default
behavior of psql so it doesn't abort transactions in interactive mode
when I mistakenly mis-spell "select" or something silly like that. This
is of course easily remedied in my p
On 7/2/20 9:44 AM, Jeremy Schneider wrote:
On 7/2/20 09:28, David G. Johnston wrote:
The status quo prevailed since no-one chose to contribute further
arguments for change and the original patch was retracted. What kind
of "bike-shedding" (which seems to be used incorrectly here) would you
ex
On 7/2/20 9:44 AM, Jeremy Schneider wrote:
On 7/2/20 09:28, David G. Johnston wrote:
The status quo prevailed since no-one chose to contribute further
arguments for change and the original patch was retracted. What kind
of "bike-shedding" (which seems to be used incorrectly here) would you
ex
On Thu, Jul 2, 2020 at 5:43 PM Tom Lane wrote:
> Anders Steinlein writes:
> >> Even that perhaps isn't conclusive, so you could
> >> also try comparing the pg_rewrite.ev_action fields for the views'
> >> ON SELECT rules. (That might be a bit frustrating because of likely
> >> inconsistencies in
Anders Steinlein writes:
> On Thu, Jul 2, 2020 at 5:43 PM Tom Lane wrote:
>> Unfortunately,
>> since the reverse-listing of this join is just going to say "USING
>> (email)", there's no way to detect from human-readable output that the
>> interpretation of the USING clauses is different. (We've
I am confused about one claim in this blog post:
https://www.2ndquadrant.com/en/blog/oracle-to-postgresql-binary-objects
All columns that come after data > 2000 bytes participate in The
Large Attribute Strorage Technique (TOAST). This storage is for the
row, not the column. Your id column comes
On Thu, Jul 2, 2020 at 11:44 PM Tom Lane wrote:
> Anders Steinlein writes:
> > I'm reading this correctly, would this be a "reason" to be more explicit
> > when doing joins involving non-standard data types? I.e. would it be
> > "safer" to do ON x1.email::citext == x2.email::citext instead of US
Thomas Kellerer writes:
> I am confused about one claim in this blog post:
> https://www.2ndquadrant.com/en/blog/oracle-to-postgresql-binary-objects
>> All columns that come after data > 2000 bytes participate in The
>> Large Attribute Strorage Technique (TOAST). This storage is for the
>> row,
Anders Steinlein writes:
> Am I right in thinking that we should actually go over (i.e. re-create) all
> functions and views defined before this dump/restore where we're using JOIN
> ... USING (citext_column)? We most definitely have many more such cases,
> since this is the common (perhaps naive)
Another thing that was said I wasn't aware of and have not been able to
find any evidence to support:
> 10. Blobs don’t participate in Logical replication.
On 7/2/20 4:29 PM, Adam Brusselback wrote:
Another thing that was said I wasn't aware of and have not been able to
find any evidence to support:
https://www.postgresql.org/docs/12/logical-replication-restrictions.html
"Large objects (see Chapter 34) are not replicated. There is no
workaround
>
> > https://www.postgresql.org/docs/12/logical-replication-restrictions.html
> >
> > "Large objects (see Chapter 34) are not replicated. There is no
> > workaround for that, other than storing data in normal tables."
> >
> > Of course that does not apply to bytea:
> >
> https://www.postgres
On Thu, 2020-07-02 at 09:31 -0700, Adrian Klaver wrote:
> I would say just add a message to the ERROR that points out
> ON_ERROR_ROLLBACK = 'on' is available. For instance:
>
> test(5432)=# begin ;
> BEGIN
> test(5432)=# select 1/0;
> ERROR: division by zero
> test(5432)=# select 1;
> ERROR: cu
On Thu, 2020-07-02 at 08:54 -0700, Jeremy Schneider wrote:
> Maybe it's just me, but I'm wondering if it's worth changing the default
> behavior
> of psql so it doesn't abort transactions in interactive mode when I mistakenly
> mis-spell "select" or something silly like that.
> This is of course e
36 matches
Mail list logo
