Ken Tanzer ken.tan...@gmail.com wrote:
In doing a left join with a particular view as the right table,
and non-matching join criteria, I am getting values returned in a
few fields. All the rest are NULL. I would expect all the right
side values to be NULL.
What is the output of executing?:
yep, that worked... thanks again.
On Thu, Nov 21, 2013 at 4:38 PM, Joey Quinn bjquinn...@gmail.com wrote:
Ahhh, that's what I was missing... thank-you. (just launched, we'll see
how that one goes).
On Thu, Nov 21, 2013 at 3:48 PM, Elliot yields.falseh...@gmail.comwrote:
On 2013-11-21
Thanks for the response. fsync and full_page_writes are both on.
Our database runs on a managed hosting provider's vmhost server/san, I can
possibly request for them to provide some hardware test results - do you
have any specifics diagnostics in mind? The crash was apparently due to
our vmhost
Mike Broers mbro...@gmail.com wrote:
Thanks for the response. fsync and full_page_writes are both on.
[ corruption appeared following power loss on the machine hosing
the VM running PostgreSQL ]
That leaves three possibilities:
(1) fsync doesn't actually guarantee persistence in your
Thanks, after this pg_dumpall I am going to see what kind of impact I can
expect from running VACUUM FREEZE ANALYZE (normally I just run vacuumdb
-avz nightly via a cron job) and schedule time to run this in production
against all the tables in the database. Is there anything I should look
out
Mike Broers mbro...@gmail.com wrote:
Is there anything I should look out for with vacuum freeze?
Just check the logs and the vacuum output for errors and warnings.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-general mailing list
On 11/21/2013 2:51 PM, Kevin Grittner wrote:
That leaves three possibilities:
(1) fsync doesn't actually guarantee persistence in your stack.
I'll put my $5 on (1) virtualization stacks add way too much
ooga-booga to the storage stack, and tend to play fast and loose with
write
Hello. In doing a left join with a particular view as the right table, and
non-matching join criteria, I am getting values returned in a few fields.
All the rest are NULL. I would expect all the right side values to be
NULL.
(The view is large and messy, but it doesn't seem like that should
On 2013-11-21 15:40, Joey Quinn wrote:
I have a table (5 columns) with approximately 670 million rows. It has
had an index (unique) on an inet column from the beginning. Today I
added a primary key constraint based on the same column thinking that
since it already had an index, this would be a
I have a table (5 columns) with approximately 670 million rows. It has had
an index (unique) on an inet column from the beginning. Today I added a
primary key constraint based on the same column thinking that since it
already had an index, this would be a relatively quick operation. That does
not
On Thu, Nov 21, 2013 at 2:22 PM, Kevin Grittner kgri...@ymail.com wrote:
Ken Tanzer ken.tan...@gmail.com wrote:
In doing a left join with a particular view as the right table,
and non-matching join criteria, I am getting values returned in a
few fields. All the rest are NULL. I would
Mike Broers mbro...@gmail.com wrote:
Hello we are running postgres 9.2.5 on RHEL6, our production
server crashed hard and when it came back up our logs were
flooded with:
ERROR: unexpected chunk number 0 (expected 1) for toast value 117927127 in
pg_toast_19122
Your database is corrupted.
On Thu, Nov 21, 2013 at 06:22:50AM -0800, Kevin Grittner wrote:
I would be happy to supply a patch to treat
default_transaction_read_only the same as statement_timeout or
standard_conforming_strings in pg_dump and related utilities.
Since it causes backup/restore failure
... (and pg_upgrade
Ahhh, that's what I was missing... thank-you. (just launched, we'll see how
that one goes).
On Thu, Nov 21, 2013 at 3:48 PM, Elliot yields.falseh...@gmail.com wrote:
On 2013-11-21 15:40, Joey Quinn wrote:
I have a table (5 columns) with approximately 670 million rows. It has
had an index
Ken Tanzer ken.tan...@gmail.com writes:
Hello. In doing a left join with a particular view as the right table, and
non-matching join criteria, I am getting values returned in a few fields.
All the rest are NULL. I would expect all the right side values to be
NULL.
Hmmm ... the join
On 11/21/2013 12:40 PM, Joey Quinn wrote:
I have a table (5 columns) with approximately 670 million rows. It has
had an index (unique) on an inet column from the beginning. Today I
added a primary key constraint based on the same column thinking that
since it already had an index, this would be
Update - I have two hot replication slaves of this db, both have the
problem. I took one out of recovery and ran REINDEX table session_session
and it fixed the errors about this row. Now Im going to run vacuum and see
if there are other tables that complain, but Im guessing if so I will need
to
Hello we are running postgres 9.2.5 on RHEL6, our production server crashed
hard and when it came back up our logs were flooded with:
STATEMENT: SELECT session_session.session_key,
session_session.session_data, session_session.expire_date,
session_session.nonce FROM session_session WHERE
Bruce Momjian br...@momjian.us wrote:
On Wed, Nov 20, 2013 at 02:36:08PM +0100, Karsten Hilbert wrote:
Karsten Hilbert wrote:
Let me try to rephrase:
Fact: pg_upgrade can NOT properly upgrade clusters which
contain databases that are set to
default_transaction_read_only on
Joe Van Dyk j...@tanga.com writes:
I had a function that was set to SECURITY INVOKER. I needed to give access
to a view that uses this function to a role, so I made the function
SECURITY DEFINER.
The function is STABLE and is usually inlined and takes 2 ms to run.
Immediately, the function
On Thu, Nov 21, 2013 at 6:11 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Joe Van Dyk j...@tanga.com writes:
I had a function that was set to SECURITY INVOKER. I needed to give
access
to a view that uses this function to a role, so I made the function
SECURITY DEFINER.
The function is STABLE
On Thu, Nov 21, 2013 at 4:14 PM, John R Pierce pie...@hogranch.com wrote:
On 11/21/2013 2:51 PM, Kevin Grittner wrote:
That leaves three possibilities:
(1) fsync doesn't actually guarantee persistence in your stack.
I'll put my $5 on (1) virtualization stacks add way too much
On Wed, 2013-11-20 at 14:57 -0500, Steven Dodd wrote:
I've read that setting LC_COLLATE to something other than C /
POSIX negatively affects performance, and disables use of indexes
for LIKE, etc...
It doesn't disable the use of indexes, you just need to create different
indexes.
Does the
I had a function that was set to SECURITY INVOKER. I needed to give access
to a view that uses this function to a role, so I made the function
SECURITY DEFINER.
The function is STABLE and is usually inlined and takes 2 ms to run.
Immediately, the function quit being inlined and took 1500ms to
On Thu, Nov 21, 2013 at 5:12 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Ken Tanzer ken.tan...@gmail.com writes:
Hello. In doing a left join with a particular view as the right table,
and
non-matching join criteria, I am getting values returned in a few fields.
All the rest are NULL. I
From the way the table was filled, I knew there were no nulls. It succeeded.
On Thu, Nov 21, 2013 at 8:15 PM, Joshua D. Drake j...@commandprompt.comwrote:
On 11/21/2013 12:40 PM, Joey Quinn wrote:
I have a table (5 columns) with approximately 670 million rows. It has
had an index (unique)
The issue also seems tied to the non-NULL constant in the view.
This one yields rows
33::int AS b_field
This one doesn't
NULL::int AS b_field
DROP VIEW IF EXISTS boo_top_view;
DROP VIEW IF EXISTS boo_view;
DROP TABLE IF EXISTS boo_table;
DROP TABLE IF EXISTS a_table;
CREATE TABLE
Ken Tanzer ken.tan...@gmail.com writes:
Getting a build environment together seemed more painful, so here's a test
case.
Wow, that's pretty broken. I'll dig into it tomorrow.
Just for fun, I tried this in another database on a different
machine (and with 9.0.08). I got the same results, so
28 matches
Mail list logo
