473,687 Members | 3,423 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

after postgres upgrade - ERROR: current transaction is aborted

Hi,

I have had a site working for the last 2 years and have had no problems
until at the weekend I replace my database server with a newer one. The
database migration went like a dream and I had the whole db changed over
in 1 hour.

Since the upgrade I have been getting the following error message
sporadically.

ERROR: current transaction is aborted, queries ignored until end of
transaction block
I have the following setup

Webserver:
Apache 1.3.27 (Redhat 7.2)
PHP 4.1.2

Database server (old): Postgres 7.1.3
Database server (new): Postgres 7.3.4

The PHP scripts have not changed. I am using PEAR::DB for database
access. I think it is the PEAR::DB that is actually making the
transactions because some times the error message some times gets
generated when I don't even have a transaction. Not too sure about that
though.

The funny thing is, when I first start up the web-server I don't get any
error messages and the site carries on working fine just as it did when
using the old database server.

However, after about an hour. I suddenly get 10 errors a minute from my
site (average of course) with the majority of pages still accessing
fine. After a bit more time, this doubles to 20 errors a minute. If I
carry on leaving the site, I eventually get error messages every second.
The error message seem to be generated from completely unrelated bits of
my code.

When I restart Apache the error messages go away and the site functions
as normal.

My theory is, since I am using persistent connections in PHP, a
connection is some how becoming...unst able...for the want of a better
word. That connection then returns an error on every single request.

To put my theory to test, I have turned off the persistent connections
on my site and everything appears to be working fine now. I now need to
work out where to go from here as my server load is high and I would
prefer to use persistent connections.

Has anyone experienced any similar problems with changing Postgres
versions? Do I need to upgrade my PHP on the web-server as the RedHat
postgres the PHP was built against was Postgres 7.1.3? Anyone have any
suggestions on how I can fix this?

Regards,

--
Abdul-Wahid Paterson

Lintrix Networking & Comms. ltd. Web: http://www.lintrix.net/
Tel: +44 (0) 870 285 4703 Mobile: +44 (0)7971 506177
Fax: 0870 133 0433 Email/Jabber: aw@lintrix.net
--------------------------------------------------------------------
Web-Hosting | Development | Security | Consultancy | Domains
--------------------------------------------------------------------

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQA/ZgJeN5797utT3Yk RArYcAJ9s5nq+st PFu8xOfpMG6MZFJ rrl2gCgyy89
Zo2aa6EcytiS7Q/nm7EVB1M=
=gEOK
-----END PGP SIGNATURE-----

Nov 11 '05 #1
7 6654
While I would recommend you upgrade your php to be built against 7.3,
before that you can use one of the new 7.3 error messages to find out
where things are going awry. in your postgresql.conf set
log_min_error_s tatement = error. this will cause the offending sql
statement to be written to your logs, with this you can narrow down
where in your web code your problems are being created, and better
attack the problem at that point.

Robert Treat

On Mon, 2003-09-15 at 14:18, Abdul-Wahid Paterson wrote:
Hi,

I have had a site working for the last 2 years and have had no problems
until at the weekend I replace my database server with a newer one. The
database migration went like a dream and I had the whole db changed over
in 1 hour.

Since the upgrade I have been getting the following error message
sporadically.

ERROR: current transaction is aborted, queries ignored until end of
transaction block
I have the following setup

Webserver:
Apache 1.3.27 (Redhat 7.2)
PHP 4.1.2

Database server (old): Postgres 7.1.3
Database server (new): Postgres 7.3.4

The PHP scripts have not changed. I am using PEAR::DB for database
access. I think it is the PEAR::DB that is actually making the
transactions because some times the error message some times gets
generated when I don't even have a transaction. Not too sure about that
though.

The funny thing is, when I first start up the web-server I don't get any
error messages and the site carries on working fine just as it did when
using the old database server.

However, after about an hour. I suddenly get 10 errors a minute from my
site (average of course) with the majority of pages still accessing
fine. After a bit more time, this doubles to 20 errors a minute. If I
carry on leaving the site, I eventually get error messages every second.
The error message seem to be generated from completely unrelated bits of
my code.

When I restart Apache the error messages go away and the site functions
as normal.

My theory is, since I am using persistent connections in PHP, a
connection is some how becoming...unst able...for the want of a better
word. That connection then returns an error on every single request.

To put my theory to test, I have turned off the persistent connections
on my site and everything appears to be working fine now. I now need to
work out where to go from here as my server load is high and I would
prefer to use persistent connections.

