then I get recursion error:
ERROR: infinite recursion detected in rules for relation "foo"
Possibly because the recursion analysis doesn't take WHERE condition
into account.
Any help would be greatly appreciated.
PostgreSQL version: 9.0.1 on CentOS 5 i686.
Best regards, Nikolay Karikh.
On Tue, Mar 13, 2018 at 1:05 AM, Ron Johnson wrote:
> v8.4.12
>
This is *very* old version, not supported by the community for many years.
Check https://www.postgresql.org/ to see currently supported versions.
You need to upgrade it.
On Tue, Mar 13, 2018 at 1:28 AM, Ron Johnson wrote:
> On 03/12/2018 05:20 PM, Nikolay Samokhvalov wrote:
>
> On Tue, Mar 13, 2018 at 1:05 AM, Ron Johnson
> wrote:
>
>> v8.4.12
>>
>
> This is *very* old version, not supported by the community for many years.
&
Why not set up a spot EC2 instance with Postgres 10.1, load database from a
dump (yes you’ll need to create one from RDS because they don’t provide
direct access to dumps/backups; probably you need to get only specific
tables) and repeat your actions, closely looking at filesystem.
ср, 16 мая 2018
On Tue, Jul 10, 2018 at 12:26 PM Ravi Krishna wrote:
>
>
>
> https://fle.github.io/temporarily-disable-all-indexes-of-a-postgresql-table.html
>
>
>
>
> This does not work in RDS. In order to update system catalog tables
> (pg_index), one needs privileges which is
> denied in RDS. In RDS terminol
On Thu, Aug 23, 2018 at 11:44 AM Joshua D. Drake
wrote:
> On 08/23/2018 04:47 AM, Achilleas Mantzios wrote:
> > On 23/08/2018 14:30, Sonam Sharma wrote:
> >> No, I didn't. The version is not compatible with application, so need
> >> to downgrade it
> >
> > Have you tried to tweak postgresql.conf
On Sat, Nov 2, 2019 at 8:52 PM Konstantin Gredeskoul
wrote:
> A related question is — *how can you avoid doing auto vacuum during the
> busy peak hours, and do more aggressive auto vacuuming at night during low
> traffic?* Is that possible?
>
> I tried achieving that with a manual vacuum, but tha
This is a very common task, definitely.
As for WebSockets, there is an addition to PostgREST, postgrest-websockets
https://github.com/diogob/postgres-websockets#readme
PostgREST is not only for "give me contents", you can write functions (in
any PL) and call them using POST /rpc/functionname.
Th
+1 of course
On Wed, Feb 5, 2020 at 6:55 PM Vik Fearing wrote:
> Hello,
>
> I proposed a patch to add %x to PROMPT1 and PROMPT2 by default in psql.
>
> The effect of this is:
>
> - nothing at all when not in a transaction,
> - adding a '*' when in a transaction or a '!' when in an aborted
> tr
On Wed, Feb 5, 2020 at 8:05 PM Vik Fearing wrote:
> Because it isn't always easy to modify the .psqlrc file. This is
> especially true if you frequently connect to other people's systems.
>
Exactly. You can tune your psql a lot, including excellent pspg,
but then you frequently troubleshoot oth
What a sad news.
Rest In Peace, Christopher.
Condolences to friends and family.
On Wed, Nov 4, 2020 at 15:29 Steve Singer wrote:
>
> It is with much sadness that I am letting the community know that Chris
> Browne passed away recently.
>
> Chris had been a long time community member and was ac
On Wed, Nov 11, 2020 at 12:26 AM Jitendra Loyal
wrote:
> Despite the above two constraints, the following rows get into the table:
> insert into t (b , c) values (null, true), (null, false);
>
This behavior is described in the docs
https://www.postgresql.org/docs/current/ddl-constraints.htm
On Thu, Apr 7, 2022 at 8:10 AM Jan Wieck wrote:
> So **IF** Active Record is using that feature, then it can dump any
> amount of garbage into your PostgreSQL database and PostgreSQL will
> happily accept it with zero integrity checking.
>
It's DISABLE TRIGGER ALL
https://github.com/rails/rails/
On Thu, Apr 6, 2023 at 9:17 PM Tatsuo Ishii wrote:
> With quorum failover is enabled, w0, w1, and w2 communicate each other
> to vote who is correct (if it cannot communicate, it regards other
> watchdog is down). In the case above w0 and w1 are majority and will
> win.
Communication takes time –
On Thu, Apr 6, 2023 at 11:13 PM Tatsuo Ishii wrote:
> I am welcome you to
> join and continue the discussion on pgpool mailing list.
I truly believe that this problem – HA – is PostgreSQL's, not 3rd
party's. And it's a shame that Postgres itself doesn't solve this. So
we're discussing it here.
On Mon, Oct 30, 2023 at 6:57 AM Alexander Kukushkin wrote:
...
> As Michael already said, the following workflow works just fine (I did it
> dozens of times):
> 1. enable checksums on the standby node
> 2. start the standby and let it catch up with the primary
> 3. switchover to a standby node
>
No silver bullets exist (yet). A couple of things I can recommend:
1. GitLab's experience of changing schema without downtime and maintaining
backward compatibility – they have open documentation and a lot of things
solved and documented
- start here:
https://docs.gitlab.com/ee/development/mig
My thoughts: https://twitter.com/samokhvalov/status/1403408281389789189.
Apologies for top-posting.
On Fri, Jun 11, 2021 at 10:04 AM Bruce Momjian wrote:
> On Thu, Jun 10, 2021 at 10:21:00PM +0200, Peter J. Holzer wrote:
> > > I wonder about the tolerance of the world we live in. Somehow, I can
Logical way – dump/restore.
Bringing PGDATA physically may lead to corrupted indexes due to glibc
version changes. 16.04 -> 18.04 shouldn't cause it, but it may. You can
check btree index with amcheck and GIN indexes with a patched version of it
(some backporting would be needed). You can find exa
aintenance window or just some of them (which ones – amcheck can help to
answer, for 9.5 it should be taken from here:
https://github.com/petergeoghegan/amcheck).
On Thu, Sep 2, 2021 at 11:17 AM Nikolay Samokhvalov
wrote:
> Logical way – dump/restore.
>
> Bringing PGDATA physically ma
On Tue, Feb 22, 2022 at 12:27 PM Torsten Förtsch
wrote:
> Hi,
>
> I have a few databases with several TB-sized tables. We recently moved one
> of those databases from AWS EC2 to GCP. Today I ran VACUUM FREEZE on those
> tables and every time I saw our application freezing up (and throwing tons
>
On Mon, Jan 29, 2018 at 3:06 PM, Jan De Moerloose wrote:
...
> SELECT pid, age(clock_timestamp(),query_start) as age, usename, query,
> state from pg_stat_activity order by age;
>
> When the cpu is 100% and the app slowing down, i can see that some queries
> have a long age.
>
What is the value
On Mon, Jan 29, 2018 at 3:19 PM, Jan De Moerloose wrote:
> The state is 'idle in transaction'.
>
So you have long-running *transactions*, not queries. This is not good for
an OLTP system, because some transaction can wait of others, which are
"idle in transaction" but do nothing at the moment. T
On Mon, Jan 29, 2018 at 3:45 PM, Jan De Moerloose wrote:
> So the query is just the latest query and the time is the transaction time
> since this query, i suppose ?
> Thanks for your answer, i will try to make the transaction shorter as you
> suggest.
>
Yep. This is a very common confusion, how
On Mon, Jan 29, 2018 at 9:52 PM, Nikolay Samokhvalov
wrote:
>
>
> On Mon, Jan 29, 2018 at 3:45 PM, Jan De Moerloose
> wrote:
>
>> So the query is just the latest query and the time is the transaction
>> time since this query, i suppose ?
>> Thanks for yo
25 matches
Mail list logo
