Home > mailing lists

Thread: puzzling perl DBI vs psql problem

puzzling perl DBI vs psql problem

From

Susan Cassidy

Date:

13 March 2014, 22:18:59

I have a weird issue that I can't figure out.

If I run the exact same query through psql as through perl DBI, I get different results. I get far fewer results with DBI than through the psql command line.

Any ideas why that would be?

The query is:
    SELECT st.description, st.scene_thing_instance_id,
      st.scene_id, sc.description, st.scene_thing_id, s.description,
      st.position_x, st.position_y, st.position_z,
           CASE
            when (st.description = 'absolute root'::text) then 1
            when (st.description ilike 'root%') then 2
            else 3
           END as s1, s.shape_name_id, sn.shape_name
     from scene_thing_instances st
        left join scene_things s on st.scene_thing_id = s.scene_thing_id
        left join scenes sc on st.scene_id = sc.scene_id
        left outer join shape_names sn on s.shape_name_id = sn.shape_name_id

      order by s1, st.description

I get 14 rows back via psql, but I only get 5 rows back via DBI. It's very puzzling.

I copied and pasted the query from the program's log file, so I know I'm doing the exact same query. If it matters, I'm only seeing the rows with 'root' in them via DBI, which the CASE statement refers to.

Thanks,
Susan

Re: puzzling perl DBI vs psql problem

From

Tom Lane

Date:

13 March 2014, 22:25:44

Susan Cassidy <susan.cassidy@decisionsciencescorp.com> writes:
> I have a weird issue that I can't figure out.
> If I run the exact same query through psql as through perl DBI, I get
> different results.  I get far fewer results with DBI than through the psql
> command line.

Any possibility that the perl program is connecting to a different
database, with similar-but-not-identical data in it?

I've seen variants on that theme involving different users with different
search_path settings finding different-but-similarly-named tables in
different schemas of the same database.

            regards, tom lane

Re: puzzling perl DBI vs psql problem

From

john gale

Date:

13 March 2014, 22:32:45

On Mar 13, 2014, at 12:18 PM, Susan Cassidy <susan.cassidy@decisionsciencescorp.com> wrote:

> I copied and pasted the query from the program's log file, so I know I'm doing the exact same query.  If it matters,
I'monly seeing the rows with 'root' in them via DBI, which the CASE statement refers to.   


Try enabling full query logging on postgres to see what query is actually running both times.  %'  shouldn't resolve to
anythingin perl, but there could be other issues with misquoting the query. 

    ~ john

Re: puzzling perl DBI vs psql problem

From

Steve Atkins

Date:

13 March 2014, 22:46:38

On Mar 13, 2014, at 12:18 PM, Susan Cassidy <susan.cassidy@decisionsciencescorp.com> wrote:

> I have a weird issue that I can't figure out.
>
> If I run the exact same query through psql as through perl DBI, I get different results.  I get far fewer results
withDBI than through the psql command line. 
>
> Any ideas why that would be?
>
> The query is:
>     SELECT st.description, st.scene_thing_instance_id,
>       st.scene_id, sc.description, st.scene_thing_id, s.description,
>       st.position_x, st.position_y, st.position_z,
>            CASE
>             when (st.description = 'absolute root'::text) then 1
>             when (st.description ilike 'root%') then  2
>             else 3
>            END as s1, s.shape_name_id, sn.shape_name
>      from scene_thing_instances st
>         left join scene_things s on st.scene_thing_id = s.scene_thing_id
>         left join scenes sc on st.scene_id = sc.scene_id
>         left outer join shape_names sn on s.shape_name_id = sn.shape_name_id
>
>       order by  s1, st.description
>
> I get 14 rows back via psql, but I only get 5 rows back via DBI.  It's very puzzling.
>
> I copied and pasted the query from the program's log file, so I know I'm doing the exact same query.  If it matters,
I'monly seeing the rows with 'root' in them via DBI, which the CASE statement refers to.   

How are you quoting the string in perl, and are you running with use strict?

My first thought would be that you’re not running the query you think you are - logging it at the postgresql side will
letyou check that (or if that’s not possible, DBI’s trace methods can help). 

Cheers,
  Steve

Re: puzzling perl DBI vs psql problem

From

Susan Cassidy

Date:

13 March 2014, 23:21:00

Yes, I am running with use strict. The statement I pasted in is after perl quoting, being written out by the same perl program. I just take that statement and paste it into the psql window.

DBI->trace showed nothing out of the ordinary. It just shows the lines being fetched that I am seeing in the web program, not the lines I get from psql.

Another odd thing is that it is apparently not logging statements from Perl, only from psql. I don't know why. I thought I had it set up right to log to syslog. I've had good luck before with that on other installations.

Here are the log settings in postgresql.conf:

log_destination = 'syslog'              # Valid values are combinations of
                                        # stderr, csvlog, syslog, and eventlog,
                                        # depending on platform. csvlog
                                        # requires logging_collector to be on.
# This is used when logging to stderr:
logging_collector = on                  # Enable capturing of stderr and csvlog
#logging_collector = off                        # Enable capturing of stderr and csvlog
                                        # into log files. Required to be on for
                                        # csvlogs.
# These are only used if logging_collector is on:
log_directory = 'pg_log'                # directory where log files are written,
log_filename = 'postgresql-%a.log'      # log file name pattern,
#log_file_mode = 0600                   # creation mode for log files,
log_truncate_on_rotation = on           # If on, an existing log file with the
                                        # same name as the new log file will be
log_rotation_age = 1d                   # Automatic rotation of logfiles will
log_rotation_size = 0                   # Automatic rotation of logfiles will
                                        # happen after that much log output.
# These are relevant when logging to syslog:
syslog_facility = 'LOCAL0'
syslog_ident = 'postgres'
# This is only relevant when logging to eventlog (win32):
client_min_messages = log               # values in order of decreasing detail:
                                        #   log