Has anyone experienced any similar problems with changing Postgres
versions? Do I need to upgrade my PHP on the web-server as the RedHat
postgres the PHP was built against was Postgres 7.1.3? Anyone have any
suggestions on how I can fix this?

Regards,

--
Abdul-Wahid Paterson

Lintrix Networking & Comms. ltd. Web: http://www.lintrix.net/
Tel: +44 (0) 870 285 4703 Mobile: +44 (0)7971 506177
Fax: 0870 133 0433 Email/Jabber: aw@lintrix.net
--------------------------------------------------------------------
Web-Hosting | Development | Security | Consultancy | Domains
--------------------------------------------------------------------


--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faqs/FAQ.html

Nov 11 '05 #2
On Mon, 15 Sep 2003, Abdul-Wahid Paterson wrote:
I have had a site working for the last 2 years and have had no problems
until at the weekend I replace my database server with a newer one. The
database migration went like a dream and I had the whole db changed over
in 1 hour.

Since the upgrade I have been getting the following error message
sporadically.

ERROR: current transaction is aborted, queries ignored until end of
transaction block
[...]
To put my theory to test, I have turned off the persistent connections
on my site and everything appears to be working fine now. I now need to
work out where to go from here as my server load is high and I would
prefer to use persistent connections.


<crystal ball>
You made some error when importing the new database and now you have
some sequences with their counter not greater than the last sequence
number. So you get some insert errors within transactions, and then you
cannot issue any inserts or updates in that transaction until you do a
rollback.
</crystal ball>
--
PGP/GPG Key-ID:
http://blackhole.pca.dfn.de:11371/pk...rch=0xB5A1AFE1

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to ma*******@postg resql.org so that your
message can get through to the mailing list cleanly

Nov 11 '05 #3
I have kinda put my finger on the problem. It seems that a transaction
was crashing out somewhere in my code and a rollback was not being done
(I have not found the line of code yet) and the next PHP script to take
on the connection was therefore getting a message saying that the
current transaction was aborted.

I changed my PHP connection setting to not use persistent connections
and the problem was fixed. Although, that was not a good solution for me
as I have high sever load.

I then wrote a php shutdown function to always do a rollback at the end
of the script. I switched on the persistent connections again, and
everything was fine. Thus concluding that the problem was indeed a
failed transaction that had not been rollback. (At least this will be
good enough until I can sift through the thousands of lines of code
looking for transaction code that has a missing rollback).

The thing that still puzzles me is this: If you remember from my earlier
post, the only thing I have changed here is the database server (from
postgres 7.1.3 to 7.3.4). What I don't understand is why did 7.1.3 never
cause a problem with the failed transactions not being rolledback?
Postgres surely doesn't know that it is a new PHP script using the
connection as all Postgres knows about is the Apache HTTP process
holding the connection open. Can anyone shed some light on the
difference between version? Or perhaps there is something else in
Postgres configuration that would change the above behaviour.

Best regards,

Abdul-Wahid

On Mon, 2003-09-15 at 19:48, Robert Treat wrote:
While I would recommend you upgrade your php to be built against 7.3,
before that you can use one of the new 7.3 error messages to find out
where things are going awry. in your postgresql.conf set
log_min_error_s tatement = error. this will cause the offending sql
statement to be written to your logs, with this you can narrow down
where in your web code your problems are being created, and better
attack the problem at that point.

Robert Treat

On Mon, 2003-09-15 at 14:18, Abdul-Wahid Paterson wrote:
Hi,

I have had a site working for the last 2 years and have had no problems
until at the weekend I replace my database server with a newer one. The
database migration went like a dream and I had the whole db changed over
in 1 hour.

Since the upgrade I have been getting the following error message
sporadically.

ERROR: current transaction is aborted, queries ignored until end of
transaction block


I have the following setup

Webserver:
Apache 1.3.27 (Redhat 7.2)
PHP 4.1.2

Database server (old): Postgres 7.1.3
Database server (new): Postgres 7.3.4

The PHP scripts have not changed. I am using PEAR::DB for database
access. I think it is the PEAR::DB that is actually making the
transactions because some times the error message some times gets
generated when I don't even have a transaction. Not too sure about that
though.

The funny thing is, when I first start up the web-server I don't get any
error messages and the site carries on working fine just as it did when
using the old database server.

However, after about an hour. I suddenly get 10 errors a minute from my
site (average of course) with the majority of pages still accessing
fine. After a bit more time, this doubles to 20 errors a minute. If I
carry on leaving the site, I eventually get error messages every second.
The error message seem to be generated from completely unrelated bits of
my code.

When I restart Apache the error messages go away and the site functions
as normal.

