On Tue, Feb 19, 2019 at 5:16 PM James Sewell wrote:
>> Here's a starter patch that shows one of the approaches discussed. It
>> gets WSL users to a better place than they were before, by suppressing
>> further warnings after the first one.
>
> This wasn't quite right, updated to check erro for
> Here's a starter patch that shows one of the approaches discussed. It
> gets WSL users to a better place than they were before, by suppressing
> further warnings after the first one.
>
This wasn't quite right, updated to check erro for ENOSYS (not rc)
This compiles and stops the panic on WSL
> What do you mean by "not being included by #ifdef blocks"? The only
> guard in issue_xlog_fsync() is #ifdef HAVE_FDATASYNC, which ought to be
> independent of any includes? I can see how this'd go wrong if configure
> did *not* detect fdatasync, because then
>
And now this looks like it works
Hi,
On 2019-02-19 11:50:36 +1100, James Sewell wrote:
> >
> > Right, the first step would be for a WSL user to figure out what's
> > wrong with builds on the WSL and show us how to fix it; I heard
> > through the grapevine that if you try it, initdb doesn't work (it must
> > be something pretty
>
> Right, the first step would be for a WSL user to figure out what's
> wrong with builds on the WSL and show us how to fix it; I heard
> through the grapevine that if you try it, initdb doesn't work (it must
> be something pretty subtle in the configure phase or something like
> that, since the
On Tue, Feb 19, 2019 at 6:01 AM Andres Freund wrote:
> On 2019-02-18 10:33:50 -0500, Ravi Krishna wrote:
> > Are there any plans to support PG on WSL ? Just curious.
Hi Ravi,
I definitely want to fix this particular issue for 11.3.
> I think if somebody wanted to start investing efforts to
On 2/18/19 9:11 AM, Jitendra Loyal wrote:
I have gone through the documentation quite a number of times to
establish the understanding. However, I had been wondering about the
recursion in the case I put forth.
Is there a better way to handle this requirement? The point is that the
trigger
On 2/18/19 9:07 AM, Jitendra Loyal wrote:
I do understand that the statement level trigger will be executed once
before the operation. My point is.. if one does not know the rows, what
kind of use it can be put to. What is the use case? Like in after
triggers, one gets the rows in transition
Laurenz and Hellmuth, replying to both of you!
Thanks for the quick replies BTW!
Martín
On Mon, Feb 18, 2019 at 5:32 PM Hellmuth Vargas wrote:
>
> Hola Martin
>
> Pues si uno sigue la secuencia de la pagina de ayuda de PostgreSQL
>
> https://www.postgresql.org/docs/10/pgupgrade.html
>
> Usage
Hola Martin
Pues si uno sigue la secuencia de la pagina de ayuda de PostgreSQL
https://www.postgresql.org/docs/10/pgupgrade.html
Usage
(...)
7. Stop both servers
(...)
10. Upgrade Streaming Replication and Log-Shipping standby servers
(...)
12. Start the new server
*The new server can now be
Martín Fernández wrote:
> After reading the pg_upgrade documentation multiple times, it seems that
> after running pg_upgrade on the primary instance, we can't start it until we
> run rsync from the primary to the standby. I'm understanding this from the
> following section in the pg_upgrade
Hello everyone!
We are about to upgrade a 6 instance cluster from pg92 to pg10 using pg_upgrade
with hardlinks and rsync.
Our preliminary tests are working really good so far but on question has popped
up that we feel is really critical because it has an important impact on our
failover plan.
On Sun, 17 Feb 2019 at 20:06, Michael Paquier wrote:
> Now, the error message "channel binding not supported by this build"
> would show up by either the backend or the frontend if
> X509_get_signature_nid() is not present in the version of OpenSSL your
> version of libpq (for the frontend) or
> "Chuck" == Chuck Martin writes:
Chuck> I am trying to create a query that returns all transactions for
Chuck> each person who has a balance over a given amount. I thought
Chuck> HAVING was the answer, but if so, I'm mis-using it. This query
Chuck> returns only transactions exceeding
I am trying to create a query that returns all transactions for each person
who has a balance over a given amount. I thought HAVING was the answer, but
if so, I'm mis-using it. This query returns only transactions exceeding the
given amount rather than transactions for people whose balance is over
On 2019-02-18 10:33:50 -0500, Ravi Krishna wrote:
> Are there any plans to support PG on WSL ? Just curious.
I think if somebody wanted to start investing efforts to improve testing
of that setup, and then fix the resulting issues, nobody would seriously
object. But also most people working on
On 2/18/19 8:38 AM, Jitendra Loyal wrote:
Unfortunately no! Where can I see those? Will I don't my answer there; I
have referred to the documentation and tried various things.
Please do not top post. The style on this list is to use inline posting.
On 2/18/19 8:20 AM, Jitendra Loyal wrote:
Thanks Adrian
I am trying to understand as to how a BEFORE statement-level trigger can
be used. Since it is a trigger, one needs to know which rows are being
affected.
But you can't:
https://www.postgresql.org/docs/10/plpgsql-trigger.html
"NEW
On 2/18/19 8:23 AM, Jitendra Loyal wrote:
My bad!
It is a transition table. Consider the following revised definition of
trigger:
CREATE TRIGGER storage_locations_b_u_AS_DML
AFTER UPDATE
ON storage_locations
REFERENCING NEW TABLE AS new_table
OLD TABLE AS old_table
FOR EACH STATEMENT
On 2/18/19 4:06 AM, Jitendra Loyal wrote:
The behaviour is not clear for BEFORE Statement-level Trigger. This is
because transition tables cannot be used. So how does one get access to
the rows being affected? It is not documented either.
If you need the row values then use a FOR ROW trigger.
On 2/18/19 4:11 AM, Jitendra Loyal wrote:
The AFTER Statement-level Trigger runs into infinite execution when
another set of rows are affected for the same table through this
trigger. Consider this use case where a table storage_locations that
manages a hierarchy of storage_locations in
Are there any plans to support PG on WSL ? Just curious.
Sorry I don't have the exact message right now, but YES.
To be exact, drop table | schema pg_temp_XX... in single-user mode results
in "HINT: run vaccum"
On Tue, Feb 19, 2019 at 12:11 AM Arthur Zakirov
wrote:
> On 18.02.2019 17:18, Jahwan Kim wrote:
> > Thanks for the reply.
> >
> > (1) The
On 18.02.2019 17:18, Jahwan Kim wrote:
Thanks for the reply.
(1) The problem is, I cannot drop any of the temp tables, not even in
the single-user mode. It says
'vacuum', 'You might also need to commit or roll back old prepared
transactions.'
And, no, there seems to be no pending prepared
Thanks for the reply.
(1) The problem is, I cannot drop any of the temp tables, not even in the
single-user mode. It says
'vacuum', 'You might also need to commit or roll back old prepared
transactions.'
And, no, there seems to be no pending prepared transaction either.
Best,
Jahwan
On Mon, Feb
Hello,
On 18.02.2019 15:05, Jahwan Kim wrote:
So apparently I'm in some loop without any clear way out.
The most similar thing I found was "Could not finish anti-wraparound
VACUUM when stop limit is reached"
https://www.postgresql.org/message-id/53820ed9.3010...@vmware.com. This
is quite
The AFTER Statement-level Trigger runs into infinite execution when another
set of rows are affected for the same table through this trigger. Consider
this use case where a table storage_locations that manages a hierarchy of
storage_locations in stores, and thus having following columns (for
The behaviour is not clear for BEFORE Statement-level Trigger. This is because
transition tables cannot be used. So how does one get access to the rows
being affected? It is not documented either.
Thanks
Jiten
Hi,
I checked in pgAdmin and that turned out to be the problem. If i check with \d
the trigger is listed under "Triggers firing always:". And it
fires as expected. I was misled by the UI. So it seems like it is a UI problem
rather than in postgresql.
Thanks for your time.
KR /Mikael
Any help or hint would be greatly appreciated.
Version 9.5.10
* PostgreSQL stopped, saying it needs vacuum.
* Checked the tables' age, and the top rows are as follows:
table_name |age | table_size
++
On 18/2/19 1:09 μ.μ., Gustavsson Mikael wrote:
Hi,
I have a Postgresql 11 and Slony 2.2.7 setup with one master and multiple slave
nodes. On one of the slaves I want a user defined trigger to fire on insert.
The trigger fires a notify function.
Now to the problem.
If I create the trigger it
Hi,
I have a Postgresql 11 and Slony 2.2.7 setup with one master and multiple slave
nodes. On one of the slaves I want a user defined trigger to fire on insert.
The trigger fires a notify function.
Now to the problem.
If I create the trigger it looks like it is enabled on the slave but it do
Oh Wow, i guess you are right.
I just ran example where local runs make use of parallel setup, but not FDW.
i have three servers
2 x pg10
1 x pg11
i run queries on coordinator node ( pg11 ) which makes calls to foreign
server to do a simple count.
the individual nodes run the query in parallel,
> On 14 Oct 2018, at 23:10 , Andres Freund wrote:
>
> If you created the new basebackup using rsync, and didn't exclude
> pg_replication_slot, it'll have copied the slots from the primary. And
> thus needs a high enough max_replication_slots to work with them.
Thanks for pointing this out,
34 matches
Mail list logo