log_min_messages = info         # values in order of decreasing detail:
#log_min_messages = warning             # values in order of decreasing detail:
                                        #   log
#log_min_error_statement = error        # values in order of decreasing detail:
                                        #   log
#log_min_duration_statement = -1        # -1 is disabled, 0 logs all statements
                                        # and their durations, > 0 logs only
#log_checkpoints = off
#log_connections = off
#log_disconnections = off
#log_duration = off
#log_error_verbosity = default          # terse, default, or verbose messages
#log_hostname = off
log_line_prefix = '%d %u %p %t '                        # special values:

Could it have something to do with permissions on /var/log/postgresql? It is writeable by root only. The perl program runs under apache.

Susan

On Thu, Mar 13, 2014 at 12:46 PM, Steve Atkins <steve@blighty.com> wrote:

On Mar 13, 2014, at 12:18 PM, Susan Cassidy <susan.cassidy@decisionsciencescorp.com> wrote:

> I have a weird issue that I can't figure out.
>
> If I run the exact same query through psql as through perl DBI, I get different results. I get far fewer results with DBI than through the psql command line.
>
> Any ideas why that would be?
>
> The query is:
> SELECT st.description, st.scene_thing_instance_id,
> st.scene_id, sc.description, st.scene_thing_id, s.description,
> st.position_x, st.position_y, st.position_z,
> CASE
> when (st.description = 'absolute root'::text) then 1
> when (st.description ilike 'root%') then 2
> else 3
> END as s1, s.shape_name_id, sn.shape_name
> from scene_thing_instances st
> left join scene_things s on st.scene_thing_id = s.scene_thing_id
> left join scenes sc on st.scene_id = sc.scene_id
> left outer join shape_names sn on s.shape_name_id = sn.shape_name_id
>
> order by s1, st.description
>
> I get 14 rows back via psql, but I only get 5 rows back via DBI. It's very puzzling.
>
> I copied and pasted the query from the program's log file, so I know I'm doing the exact same query. If it matters, I'm only seeing the rows with 'root' in them via DBI, which the CASE statement refers to.

How are you quoting the string in perl, and are you running with use strict?

My first thought would be that you’re not running the query you think you are - logging it at the postgresql side will let you check that (or if that’s not possible, DBI’s trace methods can help).

Cheers,
Steve

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: puzzling perl DBI vs psql problem

From

Susan Cassidy

Date:

13 March 2014, 23:25:56

No, I am connecting to the right database, as my log info shows. No duplicate table names, except in different databases. Those tables show all the data I expect, oddly enough, if I connect the perl program to that database. It is only this database that is giving me trouble. Which is another oddity. The identical test database is working fine. Only this database is giving me trouble. Naturally the "live" database is causing problems.

Susan

On Thu, Mar 13, 2014 at 12:25 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Susan Cassidy <susan.cassidy@decisionsciencescorp.com> writes:
> I have a weird issue that I can't figure out.
> If I run the exact same query through psql as through perl DBI, I get
> different results. I get far fewer results with DBI than through the psql
> command line.

Any possibility that the perl program is connecting to a different
database, with similar-but-not-identical data in it?

I've seen variants on that theme involving different users with different
search_path settings finding different-but-similarly-named tables in
different schemas of the same database.

regards, tom lane

Re: puzzling perl DBI vs psql problem

From

Steve Atkins

Date:

13 March 2014, 23:27:03

On Mar 13, 2014, at 1:20 PM, Susan Cassidy <susan.cassidy@decisionsciencescorp.com> wrote:

> Yes, I am running with use strict.  The statement I pasted in is after perl quoting, being written out by the same
perlprogram.  I just take that statement and paste it into the psql window. 
>
> DBI->trace showed nothing out of the ordinary.  It just shows the lines being fetched that I am seeing in the web
program,not the lines I get from psql. 
>
> Another odd thing is that it is apparently not logging statements from Perl, only from psql.  I don't know why.  I
thoughtI had it set up right to log to syslog.  I've had good luck before with that on other installations. 

That’s supports Tom’s theory that you’re not connecting to the database you think you are. There’s no difference from
thedatabase’s PoV between queries from psql and perl. 

Conceivably connecting as different users could change the result too, though it seems unlikely here.

> Here are the log settings in postgresql.conf:
>

[fairly normal settings deleted]

>
> Could it have something to do with permissions on /var/log/postgresql?  It is writeable by root only.  The perl
programruns under apache. 

No, that file is written by syslog, nothing to do with the client.

If the perl is running under apache, though, is it possible that it’s a long-running process that’s kept a transaction
openand is seeing old data? Bounce apache and see if anything changes. 

Cheers,
  Steve

Re: puzzling perl DBI vs psql problem

From

Rodrigo Gonzalez

Date:

13 March 2014, 23:27:12

On Thu, 13 Mar 2014 13:20:53 -0700
Susan Cassidy <susan.cassidy@decisionsciencescorp.com> wrote:

> Another odd thing is that it is apparently not logging statements from
> Perl, only from psql.  I don't know why.  I thought I had it set up
> right to log to syslog.  I've had good luck before with that on other
> installations.
>

I can bet that it is connecting to another database or server, check
your perl script configuration.

Best regards

Rodrigo Gonzalez

Re: puzzling perl DBI vs psql problem

From

Susan Cassidy

Date:

13 March 2014, 23:28:49

No, it is connecting to localhost, which is the same system I am running psql on.

Susan

On Thu, Mar 13, 2014 at 1:26 PM, Rodrigo Gonzalez <rjgonzale.lists@gmail.com> wrote:

On Thu, 13 Mar 2014 13:20:53 -0700
Susan Cassidy <susan.cassidy@decisionsciencescorp.com> wrote:

> Another odd thing is that it is apparently not logging statements from
> Perl, only from psql. I don't know why. I thought I had it set up
> right to log to syslog. I've had good luck before with that on other
> installations.
>