My theory is, since I am using persistent connections in PHP, a
connection is some how becoming...unst able...for the want of a better
word. That connection then returns an error on every single request.

To put my theory to test, I have turned off the persistent connections
on my site and everything appears to be working fine now. I now need to
work out where to go from here as my server load is high and I would
prefer to use persistent connections.

Has anyone experienced any similar problems with changing Postgres
versions? Do I need to upgrade my PHP on the web-server as the RedHat
postgres the PHP was built against was Postgres 7.1.3? Anyone have any
suggestions on how I can fix this?

Regards,

--
Abdul-Wahid Paterson

Lintrix Networking & Comms. ltd. Web: http://www.lintrix.net/
Tel: +44 (0) 870 285 4703 Mobile: +44 (0)7971 506177
Fax: 0870 133 0433 Email/Jabber: aw@lintrix.net
--------------------------------------------------------------------
Web-Hosting | Development | Security | Consultancy | Domains
--------------------------------------------------------------------

--
Abdul-Wahid Paterson

Lintrix Networking & Comms. ltd. Web: http://www.lintrix.net/
Tel: +44 (0) 870 285 4703 Mobile: +44 (0)7971 506177
Fax: 0870 133 0433 Email/Jabber: aw@lintrix.net
--------------------------------------------------------------------
Web-Hosting | Development | Security | Consultancy | Domains
--------------------------------------------------------------------

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQA/Zzj3N5797utT3Yk RAq8DAJ9pveK3dv KkQ+rcuD2uveYFz j6V+ACgk4pG
vNMYnSg+KYVqc/xuN10h2DY=
=banI
-----END PGP SIGNATURE-----

Nov 11 '05 #4
my guess is that the query causing the error in 7.3 actually was valid
syntax in 7.1, so the query never errored out and the transaction never
had to be rolled back. quickest way to find out which query is to make
the mods to postgresql.conf i mentioned below and get it from your
server logs.

Robert Treat

On Tue, 2003-09-16 at 12:23, Abdul-Wahid Paterson wrote:
I have kinda put my finger on the problem. It seems that a transaction
was crashing out somewhere in my code and a rollback was not being done
(I have not found the line of code yet) and the next PHP script to take
on the connection was therefore getting a message saying that the
current transaction was aborted.

I changed my PHP connection setting to not use persistent connections
and the problem was fixed. Although, that was not a good solution for me
as I have high sever load.

I then wrote a php shutdown function to always do a rollback at the end
of the script. I switched on the persistent connections again, and
everything was fine. Thus concluding that the problem was indeed a
failed transaction that had not been rollback. (At least this will be
good enough until I can sift through the thousands of lines of code
looking for transaction code that has a missing rollback).

The thing that still puzzles me is this: If you remember from my earlier
post, the only thing I have changed here is the database server (from
postgres 7.1.3 to 7.3.4). What I don't understand is why did 7.1.3 never
cause a problem with the failed transactions not being rolledback?
Postgres surely doesn't know that it is a new PHP script using the
connection as all Postgres knows about is the Apache HTTP process
holding the connection open. Can anyone shed some light on the
difference between version? Or perhaps there is something else in
Postgres configuration that would change the above behaviour.

Best regards,

Abdul-Wahid

On Mon, 2003-09-15 at 19:48, Robert Treat wrote:
While I would recommend you upgrade your php to be built against 7.3,
before that you can use one of the new 7.3 error messages to find out
where things are going awry. in your postgresql.conf set
log_min_error_s tatement = error. this will cause the offending sql
statement to be written to your logs, with this you can narrow down
where in your web code your problems are being created, and better
attack the problem at that point.

Robert Treat

On Mon, 2003-09-15 at 14:18, Abdul-Wahid Paterson wrote:
Hi,

I have had a site working for the last 2 years and have had no problems until at the weekend I replace my database server with a newer one. The database migration went like a dream and I had the whole db changed over in 1 hour.

Since the upgrade I have been getting the following error message
sporadically.

ERROR: current transaction is aborted, queries ignored until end of
transaction block
I have the following setup

Webserver:
Apache 1.3.27 (Redhat 7.2)
PHP 4.1.2

Database server (old): Postgres 7.1.3
Database server (new): Postgres 7.3.4

The PHP scripts have not changed. I am using PEAR::DB for database
access. I think it is the PEAR::DB that is actually making the
transactions because some times the error message some times gets
generated when I don't even have a transaction. Not too sure about that though.

The funny thing is, when I first start up the web-server I don't get any error messages and the site carries on working fine just as it did when using the old database server.

