Ken Tanzer 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 it doesn't seem
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 boo_tabl
>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 wrote:
>
> 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 col
On Thu, Nov 21, 2013 at 5:12 PM, Tom Lane wrote:
> Ken Tanzer 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 val
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
On Thu, Nov 21, 2013 at 4:14 PM, John R Pierce 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 ooga-booga
> to
On Thu, Nov 21, 2013 at 6:11 PM, Tom Lane wrote:
> Joe Van Dyk 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 inline
Joe Van Dyk 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 quit being
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 run
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
Ken Tanzer 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 conditions involving COA
On Thu, Nov 21, 2013 at 2:22 PM, Kevin Grittner wrote:
> Ken Tanzer 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 va
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 buffer
Mike Broers 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 (pgsql-general@postg
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 for
Mike Broers 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 stack.
(2) Ther
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
yep, that worked... thanks again.
On Thu, Nov 21, 2013 at 4:38 PM, Joey Quinn 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 wrote:
>
>> On 2013-11-21 15:40, Joey Quinn wrote:
>>
>>> I have a
Ken Tanzer 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?:
SELECT version(
Mike Broers 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. Unless you
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 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 (unique) on an inet co
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 mat
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 s
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 a
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_sessi
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_upgr
Bruce Momjian 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
28 matches
Mail list logo
