I see in the Release Notes for 9.3 beta . . .
Force cached functions to be replanned if the search_path changes (Tom Lane)
Previously functions already run in the current session ignored search_path
changes.
Question:
Do Prepared Statements also get replanned, if the search_path changes ?
log_line_prefix = '%m %a %u %c %v %x '
# %m Time stamp with milliseconds
# %a Application name
# %u User name
# %c emits a quasi-unique Session ID,
# consisting of two 4-byte hexadecimal numbers (without leading zeros)
separated by a dot.
# The numbers are the Process
PostgreSQL 9.1.8 on x86_64-unknown-linux-gnu,
compiled by gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-52), 64-bit
I see in the postgres log, on a DEV box
. . .
2013-04-18 17:09:44.721 EDT 516f10af.34fb 2/160904 0 ERROR: not enough stack
items
2013-04-18 17:09:44.721 EDT 516f10af.34fb 2/160904 0
We get this FATAL pg_log entry, just after Postgres startup.
(Postgres does start OK)
//9.1.3 on Linux
2013-02-20 10:15:46.637 EST 50eedb22.3602 0
LOG: database system is ready to accept connections
2013-02-20 10:15:46.637 EST 50eedb22.3607 0
LOG: autovacuum launcher started
Version=9.1.7
INFO: clustering my_cool_table using sequential scan and sort
INFO: my_cool_table: found 1 removable, 1699139 nonremovable row versions in
49762 pages
Detail: 1689396 dead row versions cannot be removed yet.
CPU 9.80s/4.98u sec elapsed 175.92 sec.
INFO: clustering my_cool_table
PostgreSQL 9.1.x
I try to enable my trigger
ALTER TABLE cool_tbl ENABLE TRIGGER trg_for_cool_tbl;
I notice that it gets blocked by another backend doing
select xxx from cool_tbl;
(of course, my pain is if this transaction lasts for minutes, instead of
seconds)
I understand that
Using Postgres 9.1
(1)
Simulate a power failure by hitting Restart on my VMware Workstation.
(2)
Turn on the VM (without any script removing lock or socket file).
(3)
Try to start postgres.
$ pgsql/bin/pg_ctl start -D pgdata
server starting
2013-01-14 FATAL: lock file /tmp/.s.PGSQL.5432.lock
In regards to 9.1.x, I would like to learn some details of the nature of
checkpointing
=== Question 1 ===
- page 123 is dirty
- checkpointing starts
- page 123 gets written to disk, as part of this checkpoint
- page 123 gets modified again
? Does it get written to disk again, as part of
9.1.3 on Linux . . .
We use our own CA implementation inside Java to generate a PEM-encoded
certificate chain (server.crt) and key (server.key).
The certificates are, as they should be, base-64 encoded and surrounded by the
appropriate delimiters such as
-BEGIN CERTIFICATE-
-END
Continuation . . .
When this happens, Postgres rejects the certificate.
FATAL: could not load server certificate file server.crt: no SSL error
reported
-dvs-
In 9.1.x
Are there any extra costs to logging all this cool stuff ?
log_line_prefix = '%m %a %u %p %c %m %v %x'
Are any of these expensive ?
Or is the only cost the number of bytes that the textual representation of
their values take in the written log file ?
Thanks,
-dvs-
Using 9.1.3
Start Transaction; DO $$ BEGIN raise info '%', txid_current(); END $$; ALTER
TABLE MyCoolTable_1 DISABLE TRIGGER trg_foo_1 ; Commit;
Start Transaction; ALTER
TABLE MyCoolTable_2 DISABLE TRIGGER trg_foo_2 ; Commit;
Start
05, 2012 1:46 PM
To: Sahagian, David
Cc: pgsql-general@postgresql.org
Subject: Re: [GENERAL] values from txid_current()
On Wed, Sep 5, 2012 at 10:53 PM, Sahagian, David
david.sahag...@emc.commailto:david.sahag...@emc.com wrote:
Why are the Messages displayed by my pgAdmin sql window like
Using 9.1
Can somebody tell me the order in which the Unique Constraints of a table are
checked, like when an INSERT is done ?
It seems the the Primary is checked first, but what about the regular UCs ?
Thanks,
-dvs-
Is there any way for me to control the name of the (unique or primary)
constraints that get created when doing a create table like parent-table
statement ?
I use this statement to create the new table in a different schema than the one
in which the parent-table lives, and I would like the
15 matches
Mail list logo