However, after about an hour. I suddenly get 10 errors a minute from my site (average of course) with the majority of pages still accessing
fine. After a bit more time, this doubles to 20 errors a minute. If I carry on leaving the site, I eventually get error messages every second. The error message seem to be generated from completely unrelated bits of my code.

When I restart Apache the error messages go away and the site functions as normal.

My theory is, since I am using persistent connections in PHP, a
connection is some how becoming...unst able...for the want of a better word. That connection then returns an error on every single request.

To put my theory to test, I have turned off the persistent connections on my site and everything appears to be working fine now. I now need to work out where to go from here as my server load is high and I would
prefer to use persistent connections.

Has anyone experienced any similar problems with changing Postgres
versions? Do I need to upgrade my PHP on the web-server as the RedHat postgres the PHP was built against was Postgres 7.1.3? Anyone have any suggestions on how I can fix this?

--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faqs/FAQ.html

Nov 11 '05 #5
Abdul-Wahid Paterson <aw@lintrix.net > writes:
I have kinda put my finger on the problem. It seems that a transaction
was crashing out somewhere in my code and a rollback was not being done
(I have not found the line of code yet) and the next PHP script to take
on the connection was therefore getting a message saying that the
current transaction was aborted.
[snip]
The thing that still puzzles me is this: If you remember from my earlier
post, the only thing I have changed here is the database server (from
postgres 7.1.3 to 7.3.4). What I don't understand is why did 7.1.3 never
cause a problem with the failed transactions not being rolledback?


Most likely, the transaction didn't fail in the first place with 7.1 ---
ie, the failure is due to some version-to-version incompatibility
between 7.1 and 7.3. Check the 7.2 and 7.3 release notes for some
ideas what to look for.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

Nov 11 '05 #6
On 16 Sep 2003, Abdul-Wahid Paterson wrote:
I have kinda put my finger on the problem. It seems that a transaction
was crashing out somewhere in my code and a rollback was not being done
(I have not found the line of code yet) and the next PHP script to take
on the connection was therefore getting a message saying that the
current transaction was aborted.

...

The thing that still puzzles me is this: If you remember from my earlier
post, the only thing I have changed here is the database server (from
postgres 7.1.3 to 7.3.4). What I don't understand is why did 7.1.3 never
cause a problem with the failed transactions not being rolledback?
Were they failing before? I should imagine there's sufficient differences in
between 7.1.x and 7.3.x to start causing you problems if you've just blindly
assumed all queries will work exactly the same.
Postgres surely doesn't know that it is a new PHP script using the
connection as all Postgres knows about is the Apache HTTP process
holding the connection open. Can anyone shed some light on the
difference between version? Or perhaps there is something else in
Postgres configuration that would change the above behaviour.


Use the server logs to determine what query is failing. Simple thing is it to
start at the start of the log and the first error report you find should be
the, or at least a, problem. If not then obviously you'll have to scan the
errors until you find a query you don't expect to get an error.

--
Nigel Andrews
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to ma*******@postg resql.org

Nov 11 '05 #7
Abdul-Wahid Paterson wrote:
-- Start of PGP signed section.
I have kinda put my finger on the problem. It seems that a transaction
was crashing out somewhere in my code and a rollback was not being done
(I have not found the line of code yet) and the next PHP script to take
on the connection was therefore getting a message saying that the
current transaction was aborted.

I changed my PHP connection setting to not use persistent connections
and the problem was fixed. Although, that was not a good solution for me
as I have high sever load.


This problem of transactions staying around for another connection was
fixed in PHP, I thought. PHP5 also has a fix to RESET all GUC variables
for persistent connection, but I thought the transaction-reset code was
already in current PHP versions.

--
Bruce Momjian | http://candle.pha.pa.us
pg***@candle.ph a.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to ma*******@postg resql.org so that your
message can get through to the mailing list cleanly

Nov 11 '05 #8

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