I can bet that it is connecting to another database or server, check
your perl script configuration.

Best regards

Rodrigo Gonzalez

Re: puzzling perl DBI vs psql problem

From

Rodrigo Gonzalez

Date:

13 March 2014, 23:34:38

On Thu, 13 Mar 2014 13:28:38 -0700
Susan Cassidy <susan.cassidy@decisionsciencescorp.com> wrote:

> No, it is connecting to localhost, which is the same system I am
> running psql on.
>
> Susan
>
Well, if one query is logged and the other one is not it means that it
is running against different servers (as far as I understand
logging)....

Maybe psql is connecting using one socket and perl using another one?
maybe you have 2 instances running?

Re: puzzling perl DBI vs psql problem

From

Susan Cassidy

Date:

13 March 2014, 23:44:54

No, I don't have 2 instances running. I default the port on the psql command line, and the perl program is using 5432, as normal.

Now, I'm discovering that syslog is no longer logging anything. I bounced it, but to no avail.

Susan

On Thu, Mar 13, 2014 at 1:34 PM, Rodrigo Gonzalez <rjgonzale.lists@gmail.com> wrote:

On Thu, 13 Mar 2014 13:28:38 -0700
Susan Cassidy <susan.cassidy@decisionsciencescorp.com> wrote:

> No, it is connecting to localhost, which is the same system I am
> running psql on.
>
> Susan
>
Well, if one query is logged and the other one is not it means that it
is running against different servers (as far as I understand
logging)....

Maybe psql is connecting using one socket and perl using another one?
maybe you have 2 instances running?

Re: puzzling perl DBI vs psql problem

From

Dennis Jenkins

Date:

13 March 2014, 23:54:04

1)
Run both "psql" and "perl" under "strace" and search the output for which sockets it connects to.

eg, strace -o /tmp/psql.log psql -Upgsql -dmydatabase -c"select version();"

2)

Add a query into your perl script to perform the following SQL and print the results:

select current_database();

select current_schema();
select inet_server_addr();
select current_user;
(and others, see http://www.postgresql.org/docs/9.3/static/functions-info.html for more functions)

Do the same from your "psql". Compare the output. Are you 110% sure that you are connecting to the same database, as the same user, and using the same schema?

On Thu, Mar 13, 2014 at 3:44 PM, Susan Cassidy <susan.cassidy@decisionsciencescorp.com> wrote:

No, I don't have 2 instances running. I default the port on the psql command line, and the perl program is using 5432, as normal.

Now, I'm discovering that syslog is no longer logging anything. I bounced it, but to no avail.

Susan

On Thu, Mar 13, 2014 at 1:34 PM, Rodrigo Gonzalez <rjgonzale.lists@gmail.com> wrote:
On Thu, 13 Mar 2014 13:28:38 -0700
Susan Cassidy <susan.cassidy@decisionsciencescorp.com> wrote:

> No, it is connecting to localhost, which is the same system I am
> running psql on.
>
> Susan
>
Well, if one query is logged and the other one is not it means that it
is running against different servers (as far as I understand
logging)....

Maybe psql is connecting using one socket and perl using another one?
maybe you have 2 instances running?

Re: puzzling perl DBI vs psql problem

From

Rodrigo Gonzalez

Date:

13 March 2014, 23:54:41

On Thu, 13 Mar 2014 13:44:48 -0700
Susan Cassidy <susan.cassidy@decisionsciencescorp.com> wrote:

> No, I don't have 2 instances running.  I default the port on the psql
> command line, and the perl program is using 5432, as normal.
>
> Now, I'm discovering that syslog is no longer logging anything.  I
> bounced it, but to no avail.

That is other problem....try changing pgsql to use stderr (or fix
syslog of course)...then check both queries again and see the
differences...

Other good point by other user is that maybe you are using persistent
connections from apache and it is using an old snapshot?

Re: puzzling perl DBI vs psql problem

From

Rob Sargent

Date:

13 March 2014, 23:55:37

On 03/13/2014 02:44 PM, Susan Cassidy wrote:

No, I don't have 2 instances running. I default the port on the psql command line, and the perl program is using 5432, as normal.

Now, I'm discovering that syslog is no longer logging anything. I bounced it, but to no avail.

Susan

On Thu, Mar 13, 2014 at 1:34 PM, Rodrigo Gonzalez <rjgonzale.lists@gmail.com> wrote:
On Thu, 13 Mar 2014 13:28:38 -0700
Susan Cassidy <susan.cassidy@decisionsciencescorp.com> wrote:

> No, it is connecting to localhost, which is the same system I am
> running psql on.
>
> Susan
>
Well, if one query is logged and the other one is not it means that it
is running against different servers (as far as I understand
logging)....

Maybe psql is connecting using one socket and perl using another one?
maybe you have 2 instances running?

I would like to see the output of

ps auxw | grep p

when each or both is running

Re: puzzling perl DBI vs psql problem

From

Susan Cassidy

Date:

14 March 2014, 00:23:37

The only one that comes out different is inet_server_addr, via the program, it comes out:
::1

whereas via psql it comes out empty.

Yes, I am 100% sure I am using the same schema (which I never specify, so I am using 'public') and the same user and database.

Susan

On Thu, Mar 13, 2014 at 1:53 PM, Dennis Jenkins <dennis.jenkins.75@gmail.com> wrote:

1)
Run both "psql" and "perl" under "strace" and search the output for which sockets it connects to.
eg, strace -o /tmp/psql.log psql -Upgsql -dmydatabase -c"select version();"

2)
Add a query into your perl script to perform the following SQL and print the results:

select current_database();
select current_schema();
select inet_server_addr();
select current_user;
(and others, see http://www.postgresql.org/docs/9.3/static/functions-info.html for more functions)
Do the same from your "psql". Compare the output. Are you 110% sure that you are connecting to the same database, as the same user, and using the same schema?

On Thu, Mar 13, 2014 at 3:44 PM, Susan Cassidy <susan.cassidy@decisionsciencescorp.com> wrote:
No, I don't have 2 instances running. I default the port on the psql command line, and the perl program is using 5432, as normal.

Now, I'm discovering that syslog is no longer logging anything. I bounced it, but to no avail.

Susan

On Thu, Mar 13, 2014 at 1:34 PM, Rodrigo Gonzalez <rjgonzale.lists@gmail.com> wrote:
On Thu, 13 Mar 2014 13:28:38 -0700
Susan Cassidy <susan.cassidy@decisionsciencescorp.com> wrote:

> No, it is connecting to localhost, which is the same system I am
> running psql on.
>
> Susan
>
Well, if one query is logged and the other one is not it means that it
is running against different servers (as far as I understand
logging)....

Maybe psql is connecting using one socket and perl using another one?
maybe you have 2 instances running?

Re: puzzling perl DBI vs psql problem

From

Rob Sargent

Date:

14 March 2014, 00:27:59

On 03/13/2014 03:23 PM, Susan Cassidy wrote:
> The only one that comes out different is inet_server_addr,  via the
> program, it comes out:
> ::1
> whereas via psql it comes out empty.
>
> Yes, I am 100% sure I am using the same schema (which I never specify,
> so I am using 'public') and the same user and database.
>
> Susan
>
>
>
Unless username is also a schema name, then you're in that schema.

Re: puzzling perl DBI vs psql problem

From

Susan Cassidy

Date:

14 March 2014, 00:28:29

You asked for it (by the way, just p is asking for a lot of output):

root        23 0.0 0.0      0     0 ?        S    Feb20   0:00 [cgroup]
root        24 0.0 0.0      0     0 ?        S    Feb20   0:00 [khelper]
root        27 0.0 0.0      0     0 ?        S    Feb20   0:00 [pm]
root        28 0.0 0.0      0     0 ?        S    Feb20   0:05 [sync_supers]
root        38 0.0 0.0      0     0 ?        S    Feb20   0:00 [kacpid]
root        39 0.0 0.0      0     0 ?        S    Feb20   0:00 [kacpi_notify]
root        40 0.0 0.0      0     0 ?        S    Feb20   0:00 [kacpi_hotplug]
root        46 0.0 0.0      0     0 ?        S    Feb20   0:00 [ksuspend_usbd]
root        59 0.0 0.0      0     0 ?        S    Feb20   0:21 [kswapd0]
root        61 0.0 0.0      0     0 ?        SN   Feb20   1:26 [khugepaged]
root        66 0.0 0.0      0     0 ?        S    Feb20   0:00 [crypto/0]
root        67 0.0 0.0      0     0 ?        S    Feb20   0:00 [crypto/1]
root        68 0.0 0.0      0     0 ?        S    Feb20   0:00 [crypto/2]
root        69 0.0 0.0      0     0 ?        S    Feb20   0:00 [crypto/3]
root        79 0.0 0.0      0     0 ?        S    Feb20   0:00 [kpsmoused]
root       111 0.0 0.0      0     0 ?        S    Feb20   0:00 [kstriped]
root       447 0.0 0.0      0     0 ?        S    Feb20   0:10 [kcryptd_io]
root       448 0.0 0.0      0     0 ?        S    Feb20   8:03 [kcryptd]
rpc       1985 0.0 0.0 18976   336 ?        Ss   Feb20   0:01 rpcbind
root      2000 0.0 0.0 192216 1508 ?        S    Feb20   0:14 /usr/libexec/sssd/sssd_pam --debug-to-files
root      2003 0.0 0.0 210388   632 ?        S    Feb20   0:10 /usr/libexec/sssd/sssd_pac --debug-to-files
root      3794 0.0 0.0 92400 3396 ?        Ssl Feb20   0:03 NetworkManager --pid-file=/var/run/NetworkManager/NetworkManager.pid
rpcuser   3815 0.0 0.0 25424   320 ?        Ss   Feb20   0:00 rpc.statd
root      3830 0.0 0.0   9120   664 ?        S    Feb20   0:17 /sbin/dhclient -d -4 -sf /usr/libexec/nm-dhcp-client.action -pf /var/run/dhclient-eth0.pid -lf /var/lib/dhclient/dhclient-90769195-b652-4a56-b37d-60b98c4c86d5-eth0.lease -cf /var/run/nm-dhclient-eth0.conf eth0
root      3837 0.0 0.0 44972   192 ?        Ss   Feb20   0:00 /usr/sbin/wpa_supplicant -c /etc/wpa_supplicant/wpa_supplicant.conf -B -u -f /var/log/wpa_supplicant.log -P /var/run/wpa_supplicant.pid
root      3855 0.0 0.0      0     0 ?        S    Feb20   0:00 [rpciod/0]
root      3856 0.0 0.0      0     0 ?        S    Feb20   0:00 [rpciod/1]
root      3857 0.0 0.0      0     0 ?        S    Feb20   0:00 [rpciod/2]
root      3858 0.0 0.0      0     0 ?        S    Feb20   0:00 [rpciod/3]
root      3862 0.0 0.0 25164   208 ?        Ss   Feb20   0:00 rpc.idmapd
root      3877 0.0 0.0 200440 1844 ?        Ss   Feb20   0:05 cupsd -C /etc/cups/cupsd.conf
root      3907 0.0 0.0   4080   192 ?        Ss   Feb20   0:00 /usr/sbin/acpid
root      3963 0.0 0.0 22448   448 ?        S    Feb20   0:22 hald-addon-input: Listening on /dev/input/event4 /dev/input/event0 /dev/input/event1 /dev/input/event5
68        3966 0.0 0.0 17936   272 ?        S    Feb20   0:00 hald-addon-acpi: listening on acpid socket /var/run/acpid.socket
ntp       4021 0.0 0.0 32520   668 ?        Ss   Feb20   0:57 ntpd -x -u ntp:ntp -p /var/run/ntpd.pid
root      4102 0.0 0.0 83312   440 ?        Ss   Feb20   0:04 /usr/libexec/postfix/master
postfix   4123 0.0 0.0 83564   404 ?        S    Feb20   0:00 qmgr -l -t fifo -u
root      4146 0.0 0.0 23032   120 ?        Ss   Feb20   0:00 /usr/sbin/oddjobd -p /var/run/oddjobd.pid -t 300
root      4161 0.0 0.0 62296   592 ?        Ss   Feb20   0:01 /usr/sbin/certmonger -S -p /var/run/certmonger.pid
root      4337 0.0 0.0 49876   992 ?        S    Feb20   0:00 /usr/libexec/devkit-power-daemon
root      4378 0.0 0.0 195196 1908 ?        S    Feb20   0:01 /usr/libexec/polkit-1/polkitd
root      4560 0.0 0.0 45108   248 ?        S    Feb20   0:00 udisks-daemon: not polling any devices
scassidy 4651 0.0 0.0 73044 4128 pts/4    S+   Mar12   0:00 ssh mrhankey
pwalters 4774 0.0 0.0 804604   640 ?        Sl   Feb20   0:00 /usr/libexec/e-calendar-factory
root      4825 0.0 0.0 173480   648 ?        Sl   Feb20   0:00 /usr/libexec/gdm-simple-slave --display-id /org/gnome/DisplayManager/Display1
root      4827 2.5 2.7 625704 220620 tty7    Ss+ Feb20 787:34 /usr/bin/Xorg :0 -br -verbose -audit 4 -auth /var/run/gdm/auth-for-gdm-YFiIyA/database -nolisten tcp
root      4883 0.0 0.0 204840   556 ?        Sl   Feb20   0:00 pam: gdm-password
scassidy 4912 0.0 0.0 31028 1476 ?        Ss   Feb20   0:02 /bin/dbus-daemon --fork --print-pid 6 --print-address 8 --session
scassidy 5022 0.1 0.0 450860 3912 ?        S<sl Feb20 33:13 /usr/bin/pulseaudio --start --log-target=syslog
scassidy 5023 0.0 0.1 358976 11188 ?        S    Feb20   0:57 gnome-panel
scassidy 5026 0.0 0.0 103908   540 ?        S    Feb20   0:00 /usr/libexec/pulse/gconf-helper
scassidy 5029 0.0 0.0 574056   556 ?        Ssl Feb20   0:00 /usr/libexec/bonobo-activation-server --ac-activate --ior-output-fd=19
scassidy 5033 0.0 0.0 480540 5500 ?        Sl   Feb20   0:03 gpk-update-icon
scassidy 5042 0.0 0.0 272168 1548 ?        S    Feb20   0:00 bluetooth-applet
scassidy 5044 0.0 0.0 299372 2128 ?        Sl   Feb20   0:00 /usr/libexec/polkit-gnome-authentication-agent-1
scassidy 5046 0.0 0.1 366600 10348 ?        S    Feb20   3:13 /usr/libexec/wnck-applet --oaf-activate-iid=OAFIID:GNOME_Wncklet_Factory --oaf-ior-fd=19
scassidy 5051 0.0 0.0 497364 7948 ?        Sl   Feb20   0:33 /usr/libexec/clock-applet --oaf-activate-iid=OAFIID:GNOME_ClockApplet_Factory --oaf-ior-fd=25
scassidy 5052 0.0 0.0 326924 3112 ?        S    Feb20   0:00 /usr/libexec/trashapplet --oaf-activate-iid=OAFIID:GNOME_Panel_TrashApplet_Factory --oaf-ior-fd=29
scassidy 5053 0.0 0.0 379868 3012 ?        S    Feb20   0:00 gnome-volume-control-applet
scassidy 5056 0.0 0.1 395228 14532 ?        S    Feb20   0:00 python /usr/share/system-config-printer/applet.py
scassidy 5072 0.0 0.0 150956   804 ?        S    Feb20   0:00 /usr/libexec/gvfs-gphoto2-volume-monitor
scassidy 5081 0.0 0.0 266644 3148 ?        S    Feb20   0:20 gnome-power-manager
scassidy 5085 0.0 0.0 320628 4008 ?        S    Feb20   0:00 nm-applet --sm-disable
scassidy 5154 0.0 0.0 152788   876 ?        S    Feb20   0:00 /usr/libexec/gvfsd-trash --spawner :1.7 /org/gtk/gvfs/exec_spaw/0
scassidy 5250 0.0 0.0 119368 2088 pts/12   Ss+ Mar12   0:00 bash
scassidy 5269 0.0 0.0 417616 4328 ?        S    Feb20   0:00 /usr/bin/gnote --panel-applet --oaf-activate-iid=OAFIID:GnoteApplet_Factory --oaf-ior-fd=25
scassidy 5274 0.0 0.0 299808 3328 ?        S    Feb20   0:00 /usr/libexec/notification-area-applet --oaf-activate-iid=OAFIID:GNOME_NotificationAreaApplet_Factory --oaf-ior-fd=28
scassidy 5276 0.0 0.0 404212 5784 ?        S    Feb20   0:00 /usr/libexec/gdm-user-switch-applet --oaf-activate-iid=OAFIID:GNOME_FastUserSwitchApplet_Factory --oaf-ior-fd=34
scassidy 5286 0.0 0.0 146028   572 ?        S    Feb20   0:00 /usr/libexec/gvfsd-burn --spawner :1.7 /org/gtk/gvfs/exec_spaw/1
scassidy 5386 2.3 4.0 1319732 325320 ?      Sl   Feb20 732:01 /usr/lib64/firefox/plugin-container /usr/lib64/flash-plugin/libflashplayer.so -greomni /usr/lib64/firefox/omni.ja -appomni /usr/lib64/firefox/browser/omni.ja -appdir /usr/lib64/firefox/browser 5296 plugin
scassidy 5526 0.0 0.0 305184   476 ?        Sl   Feb20   0:03 /usr/lib64/libreoffice/program/oosplash.bin --writer
scassidy 5537 0.5 2.6 1853460 211660 ?      Sl   Feb20 168:35 /usr/lib64/libreoffice/program/soffice.bin --writer --splash-pipe=8
scassidy 5635 0.0 0.0 19116   404 ?        S    Feb20   0:00 gnome-pty-helper
scassidy 5659 0.0 0.0 119500 1560 pts/1    Ss   Feb20   0:01 bash
root      6783 0.0 0.0 184244 3908 ?        Ss   Feb20   0:35 /usr/sbin/httpd -k start
scassidy 8660 0.0 0.0 119512 1428 pts/4    Ss   Feb20   0:01 bash
scassidy 9102 0.0 0.0 175528   776 ?        S    Feb21   0:00 /usr/libexec/gvfsd-http --spawner :1.7 /org/gtk/gvfs/exec_spaw/2
scassidy 9382 0.0 0.0 119368 1428 pts/2    Ss   Feb20   0:01 bash
root     15343 0.0 0.0 385700 2748 ?        Ssl Feb27   0:06 automount --pid-file /var/run/autofs.pid
root     16881 0.1 19.9 1835136 1599724 ?     Ssl Feb27 26:28 /usr/sbin/glusterfs --volfile-id=/export_volume --volfile-server=hgluster01 /export/
scassidy 23006 0.0 0.0 233184   864 ?        S    Feb25   0:00 /usr/libexec/gvfsd-network --spawner :1.7 /org/gtk/gvfs/exec_spaw/3
scassidy 23012 0.0 0.0 154504 1060 ?        S    Feb25   0:00 /usr/libexec/gvfsd-dnssd --spawner :1.7 /org/gtk/gvfs/exec_spaw/5
postfix 23902 0.0 0.0 83392 3408 ?        S    12:53   0:00 pickup -l -t fifo -u
root     24570 0.0 0.0 183556 1448 ?        Sl   13:34   0:00 /sbin/rsyslogd -i /var/run/syslogd.pid -c 5
postgres 24666 0.0 0.0 127728 5764 pts/2    S    13:38   0:00 /usr/local/pgsql/bin/postgres
postgres 24667 0.0 0.0 111356   684 ?        Ss   13:38   0:00 postgres: logger process
postgres 24669 0.0 0.0 127728   976 ?        Ss   13:38   0:00 postgres: checkpointer process
postgres 24670 0.0 0.0 127728 1024 ?        Ss   13:38   0:00 postgres: writer process
postgres 24671 0.0 0.0 127728   932 ?        Ss   13:38   0:00 postgres: wal writer process
postgres 24672 0.0 0.0 129024 2544 ?        Ss   13:38   0:00 postgres: autovacuum launcher process
postgres 24673 0.0 0.0 113904 1260 ?        Ss   13:38   0:00 postgres: stats collector process
apache   24831 0.0 0.0 186452 2864 ?        S    13:46   0:00 /usr/sbin/httpd -k start
apache   24832 0.0 0.0 186452 3436 ?        S    13:46   0:00 /usr/sbin/httpd -k start
apache   24833 0.0 0.0 186452 3384 ?        S    13:46   0:00 /usr/sbin/httpd -k start
apache   24834 0.0 0.0 186452 3400 ?        S    13:46   0:00 /usr/sbin/httpd -k start
apache   24835 0.0 0.0 186452 3424 ?        S    13:46   0:00 /usr/sbin/httpd -k start
apache   24836 0.0 0.0 186452 3376 ?        S    13:46   0:00 /usr/sbin/httpd -k start
apache   24837 0.0 0.0 186452 3376 ?        S    13:46   0:00 /usr/sbin/httpd -k start
apache   24838 0.0 0.0 186452 3404 ?        S    13:46   0:00 /usr/sbin/httpd -k start
scassidy 24981 0.0 0.0 152556 3840 pts/1    S+   13:57   0:00 vim examplepgm2.pl
scassidy 25341 0.0 0.0 121136 1264 pts/2    R+   14:25   0:00 ps auxww
scassidy 25342 0.0 0.0 103256   848 pts/2    S+   14:25   0:00 grep p
scassidy 25359 0.2 9.3 5131544 751304 ?      Sl   Mar05 32:19 /usr/lib/jvm/jdk1.7.0_45/jre/bin/java -Xmx2352M -XX:PermSize=60M -XX:MaxPermSize=200M -DLOCALCONFIG=true -splash:data/splash.gif -Duser.language=en -Xss1024K -Xbootclasspath/p:lib/xalan.jar -Dlauncher.properties.file=/home/scassidy/MagicDraw UML/bin/magicdraw.properties -DMAIN_CLASS=com.nomagic.magicdraw.Main -cp lib/patch.jar:lib/md.jar:lib/md_api.jar:lib/md_common.jar:lib/md_common_api.jar:lib/md_foundation_1.0.jar:lib/tw_common.jar:lib/tw_common_api.jar:lib/launcher.jar:lib/activation.jar:lib/annotation.jar:lib/batik.jar:lib/cmof14.jar:lib/com.nomagic.ci.binary_17.0.1.jar:lib/com.nomagic.ci.metamodel.index_17.0.1.jar:lib/com.nomagic.ci.metamodel.project_17.0.1.jar:lib/com.nomagic.ci.persistence.local_17.0.1.jar:lib/com.nomagic.ci.persistence_17.0.1.jar:lib/com.nomagic.ci.services_17.0.1.jar:lib/com.nomagic.ci_17.0.1.jar:lib/commons-codec-1.3.jar:lib/commons-compress-1.3.jar:lib/commons-httpclient-3.1.jar:lib/commons-logging-1.0.4.jar:lib/concurrent.jar:lib/cvsclient.jar:lib/EccpressoAll.jar:lib/ehcache-core-2.2.0.jar:lib/flexlm.jar:lib/graphics/clibwrapper_jiio.jar:lib/graphics/freehep-base.jar:lib/graphics/freehep-graphics2d.jar:lib/graphics/freehep-graphicsio-emf.jar:lib/graphics/freehep-graphicsio-ps.jar:lib/graphics/freehep-graphicsio.jar:lib/graphics/jai_imageio.jar:lib/gson-2.2.4.jar:lib/HTMLEditorLight.jar:lib/javassist.jar:lib/javax_jmi-1_0-fr.jar:lib/jaxb-impl.jar:lib/jaxb-libs.jar:lib/jboss-aop-client.jar:lib/jboss-aspect-jdk50-client.jar:lib/jboss-common-core.jar:lib/jboss-ejb3-common-client.jar:lib/jboss-ejb3-core-client.jar:lib/jboss-ejb3-ext-api.jar:lib/jboss-ejb3-proxy-client.jar:lib/jboss-ejb3-security-client.jar:lib/jboss-integration.jar:lib/jboss-javaee.jar:lib/jboss-logging-spi.jar:lib/jboss-mdr.jar:lib/jboss-messaging-client.jar:lib/jboss-remoting.jar:lib/jboss-security-spi.jar:lib/jboss-serialization.jar:lib/jbossall-client.jar:lib/jbosscx-client.jar:lib/jbosssx-as-client.jar:lib/jbosssx-client.jar:lib/jbosssx.jar:lib/jhall.jar:lib/jide-action.jar:lib/jide-charts.jar:lib/jide-common.jar:lib/jide-components.jar:lib/jide-dock.jar:lib/jide-editor.jar:lib/jide-gantt.jar:lib/jide-grids.jar:lib/jide-properties.jar:lib/jide-shortcut.jar:lib/jimi.jar:lib/jmyspell-core-1.0.0-beta-2.jar:lib/jna.jar:lib/jnp-client.jar:lib/junit.jar:lib/log4j-1.2.15.jar:lib/lpg.runtime.java_2.0.17.v201004271640.jar:lib/namespace.jar:lib/org.apache.commons.codec_1.3.0.v201101211617.jar:lib/org.apache.commons.collections_3.2.0.v201005080500.jar:lib/org.apache.commons.logging_1.1.1.v201101211721.jar:lib/org.eclipse.core.contenttype_3.4.100.v20110423-0524.jar:lib/org.eclipse.core.jobs_3.5.100.v20110404.jar:lib/org.eclipse.core.runtime_3.7.0.v20110110.jar:lib/org.eclipse.emf.common_2.7.0.v20110513-1719.jar:lib/org.eclipse.emf.ecore.change_2.7.0.v20110408-2116.jar:lib/org.eclipse.emf.ecore.xmi_2.7.0.v20110411-2239.jar:lib/org.eclipse.emf.ecore_2.7.0.v20110513-1719.jar:lib/org.eclipse.emf.transaction_1.4.0.v20100331-1738.jar:lib/org.eclipse.equinox.common_3.6.0.v20110506.jar:lib/org.eclipse.equinox.registry_3.5.100.v20110502.jar:lib/org.eclipse.ocl.doc_3.0.1.R30x_v201008311245.jar:lib/org.eclipse.ocl.ecore.edit.source_3.0.0.R30x_v201008251030.jar:lib/org.eclipse.ocl.ecore.edit_3.0.0.R30x_v201008251030.jar:lib/org.eclipse.ocl.ecore.source_3.0.1.R30x_v201008251030.jar:lib/org.eclipse.ocl.ecore_3.0.1.R30x_v201008251030.jar:lib/org.eclipse.ocl.source_3.0.1.R30x_v201008251030.jar:lib/org.eclipse.ocl_3.0.1.R30x_v201008251030.jar:lib/org.eclipse.osgi_3.7.0.v20110513.jar:lib/org.eclipse.uml2.common_1.5.0.v200905041045.jar:lib/relaxngDatatype.jar:lib/slf4j-api-1.5.11.jar:lib/slf4j-jdk14-1.5.11.jar:lib/trove.jar:lib/truezip-driver-zip-7.4.3.jar:lib/truezip-kernel-7.4.3.jar:lib/uml2.jar:lib/webservice/axis-config.jar:lib/webservice/axis.jar:lib/webservice/commons-discovery-0.2.jar:lib/webservice/jaxrpc.jar:lib/webservice/mdserviceclient.jar:lib/webservice/rsclient.jar:lib/webservice/saaj.jar:lib/webservice/wsdl4j-1.5.1.jar:lib/xalan.jar:lib/xsdlib.jar:lib/y.jar com.nomagic.launcher.Launcher

When the perl program is running (I put a sleep statement in it so I could see what was happening), the only differences are:

diff tempout tempout2
46c46
< root      4827 2.5 2.7 625704 220620 tty7    Ss+ Feb20 787:34 /usr/bin/Xorg :0 -br -verbose -audit 4 -auth /var/run/gdm/auth-for-gdm-YFiIyA/database -nolisten tcp
---
> root      4827 2.5 2.7 625704 220620 tty7    Ss+ Feb20 787:35 /usr/bin/Xorg :0 -br -verbose -audit 4 -auth /var/run/gdm/auth-for-gdm-YFiIyA/database -nolisten tcp
70c70
< scassidy 5386 2.3 4.0 1319732 325320 ?      Sl   Feb20 732:01 /usr/lib64/firefox/plugin-container /usr/lib64/flash-plugin/libflashplayer.so -greomni /usr/lib64/firefox/omni.ja -appomni /usr/lib64/firefox/browser/omni.ja -appdir /usr/lib64/firefox/browser 5296 plugin
---
> scassidy 5386 2.3 4.0 1319732 325360 ?      Sl   Feb20 732:01 /usr/lib64/firefox/plugin-container /usr/lib64/flash-plugin/libflashplayer.so -greomni /usr/lib64/firefox/omni.ja -appomni /usr/lib64/firefox/browser/omni.ja -appdir /usr/lib64/firefox/browser 5296 plugin
92,93c92,93
< apache   24831 0.0 0.0 186452 2864 ?        S    13:46   0:00 /usr/sbin/httpd -k start
< apache   24832 0.0 0.0 186452 3436 ?        S    13:46   0:00 /usr/sbin/httpd -k start
---
> apache   24831 0.0 0.0 186452 3380 ?        S    13:46   0:00 /usr/sbin/httpd -k start
> apache   24832 0.0 0.0 186452 3440 ?        S    13:46   0:00 /usr/sbin/httpd -k start
96,99c96,99
< apache   24835 0.0 0.0 186452 3424 ?        S    13:46   0:00 /usr/sbin/httpd -k start
< apache   24836 0.0 0.0 186452 3376 ?        S    13:46   0:00 /usr/sbin/httpd -k start
< apache   24837 0.0 0.0 186452 3376 ?        S    13:46   0:00 /usr/sbin/httpd -k start
< apache   24838 0.0 0.0 186452 3404 ?        S    13:46   0:00 /usr/sbin/httpd -k start
---
> apache   24835 0.0 0.0 186452 3428 ?        S    13:46   0:00 /usr/sbin/httpd -k start
> apache   24836 0.0 0.0 186452 3440 ?        S    13:46   0:00 /usr/sbin/httpd -k start
> apache   24837 0.0 0.0 186452 3380 ?        S    13:46   0:00 /usr/sbin/httpd -k start
> apache   24838 0.0 0.0 186452 3424 ?        S    13:46   0:00 /usr/sbin/httpd -k start
101,102c101,103
< scassidy 25341 0.0 0.0 121136 1264 pts/2    R+   14:25   0:00 ps auxww
< scassidy 25342 0.0 0.0 103256   848 pts/2    S+   14:25   0:00 grep p
---
> apache   25355 1.2 0.1 99808 13400 ?        S    14:25   0:00 /usr/bin/perl /var/www/cgi-bin/examplepgm.pl
> postgres 25356 0.0 0.0 129240 5440 ?        Ss   14:25   0:00 postgres: testuser scan_run_db ::1(42097) idle
> scassidy 25358 0.0 0.0 121128 1252 pts/2    R+   14:25   0:00 ps auxww
103a105
> scassidy 25360 0.0 0.0 103256   856 pts/2    S+   14:25   0:00 grep p

Susan

On Thu, Mar 13, 2014 at 1:55 PM, Rob Sargent <robjsargent@gmail.com> wrote:

On 03/13/2014 02:44 PM, Susan Cassidy wrote:
No, I don't have 2 instances running. I default the port on the psql command line, and the perl program is using 5432, as normal.

Now, I'm discovering that syslog is no longer logging anything. I bounced it, but to no avail.

Susan

On Thu, Mar 13, 2014 at 1:34 PM, Rodrigo Gonzalez <rjgonzale.lists@gmail.com> wrote:
On Thu, 13 Mar 2014 13:28:38 -0700
Susan Cassidy <susan.cassidy@decisionsciencescorp.com> wrote:

> No, it is connecting to localhost, which is the same system I am
> running psql on.
>
> Susan
>
Well, if one query is logged and the other one is not it means that it
is running against different servers (as far as I understand
logging)....

Maybe psql is connecting using one socket and perl using another one?
maybe you have 2 instances running?

I would like to see the output of
ps auxw | grep p
when each or both is running

Re: puzzling perl DBI vs psql problem

From

Susan Cassidy

Date:

14 March 2014, 00:46:51

I finally figured it out, after changing my code to output the lines per the number of rows of output, instead of until data[0] was blank. It turned out that data[0] was sometimes blank, and I forgot about that, and was stopping the output after I got back an empty record (or so I thought).

So, all my fault.

The syslog thing I fixed by changing log_min_duration to 0, instead of letting it default. I don't think this used to be the default (to not log any statements).

Thanks for all the ideas, anyway, folks.

Thanks again,
Susan

On Thu, Mar 13, 2014 at 2:27 PM, Rob Sargent <robjsargent@gmail.com> wrote:

On 03/13/2014 03:23 PM, Susan Cassidy wrote:
The only one that comes out different is inet_server_addr, via the program, it comes out:
::1
whereas via psql it comes out empty.

Yes, I am 100% sure I am using the same schema (which I never specify, so I am using 'public') and the same user and database.

Susan

Unless username is also a schema name, then you're in that schema.

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: puzzling perl DBI vs psql problem

From

MOLINA BRAVO FELIPE DE JESUS

Date:

14 March 2014, 17:00:24

De: pgsql-general-owner@postgresql.org [pgsql-general-owner@postgresql.org] en nombre de Susan Cassidy
[susan.cassidy@decisionsciencescorp.com]
Enviado: jueves, 13 de marzo de 2014 02:48 p.m.
Para: Rodrigo Gonzalez
CC: Steve Atkins; pgsql-general@postgresql.org
Asunto: Re: [GENERAL] puzzling perl DBI vs psql problem

No, I don't have 2 instances running.  I default the port on the psql command line, and the perl program is using 5432,
asnormal. 

Now, I'm discovering that syslog is no longer logging anything.  I bounced it, but to no avail.

Susan


Check  the log from webserver .... and check if the user is the same for psql and perl ...

see you