0
2174
by: Adam Kempa | last post by:
Hello I've been installed Postgres 7.4.2 on FreeBSD system and when load average grow up i've error in postgres like this: ERROR: permission denied for function varchar ERROR: permission denied for function varchar and then postgres crashes. LOG: server process (PID 9787) was terminated by signal 11
0
1176
by: Vanchau Nguyen | last post by:
I have a very simple problem (I hope). Our master database ran out of connections and we had to restart the server (couldn't SSH into the box). Rebooting the server worked and of our clients resumed activity. The problem is that the slave didn't start automatically so I tried to do a START SLAVE; on it. This is the latest shown in the error log on the slave.
1
1818
by: Steve Wampler | last post by:
I just upgraded a system from RedHat 8.0 to RedHat 9.0, which also upgrades the version of PostgreSQL. However, I cannot run pgsql to restore the databases because I don't know a 'default' user with permission to run pgsql: postmaster successfully started LOG: database system was shut down at 2003-11-06 10:27:18 MST LOG: checkpoint record is at 0/80193C
0
1343
by: Andrei Ivanov | last post by:
Hello, it seems my postgresql data has somehow become corrupted (by a forced shutdown I think): psql template1 -U shadow Password: ERROR: nodeRead: did not find '}' at end of plan node Welcome to psql 7.3.4, the PostgreSQL interactive terminal. Type: \copyright for distribution terms
0
2650
by: Dirk Försterling | last post by:
Hi all, a few days ago, I upgraded from PostgreSQL 7.2.1 to 7.4, following the instructions in the INSTALL file, including dump and restore. All this worked fine without any error (message). Since then, I found lots of the following in the postmaster output: 2003-11-29 15:19:54 ERROR: large object 4838779 does not exist 2003-11-29 15:20:11 ERROR: large object 4838779 does not exist
1
1669
by: Dirk Försterling | last post by:
Hi, sorry for reposting, but it seems my message just hit nothing but air. If I posted to the wrong list or did something else wrong with the message, please let me know. I really want to know what's going on but still found nothing. I do not know when and where the statements are produced that lead to the error messages. It seems they were generated by postgres internally but I cannot see when and why. How can
13
3132
by: Christopher Cashell | last post by:
Yesterday, while attempting to access a database, I received errors saying that the database was innaccessible. After investigating a little, I found the following in the PostgreSQL log files: 2004-06-30 08:30:19 LOG: checkpoint process (PID 28423) was terminated by signal 11 2004-06-30 08:30:19 LOG: terminating any other active server processes 2004-06-30 08:30:19 WARNING: terminating connection because of crash of another...
0
1763
by: Paramveer.Singh | last post by:
Hi! I was looking into the postgres error handling mechanism, and the documentation states that the present mechanism is primitive. I quote "whenever the parser, planner/optimizer or executor decide that a statement cannot be processed any longer, the whole transaction gets aborted and the system jumps back into the main loop to get the next command from the client application." Also, it states " it is possible that the database...
2
8469
by: KR | last post by:
Hi, We are running a test upgrade form sql 2000 standard edition to sql 2005 developer edition. Followed through all the steps and specified the account(SA priveleges and currently used by the 2000 version) and is the local admin on the box for the services and the setup seemed to move fine, except for when it got to the point of installing database services - This is the error message that I got: MSSQLServer could not be started. ...
0
8590
marktang
by: marktang | last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However, people are often confused as to whether an ONU can Work As a Router. In this blog post, we’ll explore What is ONU, What Is Router, ONU & Router’s main usage, and What is the difference between ONU and Router. Let’s take a closer look ! Part I. Meaning of...
0
9066
Oralloy
by: Oralloy | last post by:
Hello folks, I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>". The problem is that using the GNU compilers, it seems that the internal comparison operator "<=>" tries to promote arguments from unsigned to signed. This is as boiled down as I can make it. Here is my compilation command: g++-12 -std=c++20 -Wnarrowing bit_field.cpp Here is the code in...
1
8779
by: Hystou | last post by:
Overview: Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows Update option using the Control Panel or Settings app; it automatically checks for updates and installs any it finds, whether you like it or not. For most users, this new feature is actually very convenient. If you want to control the update process,...
0
8783
tracyyun
by: tracyyun | last post by:
Dear forum friends, With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each protocol has its own unique characteristics and advantages, but as a user who is planning to build a smart home system, I am a bit confused by the choice of these technologies. I'm particularly interested in Zigbee because I've heard it does some...
0
7617
agi2029
by: agi2029 | last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing, and deployment—without human intervention. Imagine an AI that can take a project description, break it down, write the code, debug it, and then launch it, all on its own.... Now, this would greatly impact the work of software developers. The idea...
1
6450
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome a new presenter, Adolph Dupré who will be discussing some powerful techniques for using class modules. He will explain when you may want to use classes instead of User Defined Types (UDT). For example, to manage the data in unbound forms. Adolph will...
0
5806
by: conductexam | last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and then checking html paragraph one by one. At the time of converting from word file to html my equations which are in the word document file was convert into image. Globals.ThisAddIn.Application.ActiveDocument.Select();...
1
2960
by: 6302768590 | last post by:
Hai team i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated we have to send another system
2
2214
muto222
by: muto222 | last post by:
How can i add a mobile payment intergratation into php mysql website.

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